Service Mesh概述

关于ServiceMesh相关知识和进展,推荐资深大牛敖小剑的相关文章 https://skyao.io/

ServiceMesh的社区网站 http://www.servicemesher.com/

最近蚂蚁金服开源了分布式框架 SOFA,项目地址 Alipay,具体文档可见 Sofa

关于Sofa Mesh, 暂时未开源,相关选型介绍可见 Sofa Mesh

一、 Service Mesh概念与定义

这个概念首先由Linkerd的团队提出,其官方定义是:

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

总结就是:

  1. 服务网格是一个基础设施层

  2. 实现服务间请求的可靠传递、轻量级的网络代理

  3. 对应用与开发者透明

故事的开始是微服务的出现与普及,很多大型单个应用程序可能由数百个服务组成,且每项服务可能有数千个实例,这些实例都是不断变化的。一旦实例状态变化,如offline变成online等,调度程序都需要进行动态调度。运行期间,这些服务之间的通信非常复杂,但这些通信却是每个应用的普遍需要的基础部分。因此将该部分抽象出来,形成服务网格,从而提供服务间可靠与高性能的通信服务。

二、 Service Mesh解决的问题

一个应用被拆分成了多个微服务,每个微服务又进行分布式部署,人工手动部署的话肯定是没人愿意的。因此Docker和Kubernetes等工具就出现了,实现了方便快捷将一个微服务应用成功部署。这些工具实现了整个部署过程的标准化。

一个服务产生价值的过程是在其运行期间与其他服务配合完成的,那么这个配合过程是否也能标准化呢?正如前文所述,运行期间,服务的状态与能力都是会变化的,为了能让应用稳定运行,这就需要每个服务都具备负载均衡、检测、通信可靠、安全、日志等能力。显然这些功能可以被抽成库,实现复用,比如谷歌的Stubby、Netflix的HYstrix、Twitter的Finagle等,提供了在运行期间服务之间的统一操作。其实这些库就是service mesh。

库方式的service mesh存在许多缺点,如以下几点:

  • 与服务耦合,主要会有代码入侵和升级难的问题。 首先,代码入侵。开发者需要了解如何使用这些SDK并完成相应的非业务代码。 其次,升级难。库的更新会要求服务也更新,但出于对应用稳定性的考虑,或重新部署比较麻烦,开发者更新都比较谨慎,库的兼容性问题就出现了。

  • 依赖冲突。比如两个库都用到了fastjson,但由于依赖版本的不同,maven最近原则选择了其中一个版本,那就可能导致另一个库在执行时出现NoSuchMethod等错误,就需要手动解决冲突。

  • 无法跨语言。如果多语言支持代价很大,甚至可能需要重新开发一套。

  • 应用开发和服务运维界线不清。故障时,应用开发者往往需要自行定位问题,无法由库的开发者统一对库进行监控与运维,等等。

  • 另外一个办法就是代理,用另一个标准化服务代理当前服务就完美的解决了上述问题。这个代理服务分布式部署在每个服务所在的机子上,对原来形态各样服务的监控和负载均衡等操作,现在全部可通过对统一的代理服务的特定接口进行操作。

由上,service mesh实现了服务之间操作的标准化,实现了运行期的服务治理,让服务开发者回归业务开发与维护。

三、 Service mesh的出现过程

如图所示,服务与服务直接交互转变成了service mesh代理。 service mesh.png

这个过程中,还经历了如下几个阶段:

  1. 主机之间直接相连 service mesh 1.png

  2. 网络层实现通信控制,解决数据包顺序等问题 service mesh 2.png

  3. 集成到应用程序内部的流量控制 service mesh 3.png

  4. 解耦到应用程序外部的流量控制 service mesh 4.png

  5. 应用程序的中集成服务发现和断路器 service mesh 5.png

  6. 专门用于服务发现和断路器的软件包/库。缺点是与服务耦合 service mesh 6.png

  7. 服务发现和断路器开源软件,如 Netflix OSS、Spring Cloud等 service mesh 7.png

  8. 微服务代理service mesh 出现,图中sidecar的中文是边车,就是吃鸡里面三个轮子的那种摩托车。这里就是一个代理服务。 service mesh 8.png

每个阶段详细解释可阅读 Pattern: Service Mesh这篇文章。

四、 Service mesh 代表产品

Service Mesh的代表产品主要有Linkerd、Envoy、 Istio和Conduit。

Buoyant公司给出了service mesh的定义,并发布第一个产品化的Service Mesh Linkerd。2016年1月15号,发布0.0.7版本,2017年4月发布1.0版本,并加入了CNCF。现在已经到1.4.3版本。 2016年9月Lyft发布service mesh产品Envoy。

按理Linkerd可能会是该领域的领头羊,只是在2017年5月,Google和 IBM等大佬公司们联合开发了Istio,0.1版本release。目前最新版本是0.8.0。其中,Istio将Lyft开发的Envoy作为其数据面板部分。三大巨头合作后,相比Linkerd新增了服务控制相关的控制面板,功能强大。Isotio发展迅速。而Linkerd却发展趋势急剧下降。2017年11月Linkerd就提出了和Istio集成,作为数据面板替换掉Envoy。不过Envoy稳定发展,并没有受影响。

2017年12月,Buoyant提出了最新产品Conduit,对标Istio。但目前看来,好像还是Istio发展更好。下面就概述下Istio的架构。

五、Istio 架构

Service mesh的主要目的是实现服务运行时的标准化治理。Istio将服务的管理分为了两大部分:数据面板和控制面板。 istio.png

数据面板:就是上文中的sidecar部分,代理了服务的所有通信。 控制面板:运行期间的服务控制,如流量控制和配置管理等。

Istio中,数据面板由Envoy实现。控制面板包括Pilot,Mixer,Istio-Auth三部分。 Envoy的功能包括:HTTP/1.1、HTTP/2、gRPC和TCP通信;请求过滤;服务健康检查;加密与认证;日志服务;Distribution Trace等。 Pilot:服务发现;路由;负载均衡;故障处理;规则配置。官方描述为收集与验证配置,并传递给Istio的其他组件。 Mixer:为了减少envoy与服务的耦合而存在,让服务开发者仅关系业务本身,而验证规则、服务监控规则等则分离出来放到Mixer中,由运维人员负责。Mixer的功能包括:前提条件检查,比如请求的合法性验证;配额管理,如限速;监测报告,上传服务日志等。 Istio-Auth:用于保证服务与服务之间的通信安全。包括:身份认证,密钥管理,请求审核等。 istio 1.png

六、 总结

service mesh还是个相对较新的技术,不过已经被认为是下一代的微服务,可见该技术对于微服务的必要性。Service mesh的最大功能在于将运行期的微服务通信,微服务管理进行标准化管理,从而简化了微服务的开发与运维。

文章目录
  1. 一、 Service Mesh概念与定义
  2. 二、 Service Mesh解决的问题
  3. 三、 Service mesh的出现过程
  4. 四、 Service mesh 代表产品
  5. 五、Istio 架构
  6. 六、 总结