微服务架构--从演变开始

前言

现在大家都在谈微服务，从大公司到小公司，从技术专家到架构师到工程师都在聊微服务，甚至产品经理都在谈微服务；微服务在软件的架构发展过程中如今已经成了一种具有相对成熟，有方法指导，可工程化的的软件架构体系。我也试着去理解微服务架构的演变，去分析其中的缘由；只有清楚其中的来龙去脉，才能更好的指导我们的的设计，避免踩坑。在我的理解里：所有的架构设计都应当是伴随着业务产生的，架构的设计是为了适应业务的发展，抛开业务去谈架构都是“耍流氓”；架构应当遵循：简单 适用 演变的过程。我想从两个维度来探讨微服务的演变，一个从架构的角度，一个是从业务发展的角度；重点着眼当下去分析微服务架构解决了什么问题又带了什么问题。

什么是微服务

我尝试着根据微服务的特性来描述下什么是微服务：微服务是一种高度专注于自身独立业务，高度自治可持续快速集成部署，快速弹性伸缩松耦合面向服务的分布式架构体系

微服务的演变大体经历了这么几个阶段：

单体应用----->SOA架构设计------>微服务架构设计，这个演变的过程是渐进式的

单体架构

• 单体应用是很简单的软件架构设计，单个服务包含了所有的业务功能；有统一的数据库和中间件通常会部署在一台服务器就可以搞定，正常运行。
• 单体应用的垂直架构也很简单，常用的就是MVC了

单体架构面临的问题

1. 代码膨胀：随着业务的发展和变化，项目的代码变得臃肿，如果没有好的设计可能会千疮百孔，变得极其不易维护
2. 随着业务的复杂度提高，很代码的开发和维护，甚至是上线部署变得极其困难，很容易出错，导致线上的发布不及时，周期长等一系列的并发症
3. 随着访问量的增加，QPS的增加，单体应用的并发是很有限的
4. 给构建部署带来困难，甚至影响线上的服务，想象一下，每一次一个小的改动都要升级服务，导致服务不可用，这是不可接受的。
5. 相同的功能在不同的项目组要不断的重复开发

那么面对如此多的问题，软件的架构设计该如何来适应这些变化呢？在这个过程中，很多前辈做了很多尝试来解决这些问题，比如说，使用集群来分担并发的访问；数据库的主从读写分离来缓解数据库的压力；使用分库分表提高读写并发能力；单体应用里面功能模块化。这些解决方案都在一定程度解决了单体应用面临的问题，但是都是很有限的。人之所以能区别于其他动物就在于有强大的自我解决问题的能力，SOA面向服务的架构思想孕育而生，并且日渐成熟。那什么是SOA呢？

SOA架构

通用定义：SOA全称（Service Oriented Architecture）：SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。这个是业界通用的定义。

我的理解：我认为SOA更像是一种面向服务的架构设计方法或者说指导思想，把原有的单体应用通过以服务为单元进行拆分，每个服务有自己的业务职能，可以公共提供复用，服务间相互依赖形成对外提供业务的能力；服务之间是松耦合，通过消息总线把各个服务单元以统一的协议格式连接起来达到相互调用。SOA在不用的企业团队都会有不同的实践，不过这些实践都是围绕SOA相对通用的设计思想来设计实现的。

SOA解决了哪些问题

SOA的设计带来了哪些好处，主要是围绕这三个方面来的有序，复用，高效（下面是引用）

系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

我用比较通俗的语言来描述参考上面单体应用来分析：

