小窍门
Azure 平台的云原生 .NET 应用电子书封面缩略图。
在本书中，我们采用了基于微服务的体系结构方法。 虽然此类体系结构具有重要的优势，但它带来了许多挑战：
进程外网络通信。 每个微服务都通过网络协议进行通信，该协议引入了网络拥塞、延迟和暂时性故障。
服务发现。 微服务在使用自己的 IP 地址和端口在计算机群集中运行时如何发现并相互通信？
复原能力。 如何管理短期故障并使系统保持稳定？
负载均衡。 入站流量如何分布在微服务的多个实例之间？
安全性。 如何强制实施传输级加密和证书管理等安全问题？
分布式监视。 - 如何跨多个使用微服务关联和捕获单个请求的可跟踪性和监视？
可以使用不同的库和框架解决这些问题，但实现可能非常昂贵、复杂且耗时。 最终还涉及基础结构问题，并附带业务逻辑。
服务网格
更好的方法是一种名为 服务网格的不断发展的技术。 服务网格是一个可配置的基础结构层，具有内置功能来处理服务通信以及上述其他挑战。 它通过将这些问题移到服务代理中来分离这些问题。 代理部署到单独的进程（称为 sidecar）中，以提供与业务代码的隔离。 但是，sidecar 链接到该服务 - 它是使用它创建的，并共享其生命周期。 图 6-7 显示了此方案。
图 6-7. 使用侧车的服务网格
在上图中，请注意代理如何截获和管理微服务和群集之间的通信。
服务网格在逻辑上拆分为两个不同的组件： 数据平面 和控制 平面。 图 6-8 显示了这些组件及其职责。
图 6-8. 服务网格控件和数据平面
配置后，服务网格功能非常强大。 它可以从服务发现终结点检索相应的实例池。 然后，网格可以将请求发送到特定实例，记录结果的延迟和响应类型。 网格可以根据许多因素（包括最近请求观察到的延迟）选择最有可能返回快速响应的实例。
如果实例无响应或失败，网格将在另一个实例上重试请求。 如果返回错误，网格将从负载均衡池中逐出实例，并在实例愈合后重新声明该实例。 如果请求超时，网格可能会失败，然后重试请求。 网格捕获并向集中式指标系统发出指标和分布式跟踪。
Istio 和 Envoy
虽然目前存在一些服务网格选项， 但 Istio 是撰写本文时最受欢迎的选项。 Istio 是 IBM、Google 和 Lyft 的合资企业。 它是一种开源产品/服务，可以集成到新的或现有的分布式应用程序中。 该技术提供一致且完整的解决方案来保护、连接和监视微服务。 其功能包括：
- 使用基于标识的强身份验证和授权保护群集中的服务到服务通信。
- 针对 HTTP、 gRPC、WebSocket 和 TCP 流量的自动负载均衡。
- 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行精细控制。
- 支持访问控制、速率限制和配额的可插入策略层和配置 API。
- 针对群集中的所有流量（包括流入量和流出量）的自动指标、日志和跟踪。
Istio 实现的关键组件是名为 Envoy 代理的代理服务。 它与每个服务一起运行，并为以下功能提供与平台无关的基础：
- 动态服务发现。
- 负载均衡。
- TLS 终止。
- HTTP 和 gRPC 代理。
- 断路器复原能力。
- 运行状况检查。
- 使用 Canary 部署滚动更新。
如前所述，Envoy 部署为群集中的每个微服务的 sidecar。
与 Azure Kubernetes 服务集成
Azure 云采用 Istio，并在 Azure Kubernetes 服务中为它提供直接支持。 以下链接可帮助你入门：
