软件架构的发展历程

一、单体架构

Web应用程序发展的早期，大部分web工程师将所有的功能模块打包到一起并放在一个web容器中运行，所有功能 模块使用同一个数据库。 下图是一个单体架构的电商系统：
特点：
1、所有的功能集成在一个项目工程中。
2、所有的功能打在一个war包部署到服务器。
3、通过部署应用集群和数据库集群来提高系统的性能。
优点：
1、项目架构简单，前期开发成本低，周期短，小型项目的首选。
2、开发效率高，模块之间交互采用本地方法调用。
3、容易部署，运维成本小，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。
4、容易测试：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统。
缺点：
1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
2、版本迭代速度逐渐变慢，修改一个地方就要将整个应用全部编译、部署、启动，开发及测试周期过长。
3、无法按需伸缩，通过集群的方式来实现水平扩展，无法针对某业务按需伸缩。

二、分布式架构

针对单体架构的不足，为了适应大型项目的开发需求，许多公司将一个单体系统按业务垂直拆分为若干系统，系统 之间通过网络交互来完成用户的业务处理，每个系统可分布式部署，这种架构称为分布式架构。

特点：
1、按业务垂直拆分成一个一个的单体系统，此架构也称为垂直架构。
2、系统与系统之间的存在数据冗余，耦合性较大，如上图中三个项目都存在客户信息。
3、系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。
优点：
1、通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。
2、每个子系统可按需伸缩。
3、每个子系统可采用不同的技术。
缺点：
1、子系统之间存在数据冗余、功能冗余，耦合性高。
2、按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。

三、SOA架构

SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好 的接口和协议联系起来。

特点：
1、基于SOA的架构思想，将重复公用的功能抽取为组件，以服务的方式向各各系统提供服务。
2、各系统与服务之间采用webservice、rpc等方式进行通信。
3、ESB企业服务总线作为系统与服务之间通信的桥梁。
优 点：
1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
2、可以针对不同服务的特 点按需伸缩。
3、采用ESB减少系统中的接口耦合。
缺点：
1、系统与服务的界限模糊，会导致抽取的服务的粒度 过大，系统与服务之间耦合性高。
2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维 护。

四、微服务架构

基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的 每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等 等，服务的粒度很小，所以称为微服务架构。

特点：
1、服务层按业务拆分为一个一个的微服务。
2、微服务的职责单一。
3、微服务之间采用RESTful、RPC等轻量级协议传输。
4、有利于采用前后端分离架构。
优点：
1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。
2、可以更加精准的制定每个服务的优化方案，按需伸缩。
3、适用于互联网时代，产品迭代周期更短。
缺点：
1、开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。
2、微服务过多，服务治理成本高，不利于系统维护。