高性能协议与RPC - phptars助力起点改造

 阅文集团的起点改造项目中，我们一度遇到了非常多的挑战，其中包括http协议的过分冗余以及上层封装带来的性能损耗。我们不但要应对同步的http的调用库所带来的吞吐量的极大下降，还要应对JSON 、XML 协议在信息传输上的低效率。

为了解决这一问题，我们必须要引入在 TCP 协议层的，简单封装的，二进制协议。才能保证用更少的传输带宽，承载更多的传输内容。

同时，在实际开发的层面上，还有 PHP 逻辑层 Server 之间通信协议文件的维护成本非常之高。有文档维护界面的还好，对于没有落地文档的接口，协议往往都只存在在代码当中。而当团队出现人员变动之后，这个代码的维护难度极大。

同时， Server 侧新增或修改接口字段，往往 Client 侧也要配合修改，很多时候无法保证接口的完全兼容而引发线上的运营问题。因此，我们必须要引入一种接口方便维护，同时又容易扩展的二进制协议。

除此之外，从开发效率上而言，原本的协议开发总是包含大量的重复的，但又不得不去做的工作内容。每一次新协议的开发，能够复用的部分非常之少。而且一个很现实的问题是，不同 Http 接口的提供方，往往会视自己的心情来定义接口。常见的例子就是对返回码的定义，有些人叫ret，有些人叫code，还有些人就叫r。就跟到了菜市场，简直是无所不包。

因此这类重复无趣的开发工作，给客户端的开发同学带来了极大的生理和心理负担，以至于他们不得不经常问 我是谁，我在哪儿，我为啥要写这种代码 这样的问题。基于这种需求，我们必须要引入一种 Server 和 Client 端都能够根据协议自动生成接口代码，保证联调舒爽通畅的解决方案。

再者，Client 对后端服务的发现和调用的上报与监控，也是一个老生常谈的问题。后端服务如何被发现，后端的接口如何被发现，这都是调用方需要解决的。同时，Client 端非常有必要对后端服务的调用情况进行上报到中央服务器，中央服务器在根据收集上来的信息，对后端服务的负载进行动态的调整，保证服务的高可用。要实现这样的需求，我们必须引入一种集成了监控、主控寻址、上报通道、负载均衡功能的解决方案。

如果有一种方案，可以满足上述的所以需求，那简直就是难以置信。兼具了简单高效、接口维护方便又容易扩展的二进制协议、同时满足server与client端代码根据协议自动生成，以及集成了寻址、服务发现、监控、上报功能。这么多的优势和特性，非我们今天要介绍的 phptars 莫属。

要了解 phptars 的开源方案，就要从二进制的协议说起了：

HTTP 协议可能是在应用层上最为广泛的协议了。现有 HTTP 的版本主要是1.0和1.1版本。它在 TCP 的基础上做了十分简洁的应用层协议封装，纯文本的内容，以及 header 和 body 的天然隔离。都使得这种协议的使用十分的方便。但是不可避免的，用户使用的简单意味着信息的冗余，为了传输少量的内容，往往需要耗费大量的流量。

另外两个大家熟知的协议，就是 JSON 和 XML 了，这两位在 WEB 交互常用的协议中不分上下，可读性强、容易理解、语言客户端支持丰富、协议表述能力突出，都是两者的优势所在。说真的，我都不知道他们两个差别何在，很可能是重复造轮子的产物。不过不管怎么样，我们先看看同样一段信息，两者需要的数据量。

假定有一所学校，两个学生和一个老师，如果用 JSON 标识的话，如下所示：

很简单的结构，共需要122个字符来表述。而如果换成 XML ：

则一共需要181个字符。从信息学的角度而言，信息熵明显就是太低了。所以为了实现通信的更高性能和更少带宽的使用，二进制协议的引入势在必行。

说到二进制协议，最赫赫有名的肯定是谷歌退出的protocol buffer了，而今天我们要着重介绍的是腾讯MIG推出的 tars 协议。从上文中的 JSON 和 XML 中我们发现他们的灵活性，也就是没有指定字段的类型，但是不可避免的，这种灵活带来了性能的大损失。因此 tars 定义了八种基本的数据类型，通过对不同的数据类型进行编码优化：

bool、byte、short、int、long、float、double、string

而同时为了满足业务需求，扩展出了struct（包含任意字段）、vector（数组）、map（key-value结构）这三种可以嵌套数据，丰富协议表现力的复杂类型。

按照上文的表现结构，几个struct就可以完成。

首先是 student 结构体：

