1 Service Mesh是什么

Service Mesh最先由Buoyant 创始人 William Morgan 提出:

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.

对此,可总结 Service Mesh 为:

  • 专用基础设施层:独立的运行单元。
  • 包括数据层和控制层:数据层负责交付应用请求,控制层控制服务如何通讯。
  • 轻量级透明代理:实现形式为轻量级网络代理。
  • 处理服务间通讯:主要目的是实现复杂网络中服务间通讯。
  • 可靠地交付服务请求:提供网络弹性机制,确保可靠交付请求。
  • 与服务部署一起,但服务无需感知:尽管跟应用部署在一起,但对应用是透明的。

    1.1 Service Mesh能做什么

  • 服务发现

以微服务模式运行的应用变更非常频繁,应用实例的频繁增加减少带来的问题是如何精确地发现新增实例以及避免将请求发送给已不存在的实例变得更加复杂。Service Mesh 可以提供简单、统一、平台无关的多种服务发现机制,如基于 DNS,K/V 键值对存储的服务发现机制。

  • 动态路由

随着服务提供商以提供高稳定性、高可用性以及高 SLA 服务为主要目标,为了实现所述目标,出现各种应用部署策略尽可能从技术手段达到无服务中断部署,以此避免变更导致服务的中断和稳定性降低,例如:Blue/Green 部署、Canary 部署,但是实现这些高级部署策略通常非常困难。如果可以轻松的将应用流量从一个版本切到另外一个版本,更或者从一个数据中心到另外一个数据中心进行动态切换,甚至可以通过一个中心控制层控制多少比例的流量被切换。那么 Service Mesh 提供的动态路由机制和特定的部署策略如 Blue/Green 部署结合起来,实现上述目标更加容易。

  • 负载均衡

运行环境中微服务实例通常处于动态变化状态,而且经常可能出现个别实例不能正常提供服务、处理能力减弱、卡顿等现象。但由于所有请求对 Service Mesh 来说是可见的,因此可以通过提供高级负载均衡算法来实现更加智能、高效的流量分发,降低延时,提高可靠性。

  • 请求熔断

动态的环境中服务实例中断或者不健康导致服务中断可能会经常发生,这就要求应用或者其他工具具有快速监测并从负载均衡池中移除不提供服务实例的能力,这种能力也称熔断,以此使得应用无需消耗更多不必要的资源不断地尝试,而是快速失败或者降级,甚至这样可避免一些潜在的关联性错误。而 Service Mesh 可以很容易实现基于请求和连接级别的熔断机制。

  • 安全通讯

无论何时,安全在整个公司、业务系统中都有着举足轻重的位置,也是非常难以实现和控制的部分。而微服务环境中,不同的服务实例间通讯变得更加复杂,那么如何保证这些通讯是在安全、授权情况下进行非常重要。通过将安全机制如 TLS 加解密和授权实现在 Service Mesh 上,不仅可以避免在不同应用的重复实现,而且很容易在整个基础设施层更新安全机制,甚至无需对应用做任何操作。

  • 多语言支持

由于 Service Mesh 作为独立运行的透明代理,很容易支持多语言。

  • 多协议支持

同多语言支持一样,实现多协议支持也非常容易。

  • Metric和链路追踪

Service Mesh 对整个基础设施层的可见性使得它不仅可以暴露单个服务的运行数据,而且可以暴露整个集群的运行数据。

  • 重试

Service Mesh 的重试功能避免将其嵌入到业务代码,同时最后期限使得应用允许一个请求的最长生命周期,而不是无休止的重试。

2 为什么有微服务了还要Service Mesh

微服务 是近三年最火的架构概念,业界有许多成熟的开源套件,如Spring CloudNetflix OSS套件dubbosofa-rpcMotan等,特别是Spring Cloud几乎成了微服务的代名词。这些微服务套件也都实现了常见的服务注册、服务发现、负载均衡、针对服务器的熔断/重试等功能。

作为业务开发在使用这些功能时,都是将相关套件类库引入到业务项目中,并在实际使用时进行一定的配置,如熔断/重试 等。

