微服务架构

《Microservices》

 

不被各种新概念牵着鼻子走是技术人员最基本的素养之一。

从某种程度上来说，“微服务”也只是个“把戏”概念。单纯地列举“微服务”的优缺点简直就是在耍流氓。

 

前言综述

简单来说，微服务架构是一种将单应用拆分部署为多个子服务的架构形式。

这些子服务运行各自独立的进程中，它们之间通常使用 HTTP API 之类的轻量级机制进行通信。

这些子服务通常围绕具体的业务能力设计，可独立地部署。

 

微服务架构与单体式架构其实没有本质区别——它们都是构建服务。

这同工程管理中将一个超级工程拆分成多个多级子工程进行管理是相通用的。

拆分成多个子服务的最主要好处是便于专注地精细化管理，而不用将太多资源耗费在“集成”系统上。

如：因为精力与能力有限，实际上他只能负责具体某一块子系统业务；

如果让应用服务设计为单体式架构，他可能需要花很多精力用于各种沟通协调。

但是在微服务架构中，因为“微服务”这个概念已经迫使这个研发组织划分出各组件（子服务）之间明确的职责界限（合作契约），所以他可以将更多精力投入到自己负责的子服务业务中。

 

微服务架构（vs 单体式架构）之所以那么火，很大程度上就是因为有非常多的人有非常不切实际的想法——用伺候单个微服务的资源去 hold 住整个应用；

而且投资方（老板）又全都有这种不切实际的想法，所以更容易引发资源不足的矛盾。

大工程当然复杂，当然难做！

拆分成微服务后成本会下降吗？会，也不会！就看你是怎么算这笔账的。

如果你是想把工程做成功，那么拆分成微服务管理这条路会比单体式架构那条路更容易达到这个目标。（长期而言，微服务路线成本更低）

但是把现有单体式架构改造成微服务肯定要继续追加大量资源。（短期而言，转型需要追加投资）

现实情况往往是资源配比远不足以切换到微服务架构模式

 

但是，历史无法假设无法重来，同一个工程不可能用两种架构各完成一遍再来计算所耗资源。

非常重要的一点是：我们永远无法得知走另一条路所需成本的精确值。

虽然有一些模型可以用来预测概况，但人总是选择性地相信自己想要相信的事。

 

既想马儿跑，又不想给马吃草？没这样的好事。

 

明白工程成本上的事就更能了解其实很多我们所说的微服务架构特征未必真的是特征，单体式架构也一样可以有这些属性；

只是相比而言，在微服务架构中，这些属性一般会稍显眼一些。

特别是当人们有这些特征属性需求，而微服务架构又刚好可以更低成本实现这些需求时，这些属性就愈发显得是特征了。

 

单体式架构

企业级应用通常由三部分组成：

• 客户端：负责面向用户的交互；
• 服务端：接收并处理来自客户端的请求；
• 数据库：用于存储业务数据

在单体式架构模式下，服务端就是一个可运行的单元，所有服务端逻辑都可以放到一个进程中运行。

水平扩展方面，可以运行多个服务端实例，通过负载均衡器进行管理。

 

单体式架构的优点（微服务架构的缺点）

这些特点反过来就是微服务架构的缺点，其实也差不多就是分布式系统的缺点（CAP理论是注定会面对）。

1. 对整体服务链的调试、构建、部署更方便

因为所有服务端逻辑都在一个进程中

2. 服务间是进程内通信，响应比微服务间的网络请求快

3. 事务处理更容易

其实在单进程内实现事务就已经不容易了。多个服务间的事务处理就更容易出错。

4. 服务管理更方便

很多时候微服务架构需要有一套额外的服务管理机制来管理这些分散的服务（服务的注册与发现）。

常见的框架工具有 ZooKeeper、Spring Cloud、Eureka、Consul 等

5. 更友好的API

微服务之间通信所用 API 的调用方式通常对编程不友好。如，HTTP 请求的调用和响应实现与一般的子程序调用相比，真是极度别扭

6. 服务重构更容易

服务的重构很可能会涉及与其上下游其它服务的契约——调用方式。

在微服务架构下，这些服务分散在不同的工程里，这导致重构的难度会高很多。

而且这类重构场景下，辅助工具能做的帮助也很少，更多时候是隔靴搔痒，还是得耗很多脑力

 

单体式架构的缺点

1. 小业务逻辑范围的改动也需要对服务端进行整体构建部署

2. 只能进行整体扩容，这会增加不必要的资源占用

 

 

微服务架构

微服务的含义并不仅仅指服务规模小。它还是得遵守“高内聚、低耦合”原则。强行将应用拆分得过“细”反而会增加不必要的成本！

 

微服务架构的优点

1. 可以对子服务模块进行更精细化的管理

如，可以独立构建、测试、部署、扩容等。这为研发团队提高服务迭代效率提供了更好的支撑。

这是最主要的优点

2. 允许不同子服务选用各自最合适的的技术实现