从注释中可以看到，三个字段需要的字节数为14，再加上结构体的开始和结构体结束的标识共2个字节，一共只需要16个字节而已。加上另一位老师的信息，一共不超过30个字节。相比之下，这仅仅是 JSON 的1/4，是 XML 协议标识同样信息的1/5，高下立判. 巧妙地用协议强约定换传输可读性，这就是高信息熵的二进制协议的诀窍。

有了这么强力的二进制协议，那么 PHP 必须通过开发高效的客户端来充分利用之。不过，PHP 语言本身被诟病最多的，就是针对 CPU 密集型的运算的低效率。由于并不十分高效的 ZEND 虚拟机、松散的数据结构和弱类型的存在，使得打包、解包这类字符串操作型的效率很低下。

基于这个原因，php扩展应运而生。通过引入高性能的 C/C++ 类库，使得 PHP 在性能处理方面迎头赶上。这也就是我们设计 pptars 扩展的初衷。

我们来看看 PHP 语言的结构：

最底层的Server API用来 PHP 与webserver通信，这个主要是之前与 Apache 配合需要使用的。在其左上的phpcore层，是为了提供最基本的文件和网络操作的能力。而右上的 ZEND，则是用来把 PHP 的脚本语言编译成机器码的工具。

最上面就是我们的扩展层了，这层会充分利用 ZEND 的api和phpcore的能力，直接写出zend能够高效执行和理解的代码，省去了 PHP 脚本编译为机器码的过程，从而大大的提高执行的效率。

如果要设计phptars扩展，我们必须要将上文中tars的数据结构通过C语言的方式加以表达，同时设计出基于这套数据结构的编码器与解码器。另一个需要考虑的方面是，必须要使得在 PHP 层面尽可能的简单、易用，这就对我们设计扩展的时候提出了比较高的挑战。通过参考赫赫有名的 Google 的protobuf的设计思想，我们成功的将tars中的struct，进行了 PHP 中的class的表达:

而从图中可以清晰的看到，结构体SimpleStruct被我们分解成了三个部分：

•  tag 部分

• 成员变量部分

• 变量描述的 fields

tag部分至关重要，这部分被我们用来代表 struct 中每个元素的 tag 值。这也是我们实际进行 tars 编码和解码的时候，二进制包里面最终包含的内容。为什么要有 tag ？这是因为相比于 json 里面对字段的文本性质的描述， tag 本身更节省空间。

第二部分则是类的成员变量，这部分成员变量和 tars 的 struct 中的变量一一对应。这是为了承载对应变量的实际值而存在的。只有靠他们我们才能对真正的数据进行打包和解包。

为了在 tag 和变量之间搭起一座桥梁，我们就有了第三个部分。也就是最重要的 fields 部分。这部分是 tag 与其对应的变量属性的一个映射。抱哈拿了变量的名称、变量是否必填以及变量的类型。通过这些信息，一方面我们实现了对 tars 协议的二进制编码，也实现了解码时候的映射。可谓一举两得。

那么经过复杂的扩展设计与实现，我们有必要将扩展实现的打包解包性能和原生PHP 实现的打包解包性能进行比对。从下面的表格中可以非常明显的看出扩展实现拥有性能上面的绝对优势：

从这个表格中可以非常清晰的看到，无论是简单的tars，还是复杂的tars，使用扩展进行打包解包都比原生 PHP 的性能提高十倍以上。当我们遇到复杂的业务逻辑，需要调用大量的使用 tars 协议的后台服务的时候，这种效率的提升会让我们服务的吞吐量上一个数量级。

刚刚提到，除了对打包解包性能的极致追求之外，我们还必须考虑到php使用时的友好性。基于这一点，非常有必要实现一整套从 tars 到 PHP 文件的自动生成与转换的工作。

使用协议的同学，只需执行一个命令，即可将打包解包所必须的文件生成完毕，再经过简单的调试，就能完成一次协议的开发，从而大大降低了之前人工撰写的成本。把人力聚焦在更值得他们做的事情上面。

转换为：

要实现这一点，对 tars 文件的处理必不可少。这种转换与自动生成的工作，如果要做的足够健壮，那么一定不能使用生硬的正则匹配。而是必须要从编译原理的角度去考虑，即是：如果你要做一个 tars 语言的初级编译器，你会如何去实现？

下面给出我们设计的整个工具系统的结构：

