4、微服务开发：团队服务构建与测试驱动实践

微服务开发：团队服务构建与测试驱动实践

1. 微服务兼容性与团队服务引入

在微服务开发中，需要考虑兼容性规则。如果你构建的服务会频繁将大量服务以独立发布周期部署到生产环境，那么就应该花时间考虑 API 版本控制和向后兼容性策略。在从头构建微服务时，要思考服务预期的变更频率，以及有多少服务部分与变更无关（这些部分可能适合作为单独的服务）。Sam Newman 提出的微服务变更黄金规则是：能否在不改变其他任何东西的情况下对一个服务进行更改并单独部署它。

真正的微服务具有占用资源少、易于部署和无状态的特点，非常适合在弹性扩展的云环境中运行。

为了有实际功能进行测试，我们将构建一个团队服务来解决实际问题。很多公司的团队成员分布在不同地理位置，难以跟踪成员的位置、联系信息和项目分配等。团队服务旨在帮助解决这个问题，它允许客户端查询团队列表、团队成员及其详细信息，还可以添加或删除团队和团队成员。在设计该服务时，要考虑支持多种团队可视化方式，如带有成员标记的地图以及传统的列表和表格。同时，为了使示例更现实，允许个人同时属于多个团队，如果从一个团队中移除某人后他没有其他团队归属，那么将其移除。

2. API 优先开发

在编写代码之前，我们要先定义服务的 API。对于构建孤立且不与其他系统交互的 “Hello World” 应用，API 优先的概念作用不大。但在现实世界中，尤其是将服务部署到抽象基础设施的平台（如 Kubernetes、AWS、GCP、Cloud Foundry 等）时，即使是最简单的服务也会消费其他服务并被其他服务或应用消费。

现代软件开发追求每个团队能独立添加功能、修复 bug、进行增强并部署到生产环境，且不影响其