软件产品的架构，通常都是随着业务的发展而不断演变的；我从事软件开发行业也有十余年了，遇到过的软件（企业级应用，我是从事JAVA开发）架构主要有这么几种：
单体架构架构总的概括来说，单体架构就是应用所有的功能，只有一个代码包，开发和部署都在一起，这是一种比较传统的架构风格；当然，单体架构也有着诸多的缺点：
- 代码越来越多，增加了代码的复杂性；作为开发人员一定深有感触，每当修改一个老方法的时候，一定会格外的小心翼翼，生怕影响了其他的功能；
- 【在软件项目开发过程中，都有哪些常见的软件架构？】单体应用需要统一技术栈，团队中的开发人员，都需要掌握相同的开发语言和框架；
- 随着开发人员的流动，老员工离开项目组，复杂且庞大的项目代码又让新成员难以阅读和理解，技术债务越积越多；
- 代码都在一个代码包中，就算是修改一个小小的功能，都要把整个项目打包上线；
- 所有的模块都运行在同一个JVM中，非关键性业务可能占用大量的资源，导致关键性业务发生问题；不能单独对某一个模块进行扩展 。
文章插图
文章插图
SOA架构因为单体应用架构的种种缺点，已经不能再满足业务需求的时候，于是就出现了SOA架构 。
SOA架构的主要思想是把应用程序的模块化组件，通过接口联系起来（接口可以独立于语言、框架、硬件、操作系统）；在SOA架构中，有两个主流实现方式：
- Web Service：使用WSDL定义接口，SOAP协议通信，传输XML数据；缺点是SOAP、XML较重；服务管理不完善；
- ESB：企业服务总线，每个服务提供者通过总线模式插入系统，总线完成服务的编排和转发；但ESB本身就比较中，而且它本身算是一个单点，在软件架构中，单点意味着风险；
文章插图
微服务架构微服务的产生，也是由于SOA架构的一些缺点，这里再次印证了这句话，【应用架构的演进的过程通常是被业务逼出来的】 。
- 在微服务的架构中，服务拆分粒度更细，提高了复用性；各个微服务可以独立开发，独立部署；
- 微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；
- 微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；
- 服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；
- 每个团队的技术栈也可以不相同，只要遵守接口协议即可 。
- 当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等 。
文章插图
推荐阅读
- 如何在论坛上推广自己的网站
- HTML中的base标签使用详解
- 软件架构的历史
- 在Centos7上安装图形化桌面工具
- 姑娘你还在冬天露脚踝呢？当心有了风度“失”了健康
- 红茶与时间同在,鲜牛奶润肤红茶
- 以生活为话题的作文600在2篇 以生活为话题的作文
- 蒲公英是在什么季节采摘,芙蓉花茶是种什么茶
- 爱上了在春天喝茉莉花茶,喝茉莉花茶的好处和功效作用
- 远程教育是什么