在单体思维中，模块 A 调用 B，模块 B 调用 C。一切正常，因为它们都在单个顺序进程中运行。但是，您也在网络上运行这些进程，这意味着延迟，这意味着对应用程序的性能影响，这不是任何人想要的。
使用 Kubernetes，微服务不应该通过远程同步请求过程相互通信，它们应该异步地相互通信。
例如，当微服务 A 收到某种请求时，它会捕获信息并可能广播它正在做什么。它不在乎谁在广播的接收端。接收器正在获取该信息并在异步流中对其进行处理。构建松散耦合的微服务意味着从头开始设计它们以尽可能自主地工作，并且 A 和其他一切之间的所有通信都是异步的。
使用面向事件的系统，客户成为发布者。任何时候客户数据发生变化，客户服务都会发布它。
不幸的是，许多使用 Kubernetes 的开发人员的工作恰恰相反。
在讨论为什么数据应该是自治的时，让我们考虑一个购物车应用程序。在许多情况下，看看为什么没有发生的事情与发生了什么相比更有趣。为什么人们将某些商品放入购物车，然后又将其取出？当您捕获每一个事件时，例如从购物车中添加或删除的项目，您将获得更丰富的数据集以供分析。这就是为什么开发人员从 CRUD（创建读取更新删除）转向 CQRS（命令查询职责分离）方法很重要的原因。CQRS 将数据的写入和数据的读取分开，这就是隔离部分。结果是面向事件的微服务类型。当您开始在事件中捕获数据时，您将停止执行 CRUD 中的基本更新和删除操作。
当您迁移到云、Kubernetes 和微服务时，挑战您迄今为止所知道的一切。实际上，当今的最佳实践与传统单体应用程序的构建方式完全背道而驰。不要使用单体数据，将私有数据用于微服务。不要依赖来自其他微服务的数据。当这些更改发生时，使用事件处理从其他微服务获取数据，并保留您自己的私有副本以供您自己消费和使用该数据的外观。这与数据的经济性无关，而与数据的速度和灵活性有关。使用 Kubernetes 和微服务的好处是难以置信的——只要确保你知道如何充分利用它的力量！