13、微服务架构系统的构建与发展

微服务架构系统的构建与发展

1. 代码转移与复用

在微服务系统中，代码转移是一个常见的操作。代码转移时，微服务可能需要有一个共同的接口，这是一种黑盒依赖，只需知道接口，而无需了解内部代码结构。同时，也可以将代码转移到另一个微服务中，同时保留在原微服务中，这会导致代码冗余。虽然需要在两个版本中修正错误，且两个版本可能会朝不同方向发展，但能确保微服务的独立性，尤其是在部署方面。

代码转移存在技术限制，两个微服务需使用相似技术，否则代码无法转移。不过在必要时，可使用新的编程语言或编程模型重写代码。由于微服务规模不大，重写的代码只是微服务的一部分，所需工作量是可控的。但存在一个问题，即接收代码的微服务规模会增大，有逐渐演变成单体应用的风险。

例如，订单处理微服务经常调用计费微服务来计算配送价格。若两个服务使用相同编程语言，代码可以从一个微服务转移到另一个。从领域角度看，配送成本计算应属于订单处理微服务。只有当两个服务使用相同平台和编程语言时，代码转移才可行，这也意味着微服务间的通信被本地通信所取代。

在代码复用方面，是选择将共享代码归于某个微服务，还是在多个微服务中保留冗余代码，这是一个值得思考的问题。传统的最佳实践是“不要重复自己”（DRY），即所有代码应只存储在系统中的一个位置。但在微服务架构中，冗余代码有一个关键优势，即两个微服务能保持独立，可独立部署和进一步开发，从而保留微服务的核心特性。

实际上，很难构建一个完全没有冗余的系统。在面向对象编程的早期，许多项目投入大量精力将共享代码转移到共享框架和库中，本意是减少单个项目的开发成本，但实际上可复用的代码往往难以理解和使用。在不同项目中采用冗余实现可能是更好的选择，有时多次实现代码比设计可复用