服务网格框架初探：Istio、Linkerd和SOFAmesh
博云技术社区（ID：bocloudresearch）由博云研究院运营，专注IT进化研究，探索云技术与行业应用的深度融合，为行业数字化转型带来完善的解决方案。
导读
2018年，Service Mesh在国内大热，有多家公司推出自己的Service Mesh产品和方案。本篇文章结合Service Mesh领域内关注度较高的几种开源方案，从架构层面出发，进行初步解读。
服务网格（ServiceMesh）是什么？
Willian Morgan——Bouyant CEO给出的 Service Mesh 定义： 服务网格是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中，服务网格通常实现一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。 具体来说，Service Mesh 是服务的前置代理层的实现，采用 sidecar 设计模式，用来管理 inbound 和 outbound 流量，并且针对拦截的流量和具体配置，实现路由转发，策略控制，认证授权，数据监测等功能。将与业务服务紧密结合的外围支撑组件从服务组件中剥离，形成独立的基础设施层，进而让服务回归业务本身，不再考虑外围支撑，实现真正的服务无关性、无侵入式治理。 由于目前社区对 Service Mesh 实现都基于容器之上实现，因此本文中重点介绍 基于Kubernetes 的 Service Mesh 方案，并对其中的优劣势做出对比说明。目前社区比较活跃的 Service Mesh 实现主要有3个：Linkerd2、Istio、SOFAMesh。 服务网格对比 Linkerd2 Linkerd是基于 Kubernetes 和其他框架的服务网格。它通过为你提供运行时调试，可观察性，可靠性和安全性，使运行服务更容易，更安全，而无需对代码进行任何更改。 Istio Istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网格，可以透明地分层到现有的分布式应用程序上。它也是一个平台，包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio的多样化功能集使你能够成功高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。 SOFAMesh SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案 。 架构 Linkerd2 Linkerd2 整体上分为数据平面和控制平面两部分。为了能够更好的契合Kubernetes 容器环境，基于 Rust 和 Golang 重写 Linkerd 所有功能组件，主要包括控制器，管理控制台，数据采集器，数据展示平台。 控制器（Controller） 控制器部分有多个容器（public-api，tap，destination，proxy-api）组成，这些容器提供了控制平面的大部分功能。 管理控制台（Web） 提供 Linkerd2 对外呈现的 Dashboard，方便运维人员以可视化的方式实时查看服务运行状态。 数据采集器（Prometheus） Linkerd2 中 Prometheus 组件和开源 Prometheus 组件区别在于，Linkerd2中 Prometheus 针对 Linkerd2 的特殊实现，Linkerd2 中公开的所有监测指标都通过 Prometheus 进行操作，并且完成数据的持久化存储。 数据展示平台（Grafana） Grafana 与 Prometheus 集成，作为 Linkerd2 收集的性能监测数据可视化展示平台。 Istio 从 SOFAMesh 架构图可以看出，SOFAMesh 源自 Istio，区别在于 SOFAMesh 在继承 Istio 强大的功能和丰富特性的基础上，根据阿里的实践经验做了以下增强： 采用 Golang 编写的 MOSN(Modular Observable Smart Net-stub)取代 Enovy，同时保证完全兼容 Envoy API； 合并 Istio 中 Mixer 组件的 check policy 功能到数据平面，有效解决大规模服务部署情况下，Mixer 一级缓存在进行策略检查时引发的“笛卡尔积问题”，同时保留 Mixer 中遥测数据上报的功能。 针对客户的实际使用情况，增强 Pilot 的服务发现能力，在保留原有能力基础上，增加对 Dubbo，SOFA Registry 的支持，后续将进一步增加对 Zookeeper 支持； 增加数据同步模块，实现多个服务注册中心数据同步； 增加 Open ServiceRegistry API，提供标准化的服务注册功能； 支持更多的协议处理（SOFA RPC、DUBBO RPC 等）。
