梁晨
Ted
任职起点技术中心前端开发组，负责起点中文网、起点海外版的web后台开发工作。曾负责腾讯上海企业产品部营销QQWeb后台开发、QQ公众号Web后台开发，对大型网站技术架构，有自己的经验和见解。腾讯开源项目TSF2.0框架开发者，腾讯开源组件phptars开发者，也曾是腾讯公司多个php扩展组件的开发者与维护者。
高性能协议与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 必须通过开发高效的客户端来充分利用之。不过，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 服务的开发时间，从小时的级别，降低到了分钟的级别，大大提高了起点改造过程中的工作效率。
TAF监控上报与自动路由集成
在起点后台的服务治理完成之后，大部分我们与后台之间的数据交换，已经从 http 切换成了基于 tars 协议的 tcp 网络传输。如此多的服务，那就势必遇到如下的几个问题：
1. 如何对服务的调用情况进行监控告警
2. 如何管理每个服务的调用地址和负载均衡
依托于强大的米格监控系统，我们在底层集成了对每个 tars 服务的调用耗时和成功率的统计。只需选择不同的业务，那么当前业务下的所有调用的服务和接口，以及他们的频率、耗时和成功率都是一目了然。
对于远程服务的地址管理，最差的方案就是将其写入本地文件中。这种方案无法应对快速缩扩容以及服务器下线的需求，会给后续的运维带来很大的工作量。
稍微好一些的方案是本地存储虚拟IP，那么每次只需要调整虚拟IP，就可以实现服务地址的自动映射和变化。但是这意味着对要调用的每一个后台服务，都需要存储其对应的虚拟IP、Host信息、接口信息等一系列的信息，同样维护成本很高。
而更加通用的方案，则是提供服务的统一配置中心，每次需要调用后台服务的时候，就从配置中心根据唯一的标识拉取出服务最新的地址。这样一方面能够做到缩扩容对业务的无感知，另一方面配置中心也能够通过服务的寻址情况，给每个客户端分配最适合它的服务机器地址，比如机房或者Set就近分配等等。
本地的服务只需要提供两个能力，第一个是能够调用定期的寻址服务，并存入本机的存储中，保证寻址的速度。第二个则是能够接收配置中心下发的命令，更新特定服务的地址。能做到这两点，就能够实现高效的寻址和可靠的寻址了。
正是依托于 phptars 强大的主控和寻址的机制，我们按照如下的架构，搭建了本机的自动路由和监控上报的体系：
在使用中，我们结合实际业务情况，一方面每分钟向主控请求一次服务的地址，通过轮询的方式获取一个可用的服务地址，再放入本地的高速共享内存，方便在这一分钟之内重复的读取。
另一方面在每次服务调用的时候，都自动在底层集成对服务调用情况的耗时、成功率的上报。在双管齐下的作用之下，对远程服务的调用不再像过去那样难以维护、难以开发、难以监控，而是清晰可见高效的被管理。
结语
正如上文中所说，天下武功，唯快不破。我们通过引入二进制的 tars 协议，大大压缩了服务请求的流量。引入对 tars 协议解析的 php 扩展，提高了打包解包的性能进而提升了单进程的任务处理能力。开发了状态机模型的基于 tars 协议的代码自动生成工具，降低了开发人员的开发和调试的成本。
最后，我们集成了 tars 监控上报与自动路由机制，保证服务的高可用和可监控。这一整套的 web 后台的 phptars 开发体系，使得我们真正做到了高性能、高效率与高可用。
引用自：
http://www.mobanhu.com/zytg/3050.html
微服务架构到底应该如何选择？
什么是微服务？
微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等。 微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。 主要有一下几个特点
服务拆分粒度更细 微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
服务独立部署 每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。
服务独立维护 每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
服务治理能力要求高 因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
微服务架构下，服务调用主要依赖下面几个基本组件：服务描述 注册中心 服务框架 服务监控 服务追踪 服务治理
开源RPC框架介绍
Dubbo
国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。中间一度没人维护坑了不少人，17年重启维护焕发新春。架构图如下
官网： dubbo.io/
通信框架方面，Dubbo 默认采用了 Netty 作为通信框架。
通信协议方面，Dubbo 除了支持私有的 Dubbo 协议外，还支持 RMI 协议、Hession 协议、HTTP 协议、Thrift 协议等。
序列化格式方面，Dubbo 支持多种序列化格式，比如 Dubbo、Hession、JSON、Kryo、FST 等。
性能： dubbo.apache.org/zh-cn/docs/…
Tars
Tars是基于名字服务使用Tars协议的高性能RPC开发框架，同时配套一体化的服务治理平台，帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。
Tars是将腾讯内部使用的微服务架构TAF（Total Application Framework）多年的实践成果总结而成的开源项目。
架构图如下
开源协议为：BSD-3-Clause
支持多语言 C++，Java，Nodejs，PHP，Go
gRPC
一开始由 google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。
官网：grpc.io
基于HTTP/2 HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP链接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。
IDL使用ProtoBuf gRPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。
多语言支持（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java） gRPC支持多种语言，并能够基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言，grpc-java已经支持Android开发。
Motan
Motan 是国内另外一个比较有名的开源的 RPC 框架，同样也只支持 Java 语言实现，它的架构可以用下面这张图描述。
Motan 与 Dubbo 的架构类似，都需要在 Client 端（服务消费者）和 Server 端（服务提供者）引入 SDK，其中 Motan 框架主要包含下面几个功能模块。
register：用来和注册中心交互，包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。Server 端会在系统初始化时通过 register 模块注册服务，Client 端会在系统初始化时通过 register 模块订阅到具体提供服务的 Server 列表，当 Server 列表发生变更时也由 register 模块通知 Client。
protocol：用来进行 RPC 服务的描述和 RPC 服务的配置管理，这一层还可以添加不同功能的 filter 用来完成统计、并发限制等功能。
serialize：将 RPC 请求中的参数、结果等对象进行序列化与反序列化，即进行对象与字节流的互相转换，默认使用对 Java 更友好的 Hessian 2 进行序列化。
transport：用来进行远程通信，默认使用 Netty NIO 的 TCP 长链接方式。
cluster：Client 端使用的模块，cluster 是一组可用的 Server 在逻辑上的封装，包含若干可以提供 RPC 服务的 Server，实际请求时会根据不同的高可用与负载均衡策略选择一个可用的 Server 发起远程调用。
Spring Cloud
Spring Cloud 是为了解决微服务架构中服务治理而提供的一系列功能的开发框架，它是完全基于 Spring Boot 进行开发的，Spring Cloud 利用 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。它的架构图可以用下面这张图来描述。
以下为Spring Cloud的核心功能：
分布式/版本化配置
服务注册和发现
路由
服务和服务之间的调用
负载均衡
断路器
分布式消息传递
Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。
下图是RPC框架详细的比较
如何选择？
一家A轮融资的公司 原来架构是net，想换java架构。
公司没有强大的研发实力，公司主要是to B业务，对并发要求不高，那可以试试Spring Cloud 架构， Spring Cloud 不仅提供了基本的 RPC 框架功能，还提供了服务注册组件、配置中心组件、负载均衡组件、断路器组件、分布式消息追踪组件等一系列组件，被技术圈的人称之为“Spring Cloud 全家桶”，而 Dubbo、Motan 基本上只提供了最基础的 RPC 框架的功能，其他微服务组件都需要自己去实现,对于这类研发能力弱的团队，SpringCloud 无疑是最合适的，减少了研发成本，社区热度高，相关的教程文档很多，减少了入门成本；
再比如这家公司不准备切换Java框架还是继续使用net架构， 有一定的研发能力，对并发要求很高， 那gRPC无疑是最适合的，跨语言支持，高性能；
没有完美的解决方案，只有最合适的
推荐阅读
学习Java进阶技术干货、实践分享，职位内推，一起聊聊理想。志同道合的朋友，欢迎你的加入。
关注下面的标签，发现更多相似文章
