基于Service Mesh构建更现代的服务架构

前言

传统业务模型中，客户端和服务端之间放置一个负载均衡器，比如nginx。我们的客户端可以是移动程序或者web系统。

当服务端部署的是单体系统的时候，我们只需要在负载均衡器之后对应用部署多个单体实例。随着系统一步步抽取解耦成很多微服务，就需要将整个运行架构的某些方面进行智能化升级。

Service Mesh的作用

首当其冲的就是采用一个灵敏的API网关，如果这个网关可以做到智能化负载均衡，服务端的服务再怎么升级都不会影响到客户端的体验。

Service mesh的理想状态是，所有服务应该是很小的，并可以相互连接起来。在分布式系统中，网络是一个非常不可靠的因素，网络可能会很慢，有延迟，可能宕机，总之网络的各种问题可能影响我们服务的稳定性。

在微服务体系中，每个团队都维护自己的服务，并进行独立部署，当网络出现问题时，可以针对微服务进行降级。

Service mesh不是一种技术，而是一种设计模式，我们可以通过多种方式来实现Service Mesh。但通常情况下，我们都有一个代理和服务一起运行，通过这些代理可以将不可靠的网络变得可靠。所以我们就可以不需要担心如何处理因网络造成的延迟问题，可用性问题了。

基础概念

Service Mesh最核心有两个概念：数据面和控制面。

有了代理之后，服务之间的连接不是互相直接连服务了，而是连接到数据平面上，通过数据平面互相通信。由于数据平面可以在服务无感知的情况下执行逻辑，那么可以在这里进行异常，延迟和可观测性处理。

在Service Mesh中，数据平面即是代理也是反向代理，这取决于请求的去向。如果服务A想调用其他服务B，那么这个数据平面就是代理，因为服务A的请求通过数据平面进行了代理才可以。当服务B受到请求并作出响应，那么这个数据平面就是一个反向代理，将接收的请求代理到与之关联的服务上。

数据面

数据面负责做网络代理，在服务请求到链路上做一层拦截与转发，可以在核心链路上实现服务路由，链路加密，服务鉴权等。

技术实现可以采用Golang进行高性能网络代理的研发，承载核心应用流量。

控制面

控制面负责做服务发现，服务路由管理，请求度量等。

集合K8s

我们可以将每个服务器上的服务实例提供一个数据平面，也叫sidecar。总的来说就是每个服务都会首先转到数据平面，又数据平面接收请求。服务之间不再直接通信，有了数据平面，我们可以在其中实现额外的逻辑，所有团队开箱即用。

实现了Service Mesh之后，我们就区别了之前代理实例中心化了，而是将其分散到各个服务中。在k8s中对底层虚拟机进行了抽象，通过部署pods将虚拟机群变得看起来像一台机器。

我们可以告诉k8s产生一个sidecar容器，可以实现每个部署service的pod里面都有一个sidecar容器。这样可以实现服务之间一直在localhost上进行，因为请求没有进入到外部网络，一直在虚拟机群中。

因为我们需要在系统中为每个服务都部署一个代理，所以代理需要足够小，不能造成过多的资源消耗和内存消耗。当我们实现了每个服务都有自己的数据平面之后，需要可以对这些数据平面进行配置，而不希望以人工的方式进行升级。于是就引入了控制平面。

通过控制面板统一管理配置，之后推送到所有的数据面板。同时数据面板收集的数据会上报到控制面板。控制面板仅用来提供配置，获取数据指标，其不会出现在一个请求路径上。

事件驱动架构

微服务之间的通信不是唯一的通信方式，还有一种基于事件的体系架构可以创建他们。我们可以在系统中传播一个事件，并以更有效的方式来处理如状态捕获之类的事情。对于一些可以异步处理的情况来说，可以考虑使用事件方式。同样我们可以在事件收集器（如kafka）之前加一个数据平面，以确保服务事件能够到达事件收集器（kafka）。

我们可以用神经系统比喻未来的架构，大脑中有中暑神经系统和周围神经系统组成。周围神经系统可以将身体能够理解的所有信息存起来，然后传递给中枢神经系统，在中枢神经系统中进行信息处理。

这种概念和数据面板，控制面板很相似。数据平面位于每个服务旁进行数据采集，控制平面有相关配置，监控，可观察性。

网络两跳的问题

由于引入了数据平面，对于原有的进程调用增大了延迟，这种情况可以通过管理平面获取的数据指标以了解延迟和瓶颈的正确位置，造成延迟的原因可能不仅仅是网络，还有其他原因，如果需要通过网络，发现本地函数调用更多的延迟以优化，这是可以的。

我们可以在数据面板缓存一些信息，这样请求可以不需要进入到外部网络，如果这是可行的也可以降低延迟。

对于大部分架构来说，可以接受最终一致性，延迟只是他的一部分。在实际情况来说，我们需要基于网络请求，判断哪些延迟是正常的，哪些是不正常的，如果不正常就必须确保系统的最终一致性，并以此为前提构建客户端。

Service Mesh实践

在实践上参考下蚂蚁金服的Service Mesh实践，管中窥豹。

核心链路的诉求

在面对核心链路大促大流量场景的需求下，解决链路稳定性是极大的挑战。

能力支持

Service Mesh作为底层高性能网络代理，支撑RPC，MSG，Gateway等业务场景。

IO模型

Service Mesh在实现上，支持两种IO模型，一个是Golang经典模型，goroutine-per-connection；一个是RawEpoll模型，就是经典的Reactor模式，IO多路复用+非阻塞IO模式。

对于服务化场景来说可以选择Golang经典模型。

对于接入层和网关有大量长链接的场景，更适合RawEpoll模型。

Golang协程模型

- 一条TCP连接对应一个Read协程，执行收包和协议解析；

- 一个请求对应一个worker协程，执行业务处理，proxy和write逻辑；

常规模型一个TCP连接有Read/Write两个协程，可以取消单独到Write协程，让workerpool工作协程代替，以减少调度延迟和内存占用。

扩展能力

通过plugin机制，支持协议扩展，如：Http1/Http2，Dubbo等协议。

链路安全

对于链路加密，可以采用Go的TLS实现。

内存复用

采用：sync.Pool，slice复用使用slab细粒度，提高复用率，常用结构体复用。

动态配置能力

基于Json提供统一数据面API。

关于Go

在版本上选择最新的1.12.6，其修改了内存回收的默认策略。

- GC优化，减少长尾请求。采用自我抢占机制，将耗时较长的GC标记过程打散，换取更为平滑的GC表现，减少对业务延迟的影响。

最后

从技术上来说，微服务不一定必须通过service mesh来做，但如果你想拥有这些优点，这样做最好。service mesh的实现也不一定需要k8s，但service mesh理念可以应用于任何平台。k8s可以让我们大规模运行微服务，不同服务可以用不同语言开发，这也是微服务的优势之一。