但微服务存在以下问题:

  • 多语言支持
    • 微服务在开始之初就承诺了一个重要的特性,就是不同的微服务可以采用不同的变成语言实现,服务与服务之间通过协议通信。
    • 但要实现多语言支持面临很多困难,所以现在大部分公司都是通过统一编程语言来实现。即使部分实现了多语言的微服务,需要美中语言都实现相同的功能服务框架,导致微服务SDK很重,需要实现服务注册发现,服务路由、负载均衡、服务鉴权、服务降级、服务限流等,成本极高。
  • 对业务代码侵入
    • 业务项目实现微服务需要引入微服务SDK,并进行少量的开发,这些开发是和业务项目耦合的。
    • 这种侵入,导致微服务SDK在升级过程中极其痛苦,甚至为因为SDK而导致线上事故,由此带来的升级维护成本较大
    • 在我所在的公司,每次进行SDK升级时,都需要公司强制执行,升级过程中又会牵涉到与其他开源组件不兼容的情况,上线后也需要花时间灰度观察。整个公司这样做,其成本可想而知。
  • 学习成本高
    • 服务注册发现,服务路由、负载均衡、服务鉴权、服务降级、服务限流 这些功能几乎都可以独立成一个项目,实际上很多开源项目也是这样做的。每个组件的学习及熟悉成本都会很大,而业务开发首要面对的问题是业务支持,而不是花较大的精力在基础组件的学习使用上。

Service Mesh是微服务模式的新的层面。Service Mesh的主要思想是将微服务的通讯层下沉,类似将网络访问的技术栈下移到TCP。Service Mesh将服务发现、复杂均衡、服务鉴权、服务降级、限流等服务之间通讯功能下层为基础层,这样微服务只需要关注业务逻辑即可。

简化来看,Service Mesh就如同一个个网格一样。

这样,业务服务就不用关系服务启动及服务之间通信的细节,关注在业务逻辑本身即可。

3 Service Mesh的实现方式——Sidecar

由于每个节点上都需要一个节点代理,因此需要与基础架构进行一些协作,如果没有协作的话此模型就无法工作
 
相比工作审计来说,这个模型强调工作资源共享,如果节点代理用一些内存来缓存微服务的数据,那么服务就可能会在几秒钟内转向并使用该缓存区提供的数据。这可能非常有效,但容易被滥用。如果我的微服务请求所有缓存区空间,节点代理要先为你的微服务在缓存区提供一个快照。您需要更多代码来管理每个共享资源。

Sidecar,俗称挎斗,原来两轮摩托车的驾驶者集中注意力跑赛道,边车上的领航员专注周围信息和地图,专注导航等。

在Service Mesh中sidecar附加到父应用中,为应用程序提供支持性功能。

3.1 proxy

将服务框架的公共功能抽取到 Proxy 中,Proxy 作为一个单独的进程运行,每种语言的SDK只实现很小的一部分接口功能,实现一个非常轻量的客户端,客户端跟 Proxy 进行通信,Proxy 将客户端的请求,转发到服务提供方的 Proxy,再由服务提供方的 Proxy 转发到本地的服务实现上,然后执行服务,将结果原路返回。

早期使用Proxy的方式实现了Sidecar,比如Netflix的Prana和唯品会的OSP框架。

3.2 通用型sidecar

如前文所述,现在Service Mesh并没有一个标准规范指导实现,各个不同的Service Mesh也都是探索阶段,具体参见4。但总体而言,通用型Sidecar具有以下特点:

  • Service Mesh不再视为单独的组件,而是强调连接形成的网络
  • Service Mesh是一个通用组件
  • 与proxy不同,Service Mesh要求掌控所有流量

service mesh掌控了所有流量,整体视图来看,就可以有一个集中到控制面板。

Sidecar是一种向应用程序提供服务(如高级通信代理和服务网格)的方法。它特别适用于容器和Kubernetes。它的最大优势包括:

  • 不需要中央协调,可以逐步的添加到现有集群
  • 为应用程序做的工作就属于该应用程序
  • App-to-sidecar通信比app-to-agent更安全

4 业界的实现

业界的实现在蚂蚁金服大规模微服务架构下的Service Mesh探索之路 有很好的阐述。

4.1 Linkerd

Linkerd 是 Buoyant 公司的产品,是业界第一个Service Mesh。Linkerd实现了 Service Mesh 的数据面,基于 Twitter 的 Fingle,长期的实际产线运行经验及验证,支持 Kubernetes、DC/OS 容器管理平台,也是 CNCF 官方支持的项目之一。

但由于自身是 Scala 实现的的,占用资源较多,且架构上不够开放,很难对其进行适配。

4.2 Envoy

Envoy 是 Lyft 公司的产品,是7层代理及通信总线,支持7层 HTTP 路由、TLS、gRPC、服务发现以及健康监测等,也是 CNCF 官方支持项目之一。

