微服务是近年来异常火爆的概念，是 Web 领域极具话题性的方向，无论是出于好奇还是学习，都得踏入一只脚试试水，睁开双眼，窥其本质。

what

要想知道微服务是什么，解决什么问题，追根溯源，不得不先关注它生长的土壤环境： 移动互联网时代。

移动互联网已经驰骋近 10 年，掀起了翻天覆地的变化。因为它的蓬勃发展，现今网民的比例已经非常之高，互联网载体对于人的时间占用已经接近极限。在这样的背景下，互联网公司一般有如下特点：

• 数据量大
• 访问量高
• 竞争激烈

为了在上述背景中更好地存活，互联网公司面有两个有些矛盾的需求：

• 应用必须具有高度的稳定性（服务高度可用）
• 应用需要有快速的迭代更新能力 (效率)

需要在高速的增长过程中，应对疯狂增长的流量与数据，需要极力避免服务器瘫痪等不可用的现象。

同时，也要保持高度的嗅觉，以最高的效率调整产品特性，并部署到线上。（部署很可能导致服务故障）

这两个需求在产品规模到达一定程度时，几乎成长为两个互斥的点。要解开这个结，就必须在产品的工程化实施过程中，同时保证稳定性与效率，而这并不简单。

挑战来自三个方面：

• 应用规模增长导致其本身复杂度极速提高（服务器和产品模块）
• 应用访问量数据量增长导致稳定性下降，特别是单体应用一损俱损（服务器）
• 人员规模增长导致协作效率急剧下降（沟通和分工）

这可以进一步解释为三大瓶颈：

• 计算机的处理能力瓶颈
• 人处理熵的瓶颈
• 单个应用的容量瓶颈

要避开这些瓶颈解决上诉难点，达到高度稳定、高效率的目标，就得引入新的，理念级别的解决方案，而微服务就是这样的一种方案。

要达到上面的目的，微服务必须具备以下两项作用：

• 减熵，也就是转移复杂度（降低复杂度）
• 解耦，降低人或模块之间的相互影响

减熵主要是通过复杂度转移来实现。把一个复杂度高度集中的应用砍成多个小的模块，每个模块尽量独立，形成一个模块群。这样每个小模块的复杂度会远小于原来的应用，也将原来的集中的复杂度，部分转移到了模块群，将内部相互影响的复杂度转移到网络调用等等，实现复杂度的分而治之。

在微服务理念中，将大模块砍成小模块的的核心思路是以服务的维度。每个复杂的应用其实都是由多个模块拼接而成的，每个模块或多或少都有一部分核心的职责。以服务的维度来拆分这些模块，核心就是：

• 以服务的视角将各个模块归类
• 清晰划分各个模块的职责
• 各个模块通过网络调用进行通信（拆分前是内部调用）

通过以服务为单位进行拆分，会引导出两个极具价值的结果：

• 技术减熵。技术人员可以专注于一个个模块，用合适的工具 (语言) 逐一击破。同时避免同一件事被各个模块重复做
• 协作减熵。产品研发团队可随着服务进行对应拆分，人员螺丝钉化，各自专注于独立的点，提高小团体间协作效率

到这里，可以简单总结下复杂度的转移结果。服务化拆分其本质上是将高度集中的复杂度打散，分而治之，其中复杂度分别存在于产品技术实现和团队协作两个维度。

其结果是：

• 复杂度被打散，各个独立模块复杂度显著下降（人和技术）
• 各个模块之间通信的复杂度（网络）
• 各个模块之间连结成系统的复杂度（分布式系统）
• 各个小团队之间沟通的复杂度（协作）

当复杂度被打散之后，整体的工作难度会有很大减轻，人力资源可以得到合理利用，各个模块之间可以专注于自己的事，不用因为原来集中的复杂度而蹑手蹑脚。这本质也是实现了分工提升效率的理念。

在实现减熵之后，各个模块能独立专注地解决自己的问题，人力资源也得到了高效的利用，生产力得以极大提升。但这离产品最终上线和交付还有一段距离。这段距离就是上面所说的复杂度转移的结果：

• 因为复杂度被转移到了网络上，各个模块会相互干扰甚至牵制
• 因为复杂度被转移到了系统上，协调和组织各个模块变得复杂
• 因为复杂度被转移到了团队沟通，各个团队之间会相互影响

