导读:RPC,微服务,Service Mesh这些服务之间的调用是什么原理?

作者 codedump codedump.info 博主,多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。

本文专注于演化过程中每一步的为什么(Why)和是什么(What)上面,尽量不在技术细节(How)上面做太多深入。

服务的三要素

一般而言,一个网络服务包括以下的三个要素:

需要说明在服务地址中:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(1)

这都属于TCPIP协议栈的知识点,不在这里深入详述。

这里还需要对涉及到服务相关的一些名词做解释。

基于IP地址的调用

最初的网络服务,通过原始的IP地址暴露给调用者。这种方式有以下的问题:

“尽量不使用过于底层的概念来提供服务”,是这个演化流程中的重要原则,好比在今天已经很少能够看到直接用汇编语言编写代码的场景了,取而代之的,就是越来越多的抽象,本文中就展现了服务调用这一领域在这个过程中的演进流程。

在现在除非是测试阶段,否则已经不能直接以IP地址的形式将服务提供出去了。

域名系统

前面的IP地址是给主机做为路由器寻址的数字型标识,并不好记忆。此时产生了域名系统,与单纯提供IP地址相比,域名系统由于使用有意义的域名来标识服务,所以更容易记忆。另外,还可以更改域名所对应的IP地址,这为变换机器提供了便利。有了域名之后,调用方需要访问某个网络服务时,首先到域名地址服务中,根据DNS协议将域名解析为相应的IP地址,再根据返回的IP地址来访问服务。

从这里可以看到,由于多了一步到域名地址服务查询映射IP地址的流程,所以多了一步解析,为了减少这一步带来的影响,调用方会缓存解析之后的结果,在一段时间内不过期,这样就省去了这一步查询的代价。

协议的接收与解析

以上通过域名系统,已经解决了服务IP地址难以记忆的问题,下面来看协议格式解析方面的演进。

一般而言,一个网络协议包括两部分:

无论是HTTP协议,又或者是自定义的二进制网络协议,大体都由这两部分组成。

服务相互调用有啥问题(终于有人把服务调用说清楚了)(2)

由于很多时候不能一口气接收完毕客户端的协议数据,因此在接收协议数据时,一般采用状态机来做协议数据的接收:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(3)

接收完毕了网络数据,在协议解析方面却长期停滞不前。一个协议,有多个字段(field),而这些不同的字段有不同的类型,简单的raw类型(如整型、字符串)还好说,但是遇到复杂的类型如字典、数组等就比较麻烦。

当时常见的手段有以下几种:

上面的问题一直到Google的Protocol Buffer(以下简称PB)出现之后才得到很大的改善。PB出现之后,也有很多类似的技术出现,如Thrift、MsgPack等,不在这里阐述,将这一类技术都以PB来描述。

与前面的两种手段相比,PB具有以下的优点:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(4)

服务网关

有了前面的演化之后,写一个简单的单机服务器已经不难。然而,当随着访问量的增大,一台机器已经不足以支撑所有的请求,此时就需要横向扩展多加一些业务服务器。

而前面通过域名访问服务的架构就遇到了问题:如果有多个服务实例可以提供相同的服务,那么势必需要在DNS的域名解析中将域名与多个地址进行绑定。这样的方案就有如下的问题:

为了解决这些问题,就引入了反向代理网关这一组件。它提供如下的功能:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(5)

有四层和七层负载均衡软件,其中四层负载均衡这里介绍LVS,七层负载均衡介绍Nginx。

服务相互调用有啥问题(终于有人把服务调用说清楚了)(6)

上图是简易的TCPIP协议栈层次图,其中LVS工作在四层,即请求来到LVS这里时是根据四层协议来决定请求最终走到哪个服务实例;而Nginx工作在七层,主要用于HTTP协议,即根据HTTP协议本身来决定请求的走向。需要说明的是,Nginx也可以工作在四层,但是这么用的地方不是很多,可以参考nginx的stream模块。

做为四层负载均衡的LVS

(由于LVS有好几种工作模式,并不是每一种我都很清楚,以下表述仅针对Full NAT模式,下面的表述或者有误)

LVS有如下的组成部分:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(7)

客户端进行请求时,流程如下:

  1. 使用VIP地址访问DS,此时的地址二元组为<src:CIP,dst:VIP>。

  2. DS根据自己的负载均衡算法,选择一个RS将请求转发过去,在转发过去的时候,修改请求的源IP地址为DIP地址,让RS看上去认为是DS在访问它,此时的地址二元组为<src:DIP,dst:RIP A>。

  3. RS处理并且应答该请求,这个回报的源地址为RS的RIP地址,目的地址为DIP地址,此时的地址二元组为<src:RIP A,dst:DIP>。

  4. DS在收到该应答包之后,将报文应答客户端,此时修改应答报文的源地址为VIP地址,目的地址为CIP地址,此时的地址二元组为<src:VIP,dst:CIP>。

