想尝试微服务架构？别搞得像意大利面条怪兽一样乱糟糟的。

分布式系统无法维持迭代发布并最终变成一场噩梦的最常见原因是组件之间的紧密耦合。

构建（微）服务时，关键决策在于定义它们的边界以及它们如何通信。

更改一项服务不应影响其他服务。如果一项服务出现故障，其他服务甚至整个系统都不应该受到影响。边界清晰的服务允许我们在某个地方更改行为，并尽快发布更改。

我们不希望最终形成这样一个系统：为了实现某个变更，我们需要在很多不同的地方进行修改。这个过程既缓慢，又会妨碍代码所有权的清晰明确。同时部署多个服务也存在风险。

松耦合服务将相关的行为集中在一个地方，并且对与之协作的系统的其他部分了解得越少越好。

松耦合系统在服务间通信设计上较为保守。服务通常通过异步远程过程调用 (RPC) 进行通信，使用少量端点，并假定故障不可避免。该系统没有共享数据库，所有数据库变更都作为CI/CD 流水线的一部分以迭代方式执行。

指标和监控也是反馈循环的重要组成部分，它能够促进迭代开发。拥有可以实时检测问题的指标，让我们更有信心进行更改，因为我们知道可以快速从任何错误中恢复。

以下内容摘自我的关于云原生应用持续集成/持续交付（CI/CD）的书籍：

新电子书：使用 Docker 和 Kubernetes 实现 CI/CD