【初探云原生】服务网格整体架构

兴起之初

在微服务的思想在Martin Flower提出之后，在最近数年已经逐步深入人心。在将公共能力不断下沉的形成了Spring-Cloud全家桶和Dubbo等一系列公共的技术套件，但与之对应的问题也逐渐显现出来。

• 过于绑定特定技术栈 当面对异构系统时，需要花费大量精力来进行代码的改造，不同异构系统可能面临不同的改造。
• 代码侵入度过高 开发者往往需要花费大量的精力来考虑如何与框架或 SDK 结合，并在业务中更好的深度融合，对于大部分开发者而言都是一个高曲线的学习过程。
• 多语言支持受限 微服务提倡不同组件可以使用最适合它的语言开发，但是传统微服务框架，如 Spring Cloud 则是 Java 的天下，多语言的支持难度很大。这也就导致在面对异构系统对接时的无奈，或选择退而求其次的方案了。
• 老旧系统维护难 面对老旧系统，很难做到统一维护、治理、监控等，在过度时期往往需要多个团队分而管之，维护难度加大。

群雄逐鹿

服务网格（Service Mesh），作为服务间通信的基础设施层。是轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。

下图服务网格体系中较为流行的几个解决方案，各自均提出了针对下一代微服务的想法，且微软、Buoyant（Linkerd）和 HashiCorp（Consul）在内的多家公司联手创建了服务网格互通性规范，即服务网格接口规范 SMI，但由于缺乏Google的参与与支持，目前还未成为业界标准。从目前局势分析，Google开源的 Istio 基本成为了事实标准（毕竟Kubernetes也是他家的）

剑之所向

Istio 在社区围绕着微服务的服务注册/发现，流量管控，可观测性，安全等领域均提供了对应的方案。

上图是社区提供的服务网格的基本架构，从图上可以基本看到整体架构是分为控制面和数据面的。控制面主要负责服务发现、配置管理、证书管理等能力，在图中 Istiod 组件囊括了社区 1.5 版本前的三大组件 Pilot，Citadel，Galley（目前社区主要功能是合并在 Pilot 中，而 Citadel 和 Galley 组件正在逐步弱化），对应负责的功能如下：

• Pilot：负责 Istio 数据平面的 xDS 配置管理，具体包括服务发现、配置规则发现、xDS 配置下发。
• Citadel：负责安全证书的管理和发放，实现授权和认证等操作。
• Galley：负责配置的验证、提取和处理等功能，将 Istio 和底层平台(如,Kubernetes)进行解耦。

而数据面则有高性能流量代理组件 Envoy 负责，主要职责包括如下等功能。

• 健康检测：探测上游或下游服务实例是否健康，是否准备好接收网络流量。
• 流量路由：将网络请求路由到正确的上游或下游服务。
• 负载均衡：在对上游或下游服务进行请求时，选择合适的服务实例接收请求，同时负责处理超时、断路、重试等情况。
• 身份验证和授权：在 istio-agent 与 istiod 配合下，对网络请求进行身份验证、权限验证，以决定是否响应以及如何响应，使用 mTLS 或其他机制对链路进行加密等。
• 可观测性：对于每个请求，生成详细的统计信息、日志记录和分布式追踪数据，以便操作人员能够理解调用路径并在出现问题时进行调试。