3.Service Mesh

随着服务框架内功能的日益增多，跨语言的基础功能复用变得十分困难，这也就意味着微服务的开发者被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则。2016年出现了新的微服务架构——Service Mesh（服务网格），原来被模块化到服务框架里的微服务基础能力，被进一步从一个SDK演进成为一个独立进程——Sidecar。这个变化使得多语言支持问题得以彻底解决，微服务基础能力演进和业务逻辑迭代彻底解耦。这种架构就是云原生时代的微服务架构——Cloud Native Microservices，Sidecar进程开始接管微服务应用之间的流量，承载了服务框架的功能，包括服务发现、调用容错以及丰富的服务治理功能，例如权重路由、灰度路由、流量重放、服务伪装等。

Service Mesh是分布式应用在微服务架构纸上发展起来的新技术，旨在将微服务之间的连接、安全、流量控制和可观测等通用功能下陈伟平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无须关注微服务相关治理问题，而是聚焦于业务逻辑本身，提高了应用开发效率，加速了业务探索和创新。换句话说，因为大量非功能性的代码实现从业务进程剥离到另外的进程中，Service Mesh以无侵入的方式实现了应用轻量化。Service Mesh的典型架构如下图所示。

在上图中,Service A调用Service B的所有请求都被其下的Proxy（在Envoy中是Sidecar）截获，代理ServiceA完成到ServiceB的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面上配置的。

从架构上看，Istio可以运行在虚拟机或容器中，Istio的主要组件包括Pilot（服务发现、流量管理）、Galley（注册管理）、Mixer（访问控制、可观测性）、Gitadel（终端用户认证、流量加密）。整个服务网格关注链接和流量控制、可观测性、安全和可运维性。相比较来说，虽然服务网格增加了4个IPC通信的成本，但随着软硬件能力的提升，并不会给整体调用的延迟带来显著的影响，特别是对于百毫秒级别的业务调用而言，可以控制在2%以内。此外，服务化的应用并没有做任何改造，就获得了强大的流量控制、服务治理、可观测性、“4个9”以上的高可用性、容灾和安全等能力，再加上业务的横向扩展能力，整体收益仍然是远大于额外IPC通信支出的。

在服务网格的技术发展上，数据平面与控制平面之间的协议标准化是必然趋势。大体上，Service Mesh的技术发展围绕着“事实标准”来展开——共建各云厂商共同采纳的开源软件。

Conduit作为K8s的超轻量级Service Mesh，其目标是成为最快、最轻、最简单最安全的Service Mesh。它使用Rust构架了快速、安全的数据平面，用Go开发了简单。强大的控制平面，总体设计围绕着性能、安全性和可用性进行。它能透明地管理服务之间的通信，提供可观测性，可靠性、安全性和弹性的支持。数据平面时应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器，Conduit的设计更倾向于K8s中的低资源部署。