主动学习微服务架构深度解析：微服务的采用前提，微服务使用场景

在项目复杂度较小时，采用单体架构的生产力更高；复杂度到了一定规模时，单体架构的生产力开始急剧下降，这时对其进行微服务化的拆分才是合算的。复杂度和生产力虽然存在拐点，但并没有量化复杂度的拐点，或者说没有明确系统或代码库的规模达到具体多大时才更加适合开始进行微服务化的拆分。

团队决定构建一个微服务项目时，需要根据项目的复杂度判断是否有必要采用微服务架构，因为微服务本身也会给系统带来非业务功能的复杂性，所以在转型微服务时要慎重考虑。大多数采用微服务架构的场景还是单体架构的改造，这是业务开发人员在巨石型应用带给团队极大困扰之后的一个自然选择。这个项目阶段往往就是所谓的项目复杂度与生产力的“拐点”时期，对单体架构进行合理的服务拆分是实施微服务架构的一大前提，在后续的章节中，我们会进一步详细讲解服务拆分的依据和策略。Martin Fowler 曾经说过：“……除非你的系统复杂到难以管理的程度，否则不要考虑采用微服务……”微服务架构需要额外的开销，比如服务设计、服务通信、服务管理和系统资源。采用微服务是有代价的，如果一个应用程序无法充分利用微服务的优势，那么采用微服务反而得不偿失。所以，在我们采用微服务之前，首先需要做一个很好的权衡，需要明白使用微服务的驱动力是否充足；业务是否复杂到需要借助微服务拆分来解决问题，以快速响应变化。

团队规模

微服务架构非常适合大型项目团队。对于大型项目，《人月神话》中的“人月互换理论”已经证明是失败的，这种方式往往忽略了沟通的成本。正如著名的“两个比萨原则”：如果两个比萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。

然而，对于小型的项目团队或者只有少数开发人员维护的系统，其实是没有必要使用微服务架构的。单体架构的简单性有助于简化团队成员的工作，并且可以将系统的复杂度控制在一定范围内。使用微服务架构会增加组织的沟通成本，模块之间的跨网络交互也会给开发和运维带来额外的成本，将本来简单的事情复杂化。

所以，在实施微服务架构前，首先请关注你的团队规模。在人力资源有限的情况下，其实并不推荐使用微服务架构，因为如果你的公司没有像亚马逊、Netflix 这样的技术储备和平台储备，微服务架构反而会增加系统的复杂度，进而带来一系列问题，让你怀念单体架构带给你的简单性。

变更频率

2016 年，Gartner 发布了关于应用变化速度的报告“Pace-LayeredApplication Strategy”，该报告以变化速度为标准将业务应用分为三层。

● SOI（Systems of Innovation，敏态业务）：比如互联网业务，需求变更快，要求快速迭代、快速交付。

●

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

SOR（Systems of Record，稳态业务）：比如传统业务，变更周期长、变化频率低、变化成本高、变化风险高。

● SOD（Systems of Differentiation，中台业务）：解决前后端的开发速度匹配失衡问题，中台为前台与后台之间添加的一组“变速齿轮”。

对于新兴行业中的敏态业务，它们需要有更加动态化和更快的响应，服务往往需要更快的交付速度和更加频繁的版本发布。微服务架构的一个显著优势，就是对变化的快速响应。微服务架构相比单体架构更加独立，所以在快速开发、持续集成、持续交付上有更明显的优势。另外，微服务架构强调使用标准、轻量级的通信协议进行服务交互，契合中台作为集成前、后台资源的业务形态。所以从业务形态和服务的交付频率上说，微服务比较适合在 SOI 和 SOD 的场景中应用。

传统的稳态业务，比如大型的电信项目、银行项目，本身周期比较长，变化频率相对较低，我们不需要迁移到微服务架构，而是最好保持它目前的运行状态。

我们可以借助工具来检查哪些项目的变更频率比较快，可以利用 GitLab 这样的工具统计项目代码的提交次数和构建频率，以便决定哪些项目需要进行微服化改造。还可以使用源代码管理系统来查看代码的活跃度。以 Git 存储库为例，可以使用常用的 Linux 工具，通过几个命令行选项来运行 Git 日志。例如，我们可以使用命令生成提交次数最多的“前十个代码文件列表”。此外，也可以利用全新的“代码鉴定”工具（比如 CodeScene）深入了解项目，CodeScene 可以识别代码中的热点，帮助我们找出代码活跃区域。

项目类型