服务调用流程服务调用异常请检查业务参数( 二 ) _服务

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

使用json或者xml这样的数据格式。好处是可视性强，表达起上面的复杂类型也方便，缺陷是容易被破解，传输过去的数据较大。
自定义二进制协议。每个公司做大了，在这一块难免有几个类似的轮子。笔者见过比较典型的是所谓的TLV格式（Type-Length-Value），自定义二进制格式最大的问题出现在协议联调与协商的时候，由于可视性比较弱，有可能这边少了一个字段那边多了一个字段，给联调流程带来麻烦。

上面的问题一直到Google的Protocol Buffer（以下简称PB）出现之后才得到很大的改善。PB出现之后，也有很多类似的技术出现，如Thrift、MsgPack等，不在这里阐述，将这一类技术都以PB来描述。
与前面的两种手段相比，PB具有以下的优点：

使用proto格式文件来定义协议格式，proto文件是一个典型的DSL（domain-specific language）文件，文件中描述了协议的具体格式，每个字段都是什么类型，哪些是可选字段哪些是必选字段。有了proto文件之后，C\S两端是通过这个文件来进行协议的沟通交流的，而不是具体的技术细节。
PB能通过proto文件生成各种语言对应的序列化反序列化代码，给跨语言调用提供了方便。
PB自己能够对特定类型进行数据压缩，减少数据大小。

文章插图
服务网关
有了前面的演化之后，写一个简单的单机服务器已经不难。然而，当随着访问量的增大，一台机器已经不足以支撑所有的请求，此时就需要横向扩展多加一些业务服务器。
而前面通过域名访问服务的架构就遇到了问题：如果有多个服务实例可以提供相同的服务，那么势必需要在DNS的域名解析中将域名与多个地址进行绑定。这样的方案就有如下的问题：

如何检查这些实例的健康情况，同时在发现出现问题的时候增删服务实例地址？即所谓的服务高可用问题。
把这些服务实例地址都暴露到外网，会不会涉及到安全问题？即使可以解决安全问题，那么也需要每台机器都做安全策略。
由于DNS协议的特点，增删服务实例并不是实时的，有时候会影响到业务。

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

负载均衡功能：根据某些算法将请求分派到服务实例上。
提供管理功能，可以给运维管理员增减服务实例。
由于它决定了服务请求流量的走向，因此还可以做更多的其他功能：灰度引流、安全防攻击(如访问黑白名单、卸载SSL证书)等。

文章插图
有四层和七层负载均衡软件，其中四层负载均衡这里介绍LVS，七层负载均衡介绍Nginx 。

文章插图
上图是简易的TCPIP协议栈层次图，其中LVS工作在四层，即请求来到LVS这里时是根据四层协议来决定请求最终走到哪个服务实例；而Nginx工作在七层，主要用于HTTP协议，即根据HTTP协议本身来决定请求的走向。需要说明的是，Nginx也可以工作在四层，但是这么用的地方不是很多，可以参考nginx的stream模块。
做为四层负载均衡的LVS（由于LVS有好几种工作模式，并不是每一种我都很清楚，以下表述仅针对Full NAT模式，下面的表述或者有误）
LVS有如下的组成部分：