下一代的微服务技术Service Mesh简介

📅 2019-08-06 | 🖱️

Service Mesh即服务网格，是云原生核心技术之一。

产生背景 #

Service Mesh伴随着微服务技术发展而产生，由于微服务架构的复杂性，对微服务的治理在服务注册与发现、负载均衡、故障处理与恢复、动态路由请求、协议转换、分布式链路追踪、RPC调用、统一认证授权、服务监控、故障注入、安全加密等方面面临着严峻的挑战。在微服务架构中服务组件复杂、服务治理等都成为了痛点，需要对业务开发人员"隐藏"微服务基础组件和服务治理的复杂性，使其对业务开发人员透明。 微服务本身虽然复杂，但很多的这些复杂性和服务的业务没有关系，即微服务的业务和微服务之间的通信没有关系，那么能否把微服务的技术栈往下移动到通信层呢？Service Mesh随之出现，Service Mesh通过独立进程的方式隔离微服务基础组件，那么对这个独立进程进行运维要比传统的微服务内的基础组件的方式简单的多了。

Service Mesh的产生 #

在2016年9月由开发Linkerd的Buoyant公司提出。2017年Linkerd加入CNCF，成为第一个加入CNCF的Service Mesh项目。 Service Mesh渐渐变得流行起来，有人提出Servic Mesh是下一代微服务架构的基础。

Service Mesh的定义 #

Service Mesh是用于处理服务到服务通信的专用基础架构层。云原生有着复杂的服务拓扑，Service Mesh负责可靠的传递请求。实际上，Service Mesh通常是作为一组轻量级网络代理实现，这些代理与应用程序代码部署在一起，应用程序无感知。

Service Mesh将原来在客户端SDK中的基础能力下移到通信层，即将客户端SDK从剥离以Proxy进程运行，为应用减轻了负担。绝大部分Service Mesh的实现都支持Kubernetes，Service Mesh已经发展成为一个独立的基础设施层。

Sidecar模式 #

一个应用系统可能有数百个微服务组成，每个服务又部署为多个实例，这些微服务由Kubernetes这样的资源调度管理系统动态调度，Service Mesh在Kubernetes中被实现为Sidecar边车模式，Proxy进程就好比连接到摩托车旁边的边车一样。Sidecar模式的定义是指将应用程序的组件部署到单独的进程或容器中以提供隔离和封装，可以看出这种模式可以使应用程序由异构技术实现，sidecar和应用程序本身可以使用不同的技术。

Service Mesh的开源项目 #

Istio由Google、IBM和Lyft开源，在Istio中使用了Lyft公司的Envoy作为Sidecar。Istio的功能十分丰富，包含以下4个方面:

• 流量管理: 流量管理是istio的基本功能，使用istio的流量路由规则可以轻松控制服务之间的流量和API调用
• 策略控制: 应用策略以确保其得到执行，并且资源在消费者之间公平分配
• 可观测性: 通过自动链路追踪、监控和服务的日志可以全面了解服务如何与其它服务以及istio组件本身进行交互
• 安全认证: 通过托管的身份认证、授权和服务之间通信的加密自动保护服务的安全。Istio Security提供了全面的安全方案来解决这些问题。

Linkerd由Buoyant公司开源，最早的版本用Scala语言开发，是业界第一个Service Mesh。Linkerd的架构也是由数据平面和控制平面组成。数据平面由轻量级代理组成，它们作为Sidecar容器与服务代码的每个实例一起部署。控制平面是一组默认情况下在专用Kubernetes命名空间中运行的服务。 Linkerd 1作为开源Service Mesh的先驱，在生产环境得到了大量的使用。 Linkerd 2定位为Kubernetes的Service Mesh，其提供了运行时调试、可观测性、可靠性和安全性，使运行服务更容易、更安全，而且无需修改代码。

Envoy：由Lyft公司开源，使用C++开发，在性能和资源消耗上表现十分优秀。Envoy将自身定位为数据屏幕，并希望使用者可以通过控制平面来为Envoy提供动态配置。

总结 #

大规模的微服务使得系统的复杂度和治理难度增加，虽然微服务架构在微服务治理上提供了解决方案，但这些方案的框架和技术组件基本上都具有侵入性，需要在业务服务内部集成服务治理组件，因此对于微服务规模较大、内部服务存在异构的场景，推荐使用Service Mesh，可以将业务之外的功能都交给Service Mesh去做，Service Mesh成为微服务的基础设施。但Service Mesh不是银弹，它也有以下缺点:

• Service Mesh Sidecar代理请求转发，在一定程度上会降低系统通信性能
• 之前侵入微服务业务代码实现的服务治理功能有较大的扩展性，而Service Mesh不易扩展
• 系统的稳定性依赖于Service Mesh代理组件，多了一个故障点