1. 代码膨胀臃肿问题：通过以服务为单元把大的单体应用，以功能或者业务为维度进行拆分，减小了单个项目的量和维护开发难度；同时把各个服务在不同的项目组开发，业务变得相对独立单一，提高了开发的效率；这个其实对应的就是业务服务化（高效）
2. 并发访问的问题：通过服务的拆分，单个服务的并发访问压力变小，对整个系统实际上就是提高了并发访问的能力（高效）
3. 项目庞大不易管理：通过拆分服务，单个服务的职责变得相对单一，更加容易维护，通过消息总线ESB和规范，把各个服务统一管理起来，相互访问（有序）；
4. 在单体应用时代，如果不同项目组的服务要相互调用时极其困难的，可能一个公司N个项目组，就存在五花八门的调用方式，很难管理；SOA的设计思想是站在企业级的高度来设计架构的；通过服务的拆分，和消息总线ESB来连接各个服务，达到公用和基础服务的复用，统一规范服务之间的调用协议和方式，极大的提高了项目的管理效率。
5. 从构建部署层面：SOA架构下单体应用变成了多服务，虽然在构建部署上增加了服务的部署和维护，但是单个服务的职责单一，业务单元小，是比较不容易出故障的；单个服务的改动不用整个系统升级，只需要升级单个服务单元即可；当然事情不可能总是圆满的，相比下显然还是会选择SOA的架构，因为他从整体上解决了业务发展带来的问题，甚至是推动了业务的发展；这个选择题很好做。

SOA的星型架构

SOA结合ESB的架构

SOA中的ESB

在SOA的架构设计中ESB是一个非常重要和关键的设计，所以这边来讲一下ESB

ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互相连接；ESB梳理了服务之间复杂的调用关系，使得服务之间的调用变得清晰；这也是架构能够以服务为单元拆分的重要保障。

SOA存在的不足

• 和单体架构相比，增加了系统复杂度，系统整体性能有较大影响；所谓的增加系统的复杂度，其实是针对整个向外提供的系统，服务众多，变得复杂，但是如果从单个服务来看其实是服务变得职责更加单一，简单了。这相当于是用整理的复杂来换取单个服务的稳定也就是整个系统的稳定（有点这个意思）。至于对性能的影响，我后面会讲，我觉这个一个很值得讲和分析的点。
• SOA也是一种分布式架构系统，那么就必然存在分布式数据一致性和事务问题。
• 多服务数据通信协议之间转换过程复杂，容易造成 ESB（Enterprise Service Bus）性能瓶颈。

微服务

我尝试着根据微服务的特性来描述下什么是微服务：微服务是一种高度专注于自身独立业务，高度自治可持续快速集成部署，快速弹性伸缩松耦合面向服务的分布式架构体系。我的理解SOA是一种面向服务的组件化架构思想，在早期有星型架构，ESB消息总线架构；这些架构都一定程度上解决当时的业务架构需求，虽然存在一些问题，但是架构发展在当时很好的一种实践；微服务从定义上来看其实也具有SOA的思想，我认为微服务更像是SOA思想一种很好的实践。所以SOA和微服务的区别就很容易理解了。

区别

SOA和微服务最大的区别我认为有两点：

1. ESB和网关的区别：SOA的设计更像是针对企业内存服务级架构，通过服务拆分，达到基础服务的建设和服务间的通讯；更多的是解决企业内部服务间调用和规范问题。服务间的调用也更倾向于rpc远程调用；而微服务的网关更多的是面向用户层，所有的流量入口都从网关进入，具体的服务对使用者是透明的；服务以服务之间是通过服务注册和发现在通过网关统一访问的。
2. 服务的拆分粒度：SOA强调的是异构系统之间的通信和解耦；微服务架构强调的是按业务的边界来细粒度拆分和部署，每个服务有自己的数据库，中间件高度自治的。

微服务的特点

1. 独立部署，灵活扩展：传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（如用户服务、商品服务等）为单位进行部署。
2. 资源的有效隔离： 微服务设计原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效的避免了服务之间争用数据库和缓存资源所带来的问题。同时，由于每一个微服务实例在Docker容器上运行，实现了服务器资源（内存、CPU资源等）的有效隔离。
3. 团队组织架构的调整： 微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构。

微服务带来的问题

主要有两点

1. 由于服务的拆分，每个服务都是高度自治的，所以从运维角度来看，其实是增加了很大的难度，不过随着docker k8s的技术日渐成熟，CI/CD持续集成，灰度发布，很大程度上解放了运维，并且为弹性伸缩提供了基础。
2. 从单体到微服务还有一个问题是很值得关注的就是数据的一致性问题，尽管目前有引入很多的分布式事务和补偿机制但是给研发增加了开发的难度。