32、微服务架构的技术与政治考量

微服务架构的技术与政治考量

1. 微服务项目的基础策略

1.1 控制错误率

在微服务项目中，提高错误率的任何举措都是有益的。项目一开始就要测量错误率，借助微服务部署管道来管理风险，确保平均错误率维持在初始测量值以下。持续将代码部署到生产环境，公司需要接受这会导致短暂错误的现实。让业务方理解并接受这种权衡不仅是可以接受的，也是微服务架构带来的关键生产力提升之一，这应成为项目转型的主要目标。

1.2 舍弃功能

不要害怕舍弃功能。随着时间推移，软件系统会积累大量功能，因为移除这些功能缺乏商业动力，尽管这些遗留功能会因技术债务带来巨大成本。单个功能的价值会随时间变化，若绘制功能价值图，会呈现幂律分布。将功能与它们带来的复杂性进行对比，复杂性的衡量可以很粗略，比如代码行数。

价值与复杂性矩阵如下：
| | 低复杂性 | 高复杂性 |
| — | — | — |
| 高价值 | 理想功能 | 需优化功能 |
| 低价值 | 可考虑移除功能 | 应舍弃功能 |

右下角的功能是问题所在，它们价值低但复杂度高，其存在合理性值得质疑。无理由地移除功能会带来麻烦，但如果重新实现、重构或提供支持逻辑对开发速度有负面影响，就可以合理提出移除该功能。

1.3 停止过度抽象

开发者习惯对世界进行抽象，并将其用代码表达。但抽象会无限制增长，最终因自身重量而崩溃。要让团队停止过度抽象，这是一个艰难的人员管理挑战。开发者喜欢抽象，会陷入积极的心理反馈循环，这就是过度工程化。保持微服务小型化，默认用新的微服务实现新功能，能更好地控制这种情况。团队成员可能会反对，因为他