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

本文链接：https://blog.csdn.net/2401_84006596/article/details/138376771

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

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

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

变更频率

2016年，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技术。

遗留系统迁移