ServiceMesh

服务网格

微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。

  • 服务调用的富客户端版本升级:RPC 框架由基础架构组统一开发与维护,以 SDK 形式提供给其他部门使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演进所增加的特性并不是某些业务方所需要的时,这些业务方就没有动力配合中间件事业部去同步升级自己应用中的 SDK 版本,使得 SDK 在整个集团存在多个版本甚至变成长尾而形成包袱。类似的包袱反过来制约了 RPC 框架自身的演进效率。

  • 多编程语言支持:当微服务框架是单一编程语言独大、不能同步支持好其他多个主流编程语言时(比如 C++、Go、Node.js 等), 就会出现非独大编程语言的 SDK 在特性上严重滞后于独大编程语言的,最终影响使用非独大编程语言的业务方以自己最为熟悉的编程语言去发展和探索业务。编程语言独大所带来的好处是多数人的技术栈是一样的而提高了技术层面的协作效率,但却无法收获编程语言多样性所带来的其他好处。即便同步地对多个编程语言的 SDK 进行维护,同样的特性需要用不同的编程语言去实现其成本着实很高。

  • 在微服务软件架构所主张的拆分手法下,确实可以将每个拆分出来的服务从监管控层面做到足够的精致,但这势必会因为概念抽象不同、团队成熟度不一致等原因而使得这些“精致的烟囱”难以高效无缝协同,最终的结果是软件功能的易用性、风险的可控性和适应业务变化的敏捷性无法做到全局最优。

Service Mesh 的核心思路与微服务软件架构的思路是一脉相承的,即通过拆分实现解耦——将 SDK 中频繁变更的逻辑与业务逻辑分别放到不同的进程中。从广义上讲,服务网格正如 Red Hat 所描述“一种控制应用程序内的不同模块相互共享数据的方法”。它是为适应分布式微服务环境的独特特性而构建的。在微服务构建的大型应用中,任何给定服务都可能是运行在本地或云端的多个实例上。这种动态的架构显然很难做到,随时让单个微服务与所需要的其他服务建立通信。服务网格则能够自动地实现微服务的瞬间发现和相应服务的连接。让软件开发人员和单个微服务无需考虑这方面的功能和实现。

我们可以将服务网格的作用类比为 OSI 网络模型中第 7 级的软件定义网络(SDN)。SDN 创建了一个抽象层,使网络管理员不必处理物理网络连接,服务网格则是将应用程序的底层基础设施与软件所交互的抽象体系结构进行了解耦。

应用场景

负载均衡

服务网格提供的一个关键功能就是负载均衡。我们通常认为负载均衡是网络功能,因为它提供按规则的数据包路由转发,从而防止任何单台服务器或网络链接的流量过载。借用 Twain Taylor 的描述,服务网格就是在应用级别上做了类似的事情,我们可以将它理解为应用程序层的软件定义网络。

本质上,服务网格的一个主要工作是对分布在基础设施中的各种微服务的实例,进行健康状态的持续跟踪。它可能会轮询这些实例的请求处理状态,或者跟踪服务请求响应较慢的实例,然后将后续请求发送给其他的实例。类似于网络路由,它还会关注消息到达目的地消耗时间过长的请求,并调整后续路由来补偿。这些用时过长可能是由于底层硬件的问题,或者仅仅是由于服务被请求过载或处理能力不足造成的。但重要的是,服务网格可以找到相同服务的其他实例来接替请求处理,从而最有效地利用整个应用程序的处理能力。

每个微服务都将提供一个应用程序编程接口(API),用于与其他服务的通信。这就引出了服务网格与传统的 API 管理形式(如 API 网关)之间的差异比较。借用 IBM 的解释,API 网关是位于一组微服务和应用“外部”之间,根据需要路由服务请求,让请求者无需知道它所访问的应用程序是基于微服务架构的。但服务网格不仅有上述能力,它还在应用程序“内部”的微服务之间协调请求,且各个组件完全了解整个应用内部的环境。

灰度发布

Service Mesh 是用来处理各服务间通信的基础设施层。它主要通过构建云原生应用程序的各种复杂拓扑结构来完成传递请求。实际上,Service Mesh 通常与应用程序代码一起部署轻量级网络代理的阵列来实现请求。

在 ServiceMesh 之前,我们已经采用了 APIGateway 来实现灰度发布,但 APIGateway 通常仅部署在用户流量的入口,完全灰度发布就需要完整地部署两套系统。但是在微服务时代,任何一个微服务发生变更都需要完整地部署两套系统,这不仅成本很高而且严重影响了产品变更的速度。

而 ServiceMesh 正好可以解决这些问题,它的应用类似于将 APIGateway 部署到本地,同时提供了集中化控制,极大地简化了灰度发布的实现流程、降低了变更成本、同时加快了产品发布的进度。

产品对比

  • Linkerd(读作“link-dee”):2016 年发布的元老级项目。Linkerd 最初是从 Twitter 开发的一个库中分离出来的,在领域内的另一个重量级项目 Conduit 加入后,便形成了 Linkerd 2.0 的基础。

  • Envoy:由 Lyft 创建,Envoy 充当服务网格的“数据平面”,与“控制平面”相匹配,提供比较完整的服务网格服务。

  • Istio:由 Lyft、IBM 和谷歌联合开发而成,是服务于 Envoy 等代理的“控制平面”。虽然默认是与 Envoy 成对匹配,但是它们都可以与其他平台配对使用。

  • HashiCorp Consul:在 Consul 1.2 版本后,推出了名为 Connect 的功能,这个功能为 HashiCorp 的分布式系统的服务发现和配置部分,添加了服务加密和基于身份的授权的功能。这个使得使 HashiCorp Consul 成为非常完整的服务网格。