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