Swoole rpc实践小结

1. 背景介绍
   公司内部基础服务，基本上每一个业务，每一个页面都会调用的接口。随着业务的增长，在rpc服务提供以前，http接口天天的调用量有1亿次。原先有4台阿里云服务器（8C+32G），3台nginx+1台crontab，后来增长到5台nginx。业务高峰时负载较高，时常超过运维规定的报警峰值。
   http接口:php 5.6.7 + yaf 2.3.5 + redis + MySQL

   以其中标签业务为例：
   -	最短响应(ms)	<10ms	<50ms
   读	2.5	99.9%	0.1%
   写	7.5	73%	27%

2. RPC接口
   php 7.1.9 + swoole 2.0.8 + zookeeper + redis + MySQL等
   基于Swoole，实现dubbo的主要功能：服务注册+服务发现+监控+服务提供+服务消费,大体结构以下：
   
   数据流：
   

3. 效果

   服务器	配置	数量
   http	8C+32G	5
   rpc	8C+32G	2

   注：redis与mysql资源都是同样的。

   使用rpc接口后数据与效果对比：
   -	数据量	最短响应(ms)	<1ms	<10ms	<50ms
   http读	n	2.5	0%	99.9%	0.1%
   http写	m	4.0	0%	74%	26%
   rpc读	40n	0.3	98%	1.9%	0.1%
   rpc写	m	0.9	28%	62.5%	9.5%

   rpc读接口详细详细时间分布
   

   服务器负载均降到1之内，业务高峰期不超过2

   线上运行状况：
   

4. 踩过的坑
   4.1. 请求丢失（万分之几，周期性）
   这个在开发初期，模拟线上业务长期压测的过程当中出现。老是有周期性的丢包。联系过swoole做者，想让韩大帮忙看看解决，后来本身解决了。由于在worker进程中加了SwooleTimer::tick(），想作心跳，检查worker状态+维护tcp链接，去掉了就没有丢过包。
   4.2. 心跳如何保持
   worker进程里加心跳貌似会影响swoole的运行机制，经过对单起注册进程，按期对worker发送消息，worker收到消息后检查维护。
   4.3. 变量如何传递（$_SERVER,调用链追溯）
   专门设置一个环境变量的参数，传递到下一级请求。
   4.4. 链接数增长（worker_num*数据库数量）
   这是个大问题。咱们的php-fpm调用mysql采用的短链接，每次请求完了会释放。rpc使用的是swoole常驻进程，链接mysql使用的是长链接，链接数=worker_num*数据库数量，结果mysql服务器的链接数暴增，后经过mycat解决。
   4.5. 状态监控(worker_num, active_worker_num)
   经过对单起注册进程，按期对worker发送消息维护。
5. 对比与探索
   如今比较流行的PHP运行模式是LNMP, 其中PHP以PHP-FPM模式运行。PHP-FPM是多进程模式，master进程管理worker进程，worker进行实际运行代码处理请求。
   5.1. PHP-FPM模式的几个问题：
   5.1.1. 没有链接池：PHP-FPM模式下，注定一个请求的生命周期只有1次。也就是说，从FPM请求到请求，解析PHP脚本，FPM的Zend虚拟机分配资源执行，到最后的处理结束，PHP-FPM会回收此次请求的全部资源。因此高并发业务下，网络的处理会有劣势。
   5.1.2. 对单个进程没有多线程的程序来讲，若是频繁的有http接口的请求，服务容易被block。
   5.2. 基于swoole的RPC方案，能够有效避免FPM模式的两个缺陷。
   5.2.1. 维护链接池: worker常驻进程，能够保持对资源链接的链接池，并经过按期心跳维护链接保持。
   5.2.2. 进程内使用协程，对每一个资源的链接保存在SwooleChannel（高性能内存队列）内，没必要考虑对资源的过多链接，协程处理请求又不相互影响。不一样的资源链接在不一样的资源池，不会相互影响，其中一个请求到IO时，底层会将IO事件注册到EventLoop，并让出执行权。接口请求并不会在进程里占用timeout时间。
   5.2.3. 常驻进程，配置文件及程序初始化加载都可以在初始化阶段（onWorkerStart）完成，省去了请求开始的脚本初始化及请求结束的资源释放，能更快的响应请求。
   5.3. swoole协程解决的问题：
   5.3.1. 若是碰见FPM模式下接口A响应时间超时，不影响下一个请求的处理，不影响worker的处理能力；
   5.3.2. 资源类的IO都是经过协程出让worker的主动权，能提升总体的QPS能力；
6. 总结
   基于swoole的tcp/rpc接口对短平快的接口有更好的表现。http接口调用php-fpm初始化消耗一些时间，使用swoole常驻进程能够节省。http接口请求频繁打开关闭的链接，对服务器形成压力，也能够经过swoole常驻进程解决。
7. TODO
   7.1 swoole协程对资源调用的IO操做有更好的处理，下一步在项目中验证。
   7.2 使用协程抢占式调度器，解决单次请求响应时间过长/超时问题。

（刚看了一眼git tag记录，第一次上线时间是2018年5月22日，至今上线已有一年有余，至今稳定运行。 ）

最后，欢迎路过的各路大神指点指正，互相交流。