【从零开始学微服务】03.软件架构的演化过程

大家好，欢迎来到万猫学社，跟我一起学，你也能成为微服务专家。

目前大部分的企业系统和互联网应用都是采用Web的形式提供服务能力，根据系统的组织方式和部署结构，我们通常把软件架构的演化过程分为以下几个阶段：

• 单体架构
• 垂直架构
• SOA架构
• 微服务架构

单体架构

单体架构，也被成为巨石架构，就像一块巨石一样，系统的所有代码、所有逻辑、所有模块都集中在一个项目里，并且会被部署在一个进程中。比如下面的电商系统：

虽然在电商系统被分为了表示层、业务逻辑层、数据访问层，但是它们还是在同一个项目里。比如在业务逻辑层中，商品管理、库存管理、订单管理等等模块的逻辑都是在一起的，难免就会有代码互相耦合的地方，你中有我，我中有你。这就造成了代码维护的困难，比如本来是在修改商品管理的代码，一不注意就影响了库存管理的逻辑，引发了bug，甚至是生产环境的事故。

优点

• 结构简单，所有模块都集中在一个项目中。
• 部署简单，只需要部署一个进程就可以。

缺点

• 版本迭代慢，模块耦合度高，牵一发动全身。
• 代码维护困难，所有模块在一个项目里面，被他人误改的风险很高。

垂直架构

随着业务的发展，单体架构的系统会越来越臃肿，代码的越来越难以维护，所以就把系统垂直地分成了多个项目的子系统，就形成了垂直架构，也被称为竖井式架构，或烟囱架构。比如下面的电商系统：

原来的电商系统别分为了订单系统、物流系统和用户系统三个独立的子系统，子系统之间相互独立，互相不会有影响，新业务的迭代 更加高效。不过，因为系统之间无法互相调用，有些模块功能在不同系统中都有实现。比如，商品管理模块在订单系统和物流系统都有重复的实现。

优点

• 系统相互独立，互相不影响。
• 新业务迭代更加高效。

缺点

• 各个系统之间存在模块功能重复开发的情况
• 各个系统之间相互独立，无法进行相互调用，形成了“信息孤岛”。

SOA架构

SOA全称是Service Oriented Architecture，即面向服务的架构，当垂直应用越来越多，重复的业务代码就会越来越多。此时可以将重复的代码抽取出来，形成统一的业务层作为独立的服务。

SOA是在企业内部IT系统重复构建以及效率低下的背景下提出的，最初想法是更好的利用企业内部的各个IT系统能力，解决信息孤岛，适配异构系统，整合业务功能等方面的问题。比如下面的电商系统：

订单系统、物流系统等功能模块都被定义成了独立的服务，所有的服务通过企业服务总线（ESB）来互相连接。企业服务总线（ESB）承担了传输协议转换、数据格式转换、服务路由、监控告警等功能。

优点

• 解决了信息孤岛的问题，适配各种异构系统。
• 提高了整个系统的可重用性和可维护性。

缺点

• 服务的接口协议不固定，种类繁多，增加了复杂度。
• 服务依赖，部署复杂。

微服务

微服务架构在某种角度上看也是面向服务的架构，微服务和SOA架构看起来非常相似，很多理念也很类似，但本质上有很大差异。

SOA架构通常都有一个庞大、复杂的ESB总线，各个单体应用之间通过ESB来交换数据，ESB也承担了很多业务逻辑转换和处理的工作；但在微服务概念里面，没有ESB，有的只是轻量级的消息通信机制。

微服务是一种通过更细力度服务组合来构建大规模复杂系统的的架构风格，这些服务围绕业务能力以及一系列设计标准而非特定的技术标准来组织。

总结

• 单体架构，所有代码、所有逻辑、所有模块都集中在一个项目里。
• 垂直架构，把系统垂直地分成了多个项目的子系统。
• SOA架构，所有的服务通过企业服务总线（ESB）来互相连接。
• 微服务架构，通过更细力度服务组合来构建大规模复杂系统。

最后，感谢你这么帅，还给我点赞。