如，不同子服务采用不同的编程语言
这算是上一条的衍生优点注： 不要盲目选用不同的技术平台。很多决策者不具备担任技术选型重任的能力和经验。此时如果要选择一种不是最主流的技术栈，就要做好所得产品就是个玩具，最终需要完全推翻重来的预算

3. 可以引导设计人员改善系统的模块化设计

具体功效因人而异。就如同 TDD 迫使编码者设计出易于测试、模块职责清晰的程序一样，效果不一定尽如人意。

相比而言，这确实有利于研发团队更方便地制作测试桩

 

*4. 比Web容器量级更轻更方便

这可能算是实践中“倒逼”出来的优点；

微服务架构会引出很多的服务进程，如果用Web容器来运行这些服务，需要处理的配置工作会很繁琐；

所以微服务架构落地时一般选用一些轻量级的工具来实现对外的Web服务。

也就是让服务进程内嵌对外提供Web服务的能力，而不是由Web容器来提供

其中最常见的工具是 Spring Boot

 

这使得微服务架构又具备了这些优点（《Spring Boot vs Web Container》）：

4.1 容易部署

4.2 运维环境维护成本低

4.3 容易实现持续交付

4.4 研发周期短

4.5 对第三方库版本的替换更方便

4.6 对依赖组建的管理更清晰

 

微服务架构项目的特征

注：这些特征是微服务架构通常会有，但并不是必须得有的。

 

特征一：通过将应用拆分为多个子服务实现组件化（每个子服务就是一个组件）

单体式架构则是通过拆分为多个 library 来实现组件化

 

特征二：围绕业务功能组建研发团队，而不是围绕技术组建团队

也就是不会在组织结构上出现UI组、后端开发组、数据库管理组等技术边界分明的组织。

实现微服务架构需要跨职能、跨技能的小组。

 

（康威定律：任何组织所设计的产品主结构与该组织内部沟通结构相同。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.）

 

单体式应用架构下，其研发组织架构也可以参照这种模式。

但因为需要处理的协调事项众多，项目规模稍大就会使得内部沟通协作成本大增，职责也往往不够清晰。

因为微服务架构会显式分清界限，所以更容易实现小组间高效协作。

 

特征三：以产品为目标，而不是项目

研发与运维角色融合地更紧密。研发团队将持续承担后续运维服务。

在单体式应用架构下，也可以这么做。但其难度远比微服务架构中维护单个子服务高。

 

特征四：小巧的服务端点和传输管道

微服务架构一般采用 HTTP API 和 轻量级消息传输 方式实现服务间通信，而不是会过多侵入业务实现的复杂协议。

这有助于单个服务高内聚，服务间低耦合。
将单体式应用改造成微服务架构的最大问题之一便是改变模块间的通信方式。与单体式架构相比，微服务间的通信没那么可靠，需要研发人员做好相关鲁棒性设计。

 

特征五：分散治理

每个子服务可以选择更适合其业务的技术平台，可以有更适合自己研发与运维模式。

 

特征六：分散数据管理

在微服务架构下，每个子服务的自管理权限较高，对数据的管理也可以根据业务需要自成一体。（这算是上一条的衍生特征）

如，单体式架构的应用一般会将数据统一集中存放在某个数据库中，而微服务则可以更自由地选择不同的数据库。

但这也往往会突出数据一致性问题。

单体式架构可以依赖数据库提供的事务机制；

但微服务下的不同数据库之间的数据一致性很难得到保障，往往只能满足最终状态的一致性，且需要设计一些补偿机制来处理这种不足。

 

特征七：基础设施自动化

应用系统从编译、测试到部署，这整个流程的自动化程度很高。

 

特征八：系统设计考虑服务异常的比重高

在单体式架构中，只要服务可用，用户就能使用。

但在微服务架构中，部分子服务失效可能会导致整个服务调用链断裂；此时，即使面向客户端的服务可用，也无法为用户提供正常服务。

为了提供良好的用户体验，在设计系统时就需要多考虑这些后台子服务失效的场景。

Netflix 的 SimianArmy （Chaos Monkey, Janitor Monkey, Conformity Monkey） 就是用于测试部分子服务不可用场景的工具。

 

特征九：持续演变的设计

子服务高程度的独立性使得改变设计的成本更低，这也会反过来“鼓励”人们根据实际需求做出相应的设计变更。

单体式架构的设计也可以是持续演变的，只是比较而言微服务模式下做起来成本会更低一些。

 

结语

并不是每个新项目都应该采用微服务架构。具体实践中还需case by case。

一般可以先采用单体式架构，同时做好模块化设计；等待将来有必要时再拆分成微服务。

当然，可能因为决策者经验不足，一开始的单体式架构本就是对多项子服务的强拉硬拽式捆绑。

也有可能仅仅是研发团队的能力经验（包括其它各项资源）不足以铺开一个微服务架构，所以单体式架构对他们而言更合适。

当然，也有些准则是我们需要尽量遵守的。比如，前后端分离要尽早。