Envoy 是专为大型现代 SOA(面向服务架构)架构设计的 L7 代理和通信总线。该项目源于以下理念:网络对应用程序来说应该是透明的。当网络和应用程序出现问题时,应该很容易确定问题的根源。

概括说,Envoy提供的是服务间网络通讯的能力,包括(以下均可支持TLS):

  • HTTP/1.1
  • HTTP/2
  • gRPC
  • TCP

以及网络通讯直接相关的功能:

  • 服务发现:从Pilot得到服务发现信息
  • 过滤
  • 负载均衡
  • 健康检查
  • 执行路由规则(Rule): 规则来自Polit,包括路由和目的地策略
  • 加密和认证: TLS certs来自 Istio-Auth

此外, Envoy 也吐出各种数据给Mixer:

  • Metrics
  • Logging
  • Distribution Trace: 目前支持 Zipkin

总结: Envoy是Istio中负责”干活”的模块,如果将整个Istio体系比喻为一个施工队,那么 Envoy 就是最底层负责搬砖的民工,所有体力活都由Envoy完成。所有需要控制,决策,管理的功能都是其他模块来负责,然后配置给Envoy。

Envoy 在总体方案上有三个比较优秀的点:线程模型、动态配置和热重启。

  • 线程模型
    • Envoy 使用的线程模型类似 netty、nginx,采用了 per thread one eventloop 模型。故性能也很强劲。
  • 动态配置
    • Envoy 提供了动态配置的功能,配置的数据模型是XDS(LDS、RDS、CDS、EDS)。
    • Listener

      也即 envoy 既然是 proxy,专门做转发,就得监听一个端口,接入请求,然后才能够根据策略转发,这个监听的端口称为 listener

    • Endpoint

      是目标的 ip 地址和端口,这个是 proxy 最终将请求转发到的地方。

    • Cluster

      一个 cluster 是具有完全相同行为的多个 endpoint,也即如果有三个容器在运行,就会有三个 IP 和端口,但是部署的是完全相同的三个服务,他们组成一个 cluster,从 cluster 到 endpoint 的过程称为负载均衡,可以轮询等。

    • Route

      有时候多个 cluster 具有类似的功能,但是是不同的版本号,可以通过 route 规则,选择将请求路由到某一个版本号,也即某一个 cluster。

  • 热启动
    • Envoy的热重启,即重启时可以做到无缝衔接,其基本实现原理是:
    • 将统计信息与锁放到共享内存中。
    • 新老进程采用基本的 RPC 协议使用 Unix Domain Socket 通讯。
    • 新进程启动并完成所有初始化工作后,向老进程请求监听套接字的副本。
    • 新进程接管套接字后,通知老进程关闭套接字。
    • 通知老进程终止自己。

4.3 Istio

Istio 是由 Google、IBM、Lyft 联合开发的,Istio 使用 Envoy 作为数据面并实现了控制面,提供了完整服务组件功能,算是到目前为止的一个集大成者。Istio 首先是一个服务网络,但是 Istio 又不仅仅是服务网格: 在 Linkerd, Envoy 这样的典型服务网格之上,Istio 提供了一个完整的解决方案,为整个服务网格提供行为洞察和操作控制,以满足微服务应用程序的多样化需求。

Istio 在服务网络中统一提供了许多关键功能(以下内容来自官方文档):

  • 流量管理:控制服务之间的流量和 API 调用的流向,使得调用更可靠,并使网络在恶劣情况下更加健壮。
  • 可观察性:了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。
  • 策略执行:将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
  • 服务身份和安全:为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。

除此之外,Istio 针对可扩展性进行了设计,以满足不同的部署需要:

  • 平台支持:Istio 旨在在各种环境中运行,包括跨云, 预置,Kubernetes,Mesos 等。最初专注于 Kubernetes ,但很快将支持其他环境。
  • 集成和定制:策略执行组件可以扩展和定制,以便与现有的 ACL ,日志,监控,配额,审核等解决方案集成。

这些功能极大的减少了应用程序代码,底层平台和策略之间的耦合,使微服务更容易实现。

Istio包含四大模块:

  • Envoy

Istio 使用Envoy 代理的扩展版本,Envoy 是以C++ 开发的高性能代理,用于调解服务网格中所有服务的所有入站和出站流量。

  • Mixer

Mixer 负责在服务网格上执行访问控制和使用策略,并从 Envoy 代理和其他服务收集遥测数据。

  • Pilot

Pilot 负责收集和验证配置并将其传播到各种 Istio 组件。

  • Citadel

