9、微服务架构：从理论到实践的全面解析

微服务架构：从理论到实践的全面解析

1. 业务与基础设施代码分离

业务信息具有快速变化、隐藏深度和易过时的特点。将业务逻辑代码封装到微服务单元中，是管理快速变化的实用工程方法。

系统中还有另一种代码：基础设施代码。这里涉及系统集成、算法、数据结构操作、解析和实用代码等。这类代码受业务变化的影响较小，通常有相对完整的技术规范、可遵循的 API 或特定的有限要求。可以安全地将其与业务逻辑代码分开，这样既不会减慢业务代码的速度，也不会受到偶然业务逻辑的负面影响。

大多数单体架构的问题在于，业务逻辑和基础设施这两种代码最终混合在一起，对团队效率和技术债务水平产生可预见的负面影响。业务逻辑应放在微服务中，基础设施应放在软件库中。正确分配编码工作的能力，能使对每项工作所需工作量的估算更准确，提高项目进度的可预测性。

2. 微服务作为软件单元

微服务作为软件的结构单元非常有用，甚至可以被视为基本单元，就像对象、函数或进程一样。因为它为系统设计提供了强大的概念模型。

我们要解决的问题本质上是多维扩展问题，包括在生产环境中扩展软件系统、扩展构成这些系统的软件复杂性，以及扩展开发团队规模。微服务概念的强大之处在于，它为许多不同的扩展问题提供了统一的解决方案。

扩展问题很困难，因为它们本质上是指数级的。例如，软件团队规模翻倍，输出速度不会翻倍；软件系统复杂度翻倍，错误数量不是翻倍，而是随代码库大小的平方增加；要服务的客户端数量翻倍，就需要管理分布式系统。

扩展可以从两个主要维度进行：垂直和水平。垂直扩展是让现有资源变得更大、更强或更快，但会受到系统物理、数学或功能方面的结构限制，且效果会呈指数级衰减