云本机通信模式
构造云原生系统时，通信是一项重大设计决策。 前端客户端应用程序如何与后端微服务通信？ 后端微服务如何彼此通信？ 在云原生应用程序中实现通信时，需要考虑哪些原则、模式和最佳做法？
通信注意事项
在整体式应用程序中，通信非常简单。 代码模块在服务器上的同一可执行空间（进程）中一起执行。 这种方法具有性能优势，因为所有内容在共享内存中同时运行，但这会导致出现难以维护、发展和缩放的紧密耦合的代码。
云原生系统实现了基于微服务的体系结构，其中包含许多小型的独立微服务。 每个微服务在单独的进程中执行，通常在部署到群集的容器中运行。
群集将一组虚拟机组合在一起，形成高度可用的环境。 它们使用业务流程工具进行管理，该工具负责部署和管理容器化微服务。 图 4-1 显示了使用完全托管的 Azure Kubernetes 服务部署到 Azure 云中的 Kubernetes 群集。
图 4-1。 Azure 中的 Kubernetes 群集
在群集中， 微服务 通过 API 和 消息传送技术相互通信。
虽然微服务提供了很多好处，但也有代价。 组件之间的本地进程内方法调用现在被替换为了网络调用。 每个微服务都必须通过网络协议进行通信，这会增加系统的复杂性：
- 常见的担忧包括网络拥塞、延迟和暂时性故障。
- 复原能力是指重试失败的请求，它至关重要。
- 为了保持一致的状态，某些调用必须是幂等的。
- 每个微服务都必须对调用进行身份验证和授权。
- 必须对每个消息进行序列化，然后进行反序列化，这可能成本很高。
- 消息加密/解密非常重要。
可从 Microsoft 那里免费获取 .NET 微服务：适用于容器化 .NET 应用程序的体系结构这本书，深入了解微服务应用程序的通信模式。 在本章中，我们简要介绍了这些模式和 Azure 云中提供的实现选项。
在本章中，我们将首先解决前端应用程序和后端微服务之间的通信。 然后，我们将探讨后端微服务如何彼此通信。 我们将探讨上述内容和 gRPC 通信技术。 最后，我们将了解使用服务网格技的全新创新性通信模式。 我们还将了解 Azure 云如何提供不同种类的后备服务来支持云原生通信。