做为七层负载均衡的Nginx

在开始展开讨论之前,需要简单说一下正向代理和反向代理。

所谓的正向代理(proxy),我的理解就是在客户端处的代理。如浏览器中的可以配置的访问某些网站的代理,就属于正向代理,但是一般而言不会说正向代理而是代理,即默认代理都是正向的。

而反向代理(reverse proxy)就是挡在服务器端前面的代理,比如前面LVS中的DS服务器就属于一种反向代理。为什么需要反向代理,大体的原因有以下的考量:

反向代理与所谓的gateway、网关等,我认为没有太多的差异,只是叫法不同而已,做的事情都是类似的。

Nginx应该是现在用的最多的HTTP 七层负载均衡软件,在Nginx中,可以通过在配置的server块中定义一个域名,然后将该域名的请求绑定到对应的Upstream中,而实现转发请求到这些Upstream的效果。

如:

upstream hello { server A:11001; server B:11001;}location / { root html; index index.html index.htm; proxy_pass http://hello;}

这是最简单的Nginx反向代理配置,实际线上一个接入层背后可能有多个域名,如果配置变动的很大,每次域名以及对应的Upstream的配置修改都需要人工干预,效率会很慢。这时候就要提到一个叫DevOps的名词了,我的理解就是开发各种便于自动化运维工具的工程师。

有了上面的分析,此时一个提供七层HTTP访问接口的服务架构大体是这样的:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(8)

服务发现与RPC

前面已经解决单机服务器对外提供服务的大部分问题,来简单回顾:

然而一个服务,通常并不见得只由本身提供服务就可以,服务过程中可能还涉及到查询其他服务的流程,常见的如数据类服务如Mysql、Redis等,这一类供服务内调用查询的服务被成为内部的服务,通常并不直接暴露到外网去。

面向公网的服务,一般都是以域名的形式提供给外部调用者,然而对于服务内部之间的互相调用,域名形式还不够,其原因在于:

综上,内网间的服务调用,通常而言会自己实现一套“服务发现”类的系统,其包括以下几个组件:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(9)

有了这套服务发现系统以及搭配使用的RPC库之后,来看看现在的服务调用是什么样的。

现在服务的架构又演进成了这样:

服务相互调用有啥问题(终于有人把服务调用说清楚了)(11)

ServiceMesh

架构发展到上面的程度,实际上已经能够解决大部分的问题了。这两年又出现了一个很火的概念:ServiceMesh,中文翻译为“服务网格”,来看看它又能解决什么问题。

前面的服务发现系统中,需要一个与之配套的RPC库,然而这又会有如下的问题:

可以看到,由于RPC库是嵌入到进程之中的组件,所以以上问题很麻烦,于是就想出了一个办法:将原先的一个进程拆分成两个进程,如下图所示。

服务相互调用有啥问题(终于有人把服务调用说清楚了)(12)

在服务mesh化之前,服务调用方实例通过自己内部的RPC库来与服务提供方实例进行通信。

在服务mesh化之后,会与服务调用方同机部署一个local Proxy也就是ServiceMesh的proxy,此时服务调用的流量会先走到这个proxy,再由它完成原先RPC库响应的工作。至于如何实现这个流量的劫持,答案是采用iptables,将特定端口的流量转发到proxy上面即可。

有了这一层的分拆,将业务服务与负责RPC库作用的Proxy分开来,上面的两个痛点问题就变成了对每台物理机上面的mesh proxy的升级维护问题,多语言也不是问题了,因为都是通过网络调用完成的RPC通信,而不是进程内使用RPC库。

然而这个方案并不是什么问题都没有的,最大的问题在于,多了这一层的调用之后,势必有影响原来的响应时间。

截止目前(2019.6月),ServiceMesh仍然还是一个概念大于实际的产品。

从上面的演进历史可以看到,所谓的“中间层理论”,即“Any problem in computer science can be solved by another layer of indirection(计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决)”在这个过程中被广泛使用,比如为了解决IP地址难于记忆的问题,引入了域名系统,比如为了解决负载均衡问题引入了网关,等等。然而每引入一个中间层,势必带来另外的影响,比如ServiceMesh多一次到Proxy的调用,如何权衡又是另外的问题了。

另外,回到最开始的服务三要素中,可以看到整个演化的历史也是逐渐屏蔽了下层组件的流程,比如:

可以看到,演进流程让业务开发者更加专注在业务逻辑上,这类的演进流程不只发生在今天,也不会仅仅发生在今天,未来类似的演进也将再次发生。

高可用架构

改变互联网的构建方式

,