Citadel 提供强大的服务间认证和终端用户认证,使用交互 TLS,内置身份和证书管理。

Istio 功能比较全面,也是业务做的最好的 Service Mesh 产品,但是被人诟病的就是其 Mixer 模块,由于每次请求都经过中心 Mixer,至使性能非常底下。

Istio 架构设计

Istio 可用性

4.4 其他

  • Nginmesh

Nginmesh 是 NGINX 的 Service Mesh 开源项目,用于 Istio 服务网格平台中的数据面代理。它旨在提供七层负载均衡和服务路由功能,与 Istio 集成作为 sidecar 部署,并将以“标准,可靠和安全的方式”使得服务间通信更容易。Nginmesh 在今年底已经连续发布了0.2和0.3版本,提供了服务发现,请求转发,路由规则,性能指标收集等功能。

  • Weibo Mesh

为了解决跨语言服务调用和发布问题,微博给出了基于 Motan-Go 的更符合微博场景的 Weibo Mesh 实现,完成内部服务化改造。

  • Sofa Mesh

Sofa Mesh 充分调研了 Envoy 和 Istio ,分析了 Istio 的优缺点,使用 Golang 实现了 Sidecar 来替代 Envoy ,并将 Istio 控制面中的 Mixer 移入 Sidecar 来提升性能。另外,在 Istio 控制面中的 Pilot 上增加 SOFARegistry 的 Adapter 来替代服务注册模块。目前还在开发中,预计7月开源。

  • Dubbo Mesh

Dubbo 3.0 计划支持可选 mesh,多加一层 IPC,这主要是为了兼容老系统;而内部则会优先尝试内嵌模式。他说代理模式 Ops 可独立升级框架,减少业务侵入,而内嵌模式可以带业务测试、部署节点少、稳定性检测方便。同时,可以将 Dubbo 3.0 启动为独立进程,由 dubbo-mesh 进行 IPC,路由、负载均衡和熔断机制将由独立进程控制。

  • CSE Mesher

CSE Mesher 基于自研的 Go 语言微服务框架(该框架即将开源)开发,使用 ServiceComb 注册中心(已经开源)与 CSE 配置中心,以 Sidecar 的方式部署在微服务所运行的环境中,也可以 PerHost 模式运行。在用户数据面使用,提供 VM 部署、公有云部署、容器部署,占用资源小(闲置10多M,并发运行时30多M)。CSE Mesher 也会考虑与 Istio 进行集成,成为除了 Envoy 之外的另一种数据面选择。

5 Service Mesh的优缺点

优点

  • 无需考虑每种语言都要解决的问题
  • 对业务代码0侵入,开发者无需关心分布式架构带来的复杂性以及引入的技术问题
  • 对于不适合改造的老旧单体应用,提供了一种接入分布式环境的方式
  • 微服务化的进程通常不是一蹴而就的,很多应用选择了演进的方式,就是将单体应用一部分一部分地进行拆分。而在这个过程中,使用Service Mesh就可以很好地保证未拆分的应用与已经拆分出来的微服务之间的互通和统一治理
  • 开发出的应用既是云原生的又具有云独立性,不将业务代码与任何框架,平台或者服务绑定

缺点

依然没有银弹,我们来看看Service mesh解决不了的问题

  • 无分布式事务方案
  • Service Mesh组件代理请求转发,会在一定程度上降低系统通信性能
  • 没有Event Driven的框架
  • 侵入式框架以源码和业务代码结合,有较强定制和扩展能力,Service mesh相对不易定制扩展
  • 在运行时,依赖单独的Service Mesh代理,多了一个故障点。整个系统的运行和运维也强依赖于Service Mesh组件的能力

References

Qcon2017实录|Service Mesh:下一代微服务
为什么说 Service Mesh 是微服务发展到今天的必然产物?
Istio
What is a Service Mesh and how Istio fits in
What’s a service mesh? And why do I need one?
蚂蚁金服大规模微服务架构下的Service Mesh探索之路
 
Service Mesh 现在如此火热,你了解多少?
 
Service Mesh架构解析
 
Pattern: Service Mesh
 
Sidecar
 
Envoy 官方文档中文版
 
Envoy 官方文档
 
深入解读Service Mesh背后的技术细节
 
浅谈 Service Mesh 体系中的 Envoy
 
Istio 文档
 
Istio 中文文档
 
万字解读:Service Mesh服务网格新生代—Istio
 
Istio官方文档中文翻译
 
深入解读Service Mesh背后的技术细节
 
Istio 及 Bookinfo 示例程序安装试用笔记