本文主要介绍微服务架构是如何演进而来。微服务架构从单体架构演进而来。在单体应用相对较小时，应用的开发、测试和部署相对简单，但随着时间的推移，更多的功能被添加到应用中，代码的规模也进一步增长。作为功能扩展的结果，单体应用很快陷入单体地狱。开发变得缓慢和困难，因为系统本身过于庞大和复杂，以至于任何一个开发者都很难理解它的全部。这种复杂性逐渐形成一个恶性循环：由于代码库太难于理解，因此开发人员在更改时更容易戳错，且每一次更改都会让代码库变得更复杂、更难懂。针对大型复杂单体应用的开发，越来越的共识趋向于使用微服务架构。本文将从架构角度介绍微服务架构从单体架构的演进过程。
单体架构
任何一个复杂架构都是从简单架构演进而来，微服务架构从单体架构演进而来，这里介绍下经典的单体架构。一个经典的单体架构的部署图如下：
在单体架构中，应用服务和数据服务分离。这是一种经典的存算分离模式的应用，这样做的好处是，不同特性的服务承担不同的角色，处理能力和存储空间得到极大改善。单体架构中，还引入缓存改善服务的读写性能。同时，为了加速服务的访问速度，引入CDN和反向代理技术。这两个中间件的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求数据时，可以从物理距离最近的网络提供商机房获取数据，而反向代理服务则部署在网站的中心机房，当用户请求中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存用户请求的资源，则直接将其返回给用户。此外，服务使用横向扩展的方式，来解决高并发问题，从而实现系统的可伸缩性。通过负载均衡服务器，可将外部请求路由(分发)到任一应用实例。
需要说明的是，经典单体架构图中除了应用服务器是必需，其他组件都不是必需的。技术是为业务而存在的，应根据业务需要合理的选择技术。如，业务不提供文件服务能力，则不需要文件服务器，业务不提供客户端访问入口，则不需要CDN、反向代理服务器等。
分布式架构
单体应用随着时间的推移和反复的迭代开发，往往会进化成一个大泥球结构。在这种结构下，各个模块关系繁杂且牵一发而动全身，严重影响应用的可维护性、可扩展性和可测试性。针对日益庞杂的单体应用，应用的垂直拆分是一种必然选择。而应用拆分之后，则从单体架构演变成分布式架构。一个经典的分布式架构的部署图如下：
为了应对日益复杂的业务场景，根据业务场景拆分整个应用是一种合理的选择。这样，整个业务分成不同的产品线，如交易系统可将首页、卖家、卖家、订单等拆分成不同的产品线，分归不同的业务团队负责。拆分后，每个产品线维护的应用独立部署维护，各子应用之间通过消息队列等进行数据通信。随着业务拆分越来越小，存储系统越来越庞大。为避免所有应用都和数据库连接，导致数据库连接池资源不足，针对可复用的业务连接数据库，提供公用业务服务。针对其他公共业务，也抽取相关服务。如认证鉴权服务、NoSQL数据库读写服务、缓存读写服务等等。
SOA
在分布式架构的演进中，SOA(Service Oriented Architecture，面向服务的架构)获得一部分技术厂商的青睐。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。一个经典的SOA架构的部署图如下：
SOA架构遇到的一个问题是，服务拆分后，如何对外统一提供服务。API Gateway是一种解决策略，API Gateway是外部世界进入应用的入口。它负责请求路由、API组合和身份验证等多项功能。来自外部的所有API请求先转到API Gateway，然后API Gateway再将请求路由到相应的服务。
SOA中的每个服务都包含执行完整的独立业务功能(如用户鉴权、订单、购物车、交易等)所需的代码和数据集成。这些服务接口提供松耦合能力，这意味着，即使基本或根本不知道服务如何在底层集成，也可以调用服务公开的接口。
在SOA架构中使用服务总线连接各服务。ESB（企业服务总线）是一种模式，集中式组件可通过这种模式执行与后端系统的集成，然后将这些集成作为服务接口提供。ESB是一个智能管线，它会转换数据模型、深度连接、路由机制以及组合多个请求，并将它们作为单个服务接口提供，以供新应用程序复用。从理论上讲，开发者可以在不使用 ESB 的情况下实施 SOA，但每个应用程序所有者都必须通过自己独有的方式来公开服务接口，这就需要完成大量工作（即使接口最终可复用也不例外），并且在未来会带来巨大的维护挑战。 实际上，ESB 最终被认为是所有 SOA 实施都包含的事实元素，以致于有时将这两个术语作为同义词使用，从而造成了混乱。
微服务架构
SOA架构可以用来应对臃肿的单体应用，从而提高软件的可复用性，比如身份鉴权等公共能力。SOA的目标是在不影响其他服务的情况下透明地替换一个服务，只要替换之后的服务的外部接口没有太大的变化即可。这种性质大大简化软件维护甚至是软件重写的过程。但是，SOA架构高度集中的 ESB 模式及其相关的集中式集成专家团队可能会成为瓶颈。 而微服务架构会将 ESB 分解为更细粒度的分散式集成。另外，基于SOA架构构建的应用，一般都有一个全局的数据模型，并且共享数据库。而微服务架构中每个服务有属于它自己的数据库。一个经典的微服务架构的部署图如下：
在微服务架构中，服务间使用轻量级的通信管道，也即哑管道，而不是SOA架构中的智能管道(如ESB)， 微服务架构强调了服务的重要性。相比SOA，微服务架构中的服务拥有更小的服务尺寸(规模)。SOA善于集成大型、复杂的单体应用程序。微服务家架构中的服务虽然不是必须做到很小，但通常都比较小。因此，SOA应用通常包含和集成若干个大型的服务，而微服务架构的应用则常常由数十甚至上百个更小的服务组成。
总结
应用从单体架构演进成分布式架构，在分布式架构的演进过程中，又出现了SOA和微服务架构。微服务架构优良性，使其越来越多的在云服务厂商中应用。那么微服务架构会是架构演进的终点吗？答案是否定的。早在2014年，亚马逊就提出并应用Serverless架构。当然，相比微服务架构，两者作用层次不同，但本质都是将变化点抽离出来，让开发人员集中关注业务，减少非业务的影响，从而提高生产力。架构演进不是终点，是一个不断进化的事情。
参考
微服务设计 Sam Newman 著, 崔力强 等 译
微服务架构设计模式 Chris Richardson 著, 陈斌 等 译
大型网站技术架构 李智慧 著
http://www.uml.org.cn/soa/202004152.asp?artid=23177 SOA软件架构设计
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
