服务网格框架初探:Istio、Linkerd和SOFAmesh-BoCloud博云-51CTO博客

Windows Windows 2个月前 (08-15) 11次浏览 未收录 0个评论 扫描二维码

由博云研究院运营,专注IT进化研究,探索云技术与行业应用的深度融合,为行业数字化转型带来完善的解决方案。

导读

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

服务网格(ServiceMesh)是什么

Willian Morgan——Bouyant CEO给出的ServiceMesh定义:

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

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

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

服务网格对比

Linkerd2

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

Istio

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

SOFAMesh

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

架构

Linkerd2

服务网格框架初探:Istio、Linkerd和SOFAmesh-BoCloud博云-51CTO博客

 

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

服务网格框架初探:Istio、Linkerd和SOFAmesh-BoCloud博云-51CTO博客

 

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

Envoy

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

Pilot

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

Mixer

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

Citadel

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

Galley(暂时接触少)

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

SOFAMesh

服务网格框架初探:Istio、Linkerd和SOFAmesh-BoCloud博云-51CTO博客

 

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

采用 Golang编写的MOSN(ModularObservableSmartNet-stub)取代Enovy,同时保证完全兼容EnvoyAPI;

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

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

增加数据同步模块,实现多个服务注册中心数据同步;

增加OpenServiceRegistryAPI,提供标准化的服务注册功能;

支持更多的协议处理(SOFARPC、DUBBORPC等)。

喜欢 (0)
[]
分享 (0)
关于作者:
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址