目前，微服务架构被广泛使用。许多公司都在使用它，但不是每个人都在100%地使用它。三个方面是使微服务大放异彩的关键。
- 独立进化
- 独立测试
- 独立的部署
当所有这些点都得到满足时，微服务才会真正热闹起来。否则，部署新版本可能需要与其他团队协调，对所有依赖的服务进行级联更新，并祈祷所有的更新都能成功翻转。级联回滚是一种冒险。
独立演变
我们的应用程序随着时间的推移而演变。这是一个不可避免的过程，因为企业无法提前预测所有必要的功能，而开发人员也不可能在一周内完成所有的编码。
如果我们谈论REST，那么有一百万篇关于API进化的文章，告诉我们如何在不影响消费者的情况下更新它们。
当使用消息队列（如Kafka）时，你应该注意Avro，而不是迅速开始使用JSON。Avro支持模式进化和兼容性，这将为你在未来节省大量的时间。
专有的协议仍然是你的良知。你很可能要重新发明轮子。
独立测试
对于测试来说，一切听起来都很简单，但事实上，在一个请求的过程中，服务必须拉出另一个，再拉出另一个。而测试就不再是那么独立了。
我建议查看Spring Cloud Contract WireMock和Spring REST Docs，它允许你。
- 基于测试来编写文档
- 生成一个存根服务的工件
- 在其他微服务的测试中使用这个存根来模拟对它的调用
因此，你可以不太担心依赖的服务在现实中会有什么反应，因为你会使用它们的实际存根。
独立部署
不是每个人都能承受更新时的服务停机时间。但如果在更新过程中存在循环依赖（新A需要新B，新B需要新C，新C需要新A），这是不可避免的。我相信没有人愿意与其他团队协调来发布一个新版本的微服务。在关于独立进化的第一节中，我们谈到了如何解决这个问题。但还有一个问题--服务必须与自己的前一个版本相处。
你可能听说过蓝绿部署和金丝雀部署这些术语。这些方法假设新旧版本将共存一段时间。这意味着使用相同的数据库、分布式缓存等。
我们所需要的是保持与1个版本的兼容性。
在关系型数据库的情况下，新版本在升级过程中很可能会把一些迁移的内容卷到数据库 上。
因此，如果你需要从版本1中改变一个字段，那么最好分三步进行。
- 在版本2中添加一个新字段，并支持这两个字段
- 在版本3中，只开始使用新的字段
- 在版本4中删除旧的字段
这样，如果新的版本出了问题，以前的版本仍然可以正常工作，而且你不需要停止服务和恢复数据库。
类似的方法也适用于分布式缓存和NoSQL数据库。
结论
上述所有这些都需要努力。同时支持不同的API版本，准备测试存根（尤其是第一次），分几个步骤改变数据结构--所有这些都需要时间。因此，一个版本可能会被推迟。但是，为了充分利用微服务架构的优势，这些额外的工作是需要的。
让你的微服务独立起来》最初发表于Medium上的Javarevisited，人们在这里通过强调和回应这个故事来继续对话。
