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

　　微服务使用场景

　　项目复杂度

　　微服务架构主要解决的问题是通过对庞大的单体架构进行服务拆分，使得服务更加容易理解和控制。当你的业务应用逻辑本身复杂度不是很高时，微服务架构的威力是很难发挥的，所谓“杀鸡焉用宰牛刀”。

　　下图揭示了微服务架构与单体架构的复杂度与生产力的关系。

　　

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

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

　　团队规模

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

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

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

　　变更频率

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

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

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

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

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

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

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

　　项目类型

　　从来没有一种架构模式适用于所有业务形态。目前企业内部还有很多对性能有严苛要求的系统运行在单体架构之上。虽然单体架构存在诸多缺点，但是单体架构内的各个组件之间的交互更加简单，内部的方法调用更加高效。对I/O性能要求比较高的实时计算系统或者嵌入式系统，往往关注服务的延迟和服务的吞吐性能。相比单体架构，在完成相同功能的情况下，微服务架构可能需要经过更多的网络交互调用，而远程调用势必增加系统在网络上的I/O延迟和花费在网络上的数据传输处理时间。所以，对性能敏感的项目，微服务架构对系统造成的性能影响显然是无法被接受的。

　　另 外 ， 微 服 务 架 构 更 适 合 处 理 OLTP （ On-Line TransactionProcessing，联机事务处理）类型的项目，而不擅长处理OLAP（OnLine Analytical Processing，联机数据处理）类型的项目。大数据处理中使用比较广泛的架构是Lambda和Kappa等，以及Hadoop技术。

　　遗留系统迁移

　　在生产环境中，我们有大量的遗留系统。我们可以通过逐渐改进和演变的方式实现遗留系统向微服务架构的迁移。

　　遗留系统是否要迁移到微服务架构是一个战略问题，你需要甄别遗留系统是否适合采用微服务架构。

　　在战术层面，你需要制定详细的改造迁移策略，如功能剥离、灰度替换、数据解耦、数据同步、滚动发布等。如果你正在面对一个遗留系统的微服务改造项目，那么无论它的原始设计多么随意，无论它现在变得多么糟糕，在把它重构成微服务之前，都要认真仔细地思考一下，它正处在软件生命周期的什么阶段？它是一个任务关键型系统吗（比如包含了一个不可替代的遗留数据库）？你需要多长时间来替换整个系统？更新或者替换过程需要一个长期详尽的计划吗？

　　微服务架构在更新或替换遗留系统方面扮演着重要的角色，没有策略指引的迁移很可能会造成灾难性的后果。在后续的微服务构建相关章节中，我们会讲解常见的微服务改造模式。

　　本文给大家讲解的内容是微服务架构深度解析：微服务的采用前提，微服务使用场景下篇文章给大家讲解的是微服务架构深度解析：微服务的采用前提，技术与理念觉得文章不错的朋友可以转发此文关注小编；感谢大家的支持！