这个题目稍微有点大,纯粹是一篇科普文,将我所了解到的解决“服务调用”相关的技术演进历史简述一下,本文专注于演化过程中每一步的为什么(Why)和是什么(What)上面,尽量不在技术细节(How)上面做太多深入。
一般而言,一个网络服务包括以下的三个要素:
需要说明在服务地址中:
这都属于TCPIP协议栈的知识点,不再这里深入详述。
这里还需要对涉及到服务相关的一些名词做解释。
最初的网络服务,通过原始的IP地址暴露给调用者。这种方式最大的问题在于,IP地址是难于记忆并且无意义的,在现在除非是测试阶段,否则已经不能直接以IP地址的形式将服务提供出去了。
前面的IP地址是给主机做为路由器寻址的数字型标识,并不好记忆。此时产生了域名系统,与单纯提供IP地址相比,域名系统由于使用有意义的域名来标识服务,所以更容易记忆。有了域名之后,调用方需要访问某个网络服务时,首先到域名地址服务中,根据DNS协议将域名解析为相应的IP地址,再根据返回的IP地址来访问服务。
从这里可以看到,由于多了一步到域名地址服务查询映射IP地址的流程,所以多了一步解析,为了减少这一步带来的影响,调用方会缓存解析之后的结果,在一段时间内不过期,这样就省去了这一步查询的代价。
以上通过域名系统,已经解决了服务IP地址难以记忆的问题,下面来看协议格式解析方面的演进。
一般而言,一个网络协议包括两部分:
无论是HTTP协议,又或者是自定义的二进制网络协议,大体都由这两部分组成。
由于很多时候不能一口气接收完毕客户端的协议数据,因此在接收协议数据时,一般采用状态机来做协议数据的接收:
接收完毕了网络数据,在协议解析方面却长期停滞不前。一个协议,有多个字段(field),而这些不同的字段有不同的类型,简单的raw类型(如整型、字符串)还好说,但是遇到复杂的类型如字典、数组等就比较麻烦。
当时常见的手段有以下几种:
上面的问题一直到Google的Protocol Buffer(以下简称PB)出现之后才得到很大的改善。PB出现之后,也有很多类似的技术出现,如Thrift、MsgPack等,不在这里阐述,将这一类技术都以PB来描述。
与前面的两种手段相比,PB具有以下的优点:
有了前面的演化之后,写一个简单的单机服务器已经不难。然而,当随着访问量的增大,一台机器已经不足以支撑所有的请求,此时就需要横向扩展多加一些业务服务器。
而前面通过域名访问服务的架构就遇到了问题:如果有多个服务实例可以提供相同的服务,那么势必需要在DNS的域名解析中将域名与多个地址进行绑定。这样的方案就有如下的问题:
为了解决这些问题,就引入了反向代理网关这一组件。它提供如下的功能:
有四层和七层负载均衡软件,其中四层负载均衡这里介绍LVS,七层负载均衡介绍Nginx。
上图是简易的TCPIP协议栈层次图,其中LVS工作在四层,即请求来到LVS这里时是根据四层协议来决定请求最终走到哪个服务实例;而Nginx工作在七层,主要用于HTTP协议,即根据HTTP协议本身来决定请求的走向。需要说明的是,Nginx也可以工作在四层,但是这么用的地方不是很多,可以参考nginx的stream模块。
(由于LVS有好几种工作模式,并不是每一种我都很清楚,以下表述仅针对NAT模式,下面的表述或者有误)
LVS有如下的组成部分:
客户端进行请求时,流程如下:
在开始展开讨论之前,需要简单说一下正向代理和反向代理。
所谓的正向代理(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访问接口的服务架构大体是这样的:
前面已经解决单机服务器对外提供服务的大部分问题,来简单回顾:
然而一个服务,通常并不见得只由本身提供服务就可以,服务过程中可能还涉及到查询其他服务的流程,常见的如数据类服务如Mysql、Redis等,这一类供服务内调用查询的服务被成为内部的服务,通常并不直接暴露到外网去。
面向公网的服务,一般都是以域名的形式提供给外部调用者,然而对于服务内部之间的互相调用,域名形式还不够,其原因在于:
综上,内网间的服务调用,通常而言会自己实现一套“服务发现”类的系统,其包括以下几个组件:
有了这套服务发现系统以及搭配使用的RPC库之后,来看看现在的服务调用是什么样的。
现在服务的架构又演进成了这样:
架构发展到上面的程度,实际上已经能够解决大部分的问题了。这两年又出现了一个很火的概念:ServiceMesh,中文翻译为“服务网格”,来看看它又能解决什么问题。
前面的服务发现系统中,需要一个与之配套的RPC库,然而这又会有如下的问题:
可以看到,由于RPC库是嵌入到进程之中的组件,所以以上问题很麻烦,于是就想出了一个办法:将原先的一个进程拆分成两个进程,如下图所示。
在服务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的调用,如何权衡又是另外的问题了。