istiosidecar流量接管_服务网格框架初探：Istio、Linkerd和SOFAmesh

 点击“博云技术社区”&＃xff0c;获取最新技术分享

导读

2018年&＃xff0c;Service Mesh在国内大热&＃xff0c;有多家公司推出自己的Service Mesh产品和方案。本篇文章结合Service Mesh领域内关注度较高的几种开源方案&＃xff0c;从架构层面出发&＃xff0c;进行初步解读。

服务网格(ServiceMesh)是什么&＃xff1f;

Willian Morgan——Bouyant CEO给出的 Service  Mesh 定义&＃xff1a;

服务网格是一个用于处理服务间通信的基础设施层&＃xff0c;它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中&＃xff0c;服务网格通常实现一组和应用程序部署在一起的轻量级的网络代理&＃xff0c;但对应用程序来说是透明的。

具体来说&＃xff0c;Service Mesh 是服务的前置代理层的实现&＃xff0c;采用 sidecar 设计模式&＃xff0c;用来管理 inbound 和 outbound 流量&＃xff0c;并且针对拦截的流量和具体配置&＃xff0c;实现路由转发&＃xff0c;策略控制&＃xff0c;认证授权&＃xff0c;数据监测等功能。将与业务服务紧密结合的外围支撑组件从服务组件中剥离&＃xff0c;形成独立的基础设施层&＃xff0c;进而让服务回归业务本身&＃xff0c;不再考虑外围支撑&＃xff0c;实现真正的服务无关性、无侵入式治理。

由于目前社区对 Service Mesh 实现都基于容器之上实现&＃xff0c;因此本文中重点介绍 基于Kubernetes 的 Service Mesh 方案&＃xff0c;并对其中的优劣势做出对比说明。目前社区比较活跃的 Service Mesh 实现主要有3个&＃xff1a;Linkerd2、Istio、SOFAMesh。

服务网格对比

Linkerd2

Linkerd是基于 Kubernetes 和其他框架的服务网格。它通过为你提供运行时调试&＃xff0c;可观察性&＃xff0c;可靠性和安全性&＃xff0c;使运行服务更容易&＃xff0c;更安全&＃xff0c;而无需对代码进行任何更改。

Istio

Istio 有助于降低这些部署的复杂性&＃xff0c;并减轻开发团队的压力。它是一个完全开源的服务网格&＃xff0c;可以透明地分层到现有的分布式应用程序上。它也是一个平台&＃xff0c;包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio的多样化功能集使你能够成功高效地运行分布式微服务架构&＃xff0c;并提供保护、连接和监控微服务的统一方法。

SOFAMesh

SOFAMesh 是基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案 。

架构

Linkerd2

Linkerd2  整体上分为数据平面和控制平面两部分。为了能够更好的契合Kubernetes 容器环境&＃xff0c;基于 Rust 和 Golang 重写 Linkerd 所有功能组件&＃xff0c;主要包括控制器&＃xff0c;管理控制台&＃xff0c;数据采集器&＃xff0c;数据展示平台。

控制器(Controller)

控制器部分有多个容器(public-api&＃xff0c;tap&＃xff0c;destination&＃xff0c;proxy-api)组成&＃xff0c;这些容器提供了控制平面的大部分功能。

管理控制台(Web)

提供 Linkerd2 对外呈现的 Dashboard&＃xff0c;方便运维人员以可视化的方式实时查看服务运行状态。

数据采集器(Prometheus)

Linkerd2 中 Prometheus 组件和开源 Prometheus 组件区别在于&＃xff0c;Linkerd2中 Prometheus 针对 Linkerd2 的特殊实现&＃xff0c;Linkerd2 中公开的所有监测指标都通过 Prometheus 进行操作&＃xff0c;并且完成数据的持久化存储。

数据展示平台(Grafana)

Grafana 与 Prometheus 集成&＃xff0c;作为 Linkerd2 收集的性能监测数据可视化展示平台。

Istio

Istio 在架构上同样分为数据平面和控制平面。数据平面有 Proxy 代理&＃xff0c;具体有 Envoy 实现&＃xff0c;用于协调所有服务的 inbound 和 outbound 流量。控制层面由Pilot&＃xff0c;Mixer&＃xff0c;Citadel&＃xff0c;Galley 组成。用来管理和配置代理理由策略&＃xff0c;同时通过 Mixer 用来实时策略和收集遥测数据。

Envoy 

Envoy 被部署为 sidecar&＃xff0c;和对应服务在同一个 Kubernetes pod 中&＃xff0c;管理管理所有服务的入站和出站流量&＃xff0c;提供服务发现&＃xff0c;负载均衡&＃xff0c;熔断&＃xff0c;故障注入&＃xff0c;超时等功能。同时由于和服务处于同一个 pod 中&＃xff0c;Istio 能够将大量流量行为信号作为属性提取出来&＃xff0c;这些属性可以和 Mixer 关联&＃xff0c;并且发送给监控系统&＃xff0c;提供整个服务网格行为的信息。

Pilot 

Pilot  将平台特定的服务发现机制抽象化并提炼出数据平面  API&＃xff0c;屏蔽与sidecar 的直接对接&＃xff0c;进一步实现配置管理的标准化。这样的抽象行为确保 Istio能够在多种环境下运行(例如 Kubernetes&＃xff0c;Consul&＃xff0c;Nomad)&＃xff0c;同时保持用于流量管理的相同操作界面。

Mixer

Mixer 是独立于平台的组件&＃xff0c;可以在部署的时候选择性部署。负责在服务网格上执行访问控制和使用策略&＃xff0c;并从 Envoy 代理和其他服务收集遥测数据。Mixer同时提供了可插拔式的插件模型&＃xff0c;使得能够对接各种主机和基础设施后端。

Citadel

Citadel 通过内置身份和凭证管理赋能服务间和最终用户的身份认证。

Galley(暂时接触少)

Galley 代表其他的 Istio 控制平面组件&＃xff0c;用来验证用户编写的 Istio API 配置。随着时间的推移&＃xff0c;Galley 将接管 Istio 获取配置、处理和分配组件的顶级责任。

SOFAMesh

从 SOFAMesh 架构图可以看出&＃xff0c;SOFAMesh 源自 Istio&＃xff0c;区别在于 SOFAMesh 在继承 Istio 强大的功能和丰富特性的基础上&＃xff0c;根据阿里的实践经验做了以下增强&＃xff1a;

• 采用 Golang 编写的 MOSN(Modular Observable Smart Net-stub)取代 Enovy&＃xff0c;同时保证完全兼容 Envoy  API&＃xff1b;

• 合并 Istio 中 Mixer 组件的 check  policy 功能到数据平面&＃xff0c;有效解决大规模服务部署情况下&＃xff0c;Mixer 一级缓存在进行策略检查时引发的“笛卡尔积问题”&＃xff0c;同时保留 Mixer 中遥测数据上报的功能。

• 针对客户的实际使用情况&＃xff0c;增强 Pilot 的服务发现能力&＃xff0c;在保留原有能力基础上&＃xff0c;增加对 Dubbo&＃xff0c;SOFA  Registry 的支持&＃xff0c;后续将进一步增加对 Zookeeper 支持&＃xff1b;

• 增加数据同步模块&＃xff0c;实现多个服务注册中心数据同步&＃xff1b;

• 增加 Open ServiceRegistry  API&＃xff0c;提供标准化的服务注册功能&＃xff1b;

• 支持更多的协议处理(SOFA  RPC、DUBBO  RPC 等)。