具体针对 tars 的语法而言的话，第一点，是对 tars 文件进行正确的分词，只有把每个有意义的词或者是符号正确的分开，才能为后续的生成打下基础。如结构体中的0 required string name=1，我们必须区分出从左至右的每一个字段分别为tag require_type parameter_type parameter_name default_value，这一步所依赖的最重要的就是构词的规则，哪些词是 tars 语法的关键词，哪些是停止词，哪些是可以忽略的词，都需要在规则中明确下来。

第二点则是对分出来的词进行语法的分析，我们必须知道，哪些词是参数类型，哪些词是可以忽略的。同时还有很重要的一点是，现有分出来的词是否符合特定的语法。比如在分号之后，重复的出现 tars 中的 tag 字段，这肯定是不合法的。

或者还有出现大括号无法前后对应的情况，这也是对语法规则的一种违背。只有这一步保证了语法的正确性，才能进行下一步，也是最终的一步，对于语义的分析。

语义分析是需要结合上下文才能正确完成的事情，这与第二点存在一些依赖，但又不完全相同。我们在判断某个词是什么的时候，不单单需要依赖词本身的信息和语法规则带来的信息，还需要依赖词的上下文的信息。

如果一个数组出现在头部，那么我们认为它是 tag ，而如果一个数字出现在尾部等号的后面，那么我们认为它就是一个默认值。而这种基于对上下文的判断，必须引入状态机来保证流转的顺畅性。

下面就给出对 tars 中的 struct 的一行数据进行状态转换的状态机示例： 

正如图中所示，通过状态的流转，我们能够顺利的完成分词，以及对词语具体类型的解释。从而将其映射为 php 文件中相应的类、变量、函数等等。可以毫不夸张的说，通过这个工具的优化，原有一次接入 tars 服务的开发时间，从小时的级别，降低到了分钟的级别，大大提高了起点改造过程中的工作效率。

在起点后台的服务治理完成之后，大部分我们与后台之间的数据交换，已经从 http 切换成了基于 tars 协议的 tcp 网络传输。如此多的服务，那就势必遇到如下的几个问题：

1. 如何对服务的调用情况进行监控告警

2. 如何管理每个服务的调用地址和负载均衡

依托于强大的米格监控系统，我们在底层集成了对每个 tars 服务的调用耗时和成功率的统计。只需选择不同的业务，那么当前业务下的所有调用的服务和接口，以及他们的频率、耗时和成功率都是一目了然。

对于远程服务的地址管理，最差的方案就是将其写入本地文件中。这种方案无法应对快速缩扩容以及服务器下线的需求，会给后续的运维带来很大的工作量。

稍微好一些的方案是本地存储虚拟IP，那么每次只需要调整虚拟IP，就可以实现服务地址的自动映射和变化。但是这意味着对要调用的每一个后台服务，都需要存储其对应的虚拟IP、Host信息、接口信息等一系列的信息，同样维护成本很高。

而更加通用的方案，则是提供服务的统一配置中心，每次需要调用后台服务的时候，就从配置中心根据唯一的标识拉取出服务最新的地址。这样一方面能够做到缩扩容对业务的无感知，另一方面配置中心也能够通过服务的寻址情况，给每个客户端分配最适合它的服务机器地址，比如机房或者Set就近分配等等。

本地的服务只需要提供两个能力，第一个是能够调用定期的寻址服务，并存入本机的存储中，保证寻址的速度。第二个则是能够接收配置中心下发的命令，更新特定服务的地址。能做到这两点，就能够实现高效的寻址和可靠的寻址了。

正是依托于 phptars 强大的主控和寻址的机制，我们按照如下的架构，搭建了本机的自动路由和监控上报的体系：

在使用中，我们结合实际业务情况，一方面每分钟向主控请求一次服务的地址，通过轮询的方式获取一个可用的服务地址，再放入本地的高速共享内存，方便在这一分钟之内重复的读取。

另一方面在每次服务调用的时候，都自动在底层集成对服务调用情况的耗时、成功率的上报。在双管齐下的作用之下，对远程服务的调用不再像过去那样难以维护、难以开发、难以监控，而是清晰可见高效的被管理。

正如上文中所说，天下武功，唯快不破。我们通过引入二进制的 tars 协议，大大压缩了服务请求的流量。引入对 tars 协议解析的 php 扩展，提高了打包解包的性能进而提升了单进程的任务处理能力。开发了状态机模型的基于 tars 协议的代码自动生成工具，降低了开发人员的开发和调试的成本。

最后，我们集成了 tars 监控上报与自动路由机制，保证服务的高可用和可监控。这一整套的 web 后台的 phptars 开发体系，使得我们真正做到了高性能、高效率与高可用。