小窍门
Azure 平台的云原生 .NET 应用电子书封面缩略图。
在本章中，我们探讨了微服务通信的挑战。 我们说，开发团队需要对后端服务如何相互通信敏感。 理想情况下，服务间通信越少越好。 但是，避免并非总是可能，因为后端服务通常依赖于彼此来完成操作。
我们探讨了实现同步 HTTP 通信和异步消息传送的不同方法。 在每个情况下，开发人员都会承担实现通信代码的负担。 通信代码非常复杂且耗时。 不正确的决策可能会导致严重的性能问题。
一种更新和快速发展的技术，称为服务网格，更现代的微服务通信方法围绕该技术展开。 服务网格是一个可配置的基础结构层，具有内置功能，用于处理服务到服务通信、复原能力和许多跨领域问题。 它将这些问题的责任从微服务转移到服务网格层。 通信已经与您的微服务分离和抽象化。
服务网格的关键组件是代理。 在云原生应用程序中，代理实例通常与每个微服务并置。 尽管它们在单独的进程中执行，二者依然紧密联系并共享相同的生命周期。 此模式称为 Sidecar 模式，如图 4-24 所示。
图 4-24. 使用侧车的服务网格
请注意上图中如何通过与每个微服务一起运行的代理截获消息。 可以使用特定于微服务的流量规则来配置每个代理。 它了解消息，并可以将它们路由到您的服务和外部世界。
除了管理服务到服务通信，服务网格还支持服务发现和负载均衡。
配置后，服务网格功能非常强大。 网格从服务发现终结点检索相应的实例池。 它将请求发送到特定服务实例，记录结果的延迟和响应类型。 它根据不同的因素（包括其观察到的近期请求的延迟）选择最有可能返回快速响应的实例。
服务网格管理应用程序级别的流量、通信和网络问题。 它了解消息和请求。 服务网格通常与容器业务流程协调程序集成。 Kubernetes 支持可扩展体系结构，可在其中添加服务网格。
在第 6 章中，我们深入探讨服务网格技术，包括有关其体系结构和可用开源实现的讨论。
概要
在本章中，我们讨论了云原生通信模式。 我们首先检查前端客户端与后端微服务的通信方式。 在此过程中，我们讨论了 API 网关平台和实时通信。 然后，我们了解了微服务如何与其他后端服务通信。 我们了解了跨服务的同步 HTTP 通信和异步消息传送。 我们介绍了 gRPC，这是云原生世界中即将推出的技术。 最后，我们引入了一项名为“服务网格”的新且快速发展的技术，可以简化微服务通信。
特别强调的是托管的 Azure 服务，可帮助实现云原生系统中的通信：
接下来，我们将迁移到云原生系统中的分布式数据，以及它带来的优势和挑战。
