如果你正在管理云原生微服务,应该会听说 Service Mesh,并且也了解为何使用 Service Mesh,那么这篇文章就是为你而作。当你开始靠近观察 Service Mesh 的时候,会突然意识到,已经有了多个可选方案了。选哪个呢?你如何分辨不同 Service Mesh 之间的差异,哪个 Service Mesh 更适合你呢?本文以客观、中立的态度来帮助你启动这第一步。
Service Mesh 是一个独立的基础设施层,用于管理服务之间的通信,让这些通信可见可管控。不同产品之间有一些细节差异,但是总的说来,Service Mesh 产品是有一些共同点的。
在上面的基础架构图中,数据面的绿色方框代表着应用,蓝色方框则代表 Service Mesh 的代理服务器,灰色的矩形区域就是应用的端点(Pod、物理机等)了。控制面提供了一个中心化的 API,用于集中控制代理服务器的行为。和控制面的交互是可以自动化的(也就是可以使用 CI/CD Pipeline 来完成),这是用户和 Service Mesh 进行交互的典型方式。
本文中的任何 Service Mesh 都有一些基础功能:
这些功能的细节——如何实现、配置等,各个产品都有差异。但是总的说来,这些要素应该作为 Service Mesh 应该提供的标准功能。本文会着重关注不同产品之间的功能差异。
有了 Service Mesh 的帮助,让分布式应用的可靠性得以提升。在微服务中,服务之间的通信是应用运行质量的决定性因素。过去使用同一运行环境的本地调用变成了通过不可靠网络进行的远端过程调用。反应企业需求的复杂决策树,其成败取决于对分布式系统建设的实际情况的清楚认识。
因此当厂商主张 Service Mesh 的时候,会尝试对远程调用的消息(或者 API 调用)进行管理。因此必然要把 Service Mesh 和其他的消息管理方案例如面向消息的中间件、ESB、EAI 或者 API 网关等进行比较。Service Mesh 和这些产品会有一些功能上的重叠,但是整体上来说,Service Mesh 面向的是一个更大的问题集。
Service Mesh 之所以与众不同,是因为他在应用之外作为基础设施而存在。他的价值主要体现在对 RPC(或者消息)的管理上,但还可以更进一步的管理所有入站出站的流量。无需在应用中编写代码来实现通信管理,而是实现了一系列的互联互通的代理服务器(或 “mesh”),这些代理服务器将逻辑从应用中解耦出来,也将开发人员解放出来。
在观察 Service Mesh 家族中的特定产品之前,回答以下运维和技术问题,能帮助你有一个更加清晰的起步。
当然,这些问题每个人都会有自己的答案,不会存在适合左右人的标准选择。但是在比较产品的功能、设计理念和目标用例的时候,应该对这些问题随时保持警醒。
这篇指南中我们着重关注四个开源产品。我们会使用发布日期进行排序。这里会尝试突出不同产品之间的重要区别。
Linkerd(发音 linker-dee
)由 Buoyant 资助,在 2016 年 2 月发布的。这一产品首先提出了 Service Mesh 这一术语。Linkerd 是一个强大、多平台、功能丰富的 Service Mesh 产品。基于 Twitter 的 Finagle 库构建,Linkerd 用 Scala 编写,在 JVM 上运行,每实例每秒能够处理几万请求。
主要特性包括:
Linkerd 包含一个代理服务器作为数据面,以 Namerd(”namer-dee”)作为控制面,集成在同一个包中。Linkerd 是一个开源项目,同时 Buoyant 还提供了商业支持。截止到 2018 年 4 月,超过 50 个公司在生产环境上运行 Linkerd,Linkerd 具有经过考验的应用案例,为用户处理超过万亿次的服务请求。
Envoy 在 2016 年 10 月由 Matt Klein 以及 Lyft 团队以开源项目的形式发布。这是一个用 C++ 编写的高性能应用,为现代云原生服务架构设计。Envoy 的设计,既可以用作独立的代理服务器,也可以作为 Service Mesh 架构的通用数据面使用。Envoy 的多元化社区由在生产环境中使用 Envoy 的贡献者们构成。
主要特性包括:
Envoy 是一个高级的应用代理服务器,是 Service Mesh 架构中的数据面。Envoy 具有很小的资源占用,因此不管是共享代理还是 Sidecar 代理,Envoy 都能提供很好的支持。Envoy 是社区支持的,也有 Turbine Labs 这样的厂商提供了商业支持。你还会发现 Envoy 被嵌入安全框架、网关或者其他的 Service Mesh 解决方案,例如 Istio。当和 Istio 控制面配合的时候,Envoy 能够提供所有 Service Mesh 的必备功能。
Istio 面世于 2017 年五月,是由 Lyft、IBM 和 Google (还有其他的成员,例如红帽以及很多其他迅速加入的合作伙伴)合作的开源项目。Istio 的设计是要提供一个通用的控制面,用于管理底层大量的服务代理(缺省使用的是 Envoy)。起初 Istio 是针对 Kubernetes 的,但他的底层是平台无关的。Istio 控制面用 Go 语言编写,能够进行扩展。Istio 项目的设计宗旨是性能和规模、移植性,用松耦合的组件来支持弹性部署。
主要特性包括:
Istio 控制面专注于为运维人员提供多种对象进行策略的编制。有很多为不同应用编写的组件,让 Istio 能够匹配到不同的下级数据面上,例如商业授权的 Nginx 代理服务器。Istio 必须和一个底层代理服务器配合工作。
Conduit 在 2017 年 12 月初次发布,同样由 Buoyant 赞助。Conduit 着重为 Kubernetes 用户提供简化的 Service Mesh 使用体验。COnduit 具有轻量级、高性能、安全以及易于理解使用的方便特性。Conduit 由 Rust 编写的数据面和 Go 编写的控制面组成。
主要特性包括:
Conduit 具有一个最小化的架构,以及零配置的设计理念,开箱即用,极少需要用户干预。他的设计来源于对在生产环境中对 Service Mesh 的支持,Conduit 希望能用最小的额外复杂度来解决来自分布式系统管理的问题。
这篇产品设计和功能差异方面的介绍,希望能够帮助读者决定如何踏上 Service Mesh 之旅。这些产品的尝试本身也很有挑战性,我们鼓励用户为自己演示不同的解决方案,从而做出最合适的决策。