上面这三个点可以被称作耦合，微服务的第二大功能就是要解耦合。因为人本身的灵活性，以及团队之间沟通的结果本质上都是通过产品交付来实现，所以上面两个复杂度最终在技术上演变成了各个服务之间的复杂度。 （下面将模块改称为服务）

• A 服务上线前要等 B 服务先上线
• 多个服务依赖一个公共的服务 C
• C 服务更新时（调用地址等），需要依赖的服务跟着更新
• 新加一个服务 E，需要老的服务 D 修改
• 各个服务复用统一的日志／限流／权限等等功能

由于上面这些依赖或者说耦合的存在，即使各个服务间的生产力很强大，但要将各个服务连接成一个系统，并交付出去，还是一件很困难的事情。所以，必须要将各个服务间的相互影响降低到最小，同时让各个服务能无缝利用统一的基础设施。

how

通过上面的分析，我们已经知道微服务的核心是：通过服务化拆分的思路来进行减熵，实现资源高效利用，提升生产力；再通过解耦来降低各个模块间的相互影响，使得整个系统在变化中能快速交付。接下来就举个简单例子介绍一下如何做到这两点。

服务化拆分的第一步是：

• 以服务为单位，清晰划分服务的职责
• 整合各个模块间复用或相似的模块，避免重复造轮子

第二步是：定义拆分后模块的通信方式。定义接口和交互方式，将各个模块串起来。是通过 rcp 还是 HTTP，数据的交互是 MQ 异步通知还是用接口实时同步，这些都得仔细推敲。

借用上图为例，当用户预定一个航班时，内部的服务可以分为如图的这么些模块，每个模块独立成一个服务分别部署。其中和调整库存、时间表查询等服务交互时需要用接口的方式实时调用，而管理奖励就可以用 MQ 异步通知。而具体的拆分粒度和交互方式，就得根据具体业务和可支配的资源而定，逐步进行演化，没有一个定量的拆分方式。

对于流量不高且趋于稳定的系统，上诉的服务化拆解一般就可以满足需求了。但是对于高流量高速迭代的系统，还需要解耦。

借助上面航班预定的简单例子。当业务流量高速增长或应对流量高峰时（搞促销），对应的服务需要扩容，而原系统中的航班预定这个核心的服务持有其他服务的地址，当某个服务扩容后，航班预定这个服务就需要知道扩容后的新地址，方便调用。当高峰过去，新增的服务下线时，又得让航班预定知道某些地址已经下线了。像这样，每个子服务发生变动都需要通知它的调用方，这是一个非常繁琐且易出故障的地方，当调用的链路变得复杂后，可行性几乎为零。而这只是系统耦合点之一。

为了解决类似的问题，常见的微服务架构中的服务注册、发现应运而生，借此实现各服务自由的弹性伸缩。经过上面的梳理，它也变得容易理解。

当需要上线新服务时，服务自己向服务中心注册，服务中心也会定期检测服务是否下线或可用性，服务中心会将这些数据以适当的方式告诉调用方，实现解耦和高可用。类似的还有服务限流、 服务熔断 、服务鉴权等等，这里不再赘述。顺带地，完整的微服务架构还包括日志处理、配置中心、流量监控等等自动化的设施作为辅助，替代人力，实现高效率、高可靠的系统。

当服务的数量到达一定的数量时，调用链会变得异常复杂，追踪管理它们也会产生一个新的复杂点。同时，服务注册发现本身也需要高性能、高稳定，这又是一个新的挑战。

when

通过上面两个部分的梳理，已经能初步得知微服务是什么，以及如何打造微服务。回头看这两部分，可以描述为：为了减轻复杂度，引入了貌似更加复杂的东西。可以用递弱代偿来解释，为了解决某一部分弱点，引入了一系列补偿措施来解决问题，而这些新引入的措施使得系统本身变得更弱（递弱），又需要不断引入新的补偿来规避这些弱点，直到达到一个平衡状态，而这个平衡状态本身并不能保持稳定。像极了人类本身的发展状态。（详细可参阅《物演通论》）

明白了这一切，在是否选择微服务架构，或者思考把微服务架构做到什么程度时，必须要看清楚微服务是否能解决自己的问题，同时能否消化掉其衍生出的挑战。得思考是否有强大的运维力量，是否能驾驭分布式系统的复杂性等等。

搞清问题、选择合适、量力而行、逐步演化。