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

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

1. 微服务兼容性与团队服务介绍

在微服务开发中，需要考虑兼容性规则。如果构建的应用有多个服务频繁部署到生产环境且有独立的发布周期，那么就应该花时间考虑 API 版本控制和向后兼容性策略。在从头构建微服务时，要思考服务的变更频率以及与变更无关的部分是否可拆分为独立服务。Sam Newman 提出微服务变更的黄金法则：能否在不更改其他任何内容的情况下对服务进行更改并独立部署。

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

1.1 团队服务引入

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

1.2 API 优先开发

在编写代码之前，要先定义服务的 API。

1.2.1 为何采用 API 优先

如果团队构建的是孤立且不与其他系统交互的 “hello world” 应用，API 优先的概念作用不大。但在现实世界中，尤其是将服务部署到抽象基础设施的平台（如 Kubernetes、AWS、GCP、Cloud Foundry 等）时，即使是最简单的服务也会消费其他服务并被其他服务或应用消费。