swoole游戏服务端开发经验谈（swoft微服务架构）

swoole作为php的高性能第三方扩展，最近几年异军突起，为几近衰落的php注入了活力。而php作为敏捷开发的利器，有大批的忠粉和黑粉，原因就是实现高效开发的同时不能达到类似node、golang、java同等的性能。而swoole的出现，以及php7尤其是7.3的版本更新大幅提升了php的性能，使php能够运用到更多场景中。笔者作为一名手游服务端从业者，将在本文中分享下自己在手游开发中使用swoole的心得。才疏学浅，文中如有偏颇请及时指正，以免影响到更多小白读者。

笔者最近一个项目是基于H5的，选择php的原因很简单，节约时间成本，这目前也是很多游戏成败的关键，一个小项目十几个人开发一年就是两三百万！swoole在项目中的使用仅限于swooleHttp和swooleWebsocket两种模式，因为Tcp和Udp毫无用武之地。当然，如果您想使用TCP或UDP也是可以的，就是：浏览器->网关（协议转发）->swooleTCP/swooleUDP的RPC服务端，这种模式也是可以的。

swooleHttp生产环境怎么使用呢？

1. swoole本身提供http而非https服务

swoole作者也承认swooleHttp是不完善的，并建议在外层增加nginx做反向代理，那么https隧道加密的工作完全可以让nginx一个人扛，然后nginx再通过http方式反向代理给swooleHttp。这样的好处是：开发模式可以完全不使用https，方便调试、抓包，且迁到线上时不需要对配置ssl证书、url地址等配置项做任何更改。

2. 使用swoole_base模式

process模式时reactor和worker由不同进程负责，因此服务端收发数据时都需要在reactor和worker间做一次交互。而BASE模式下，worker进程直接接管客户端连接做数据收发，即worker同时做了reactor的工作，省去一次（或者说两次）IPC交互的消耗。作为短连接的http完全没必要使用process模式。

3. keepalive保持连接

TCP短连接每次通信要经过三次握手四次断开，加上每次发送、确认，回复、确认，一共是11次数据传输，性能开销可想而知。保持连接不断开的情况下，一次跟服务器交互只需要4次通信。

nginx代理时的keepalive配置如下（手写的，方便copy）

nginx.conf

http{

......

upstream main_server {

server 127.0.0.1:8991;

keepalive 128;

}

server{

......

# swoolehttp反向代理

location / {

proxy_http_version 1.1;

proxy_set_header Connection "";

proxy_set_header X-Real-IP $remote_addr;

proxy_pass http://main_server;

}

#swooleWebsocket反向代理

location /ws {

proxy_http_version 1.1;

proxy_set_header X-Real-IP $remote_addr;

proxy_pass http://127.0.0.1:8091;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

}

}

4.慢请求日志

慢日志有助于查询性能瓶颈，如果您没有用协程，则可以在开发环境使用xhprof调试性能，比慢日志更行之有效。

swoole本身已经提供了慢请求日志的功能，但是很弱，日志内容不能自定义所以有时候并不知道是哪个接口造成的。如果您是基于swoole自建框架，建议手写搜集慢日志的功能。笔者的日志格式是这样的，看起来一目了然（时间|接口|ip|耗时）：

5.关于数据库连接池

如使用了协程，那么连接池是必须要建的，否则同进程内的协程都会卡在操作数据库。如果使用的是swoole1.x，进程只能每个请求全部处理完毕才能处理下一个请求，所以只需要有一个数据库长连接而不需要建立连接池，或者说连接池里只有一个连接就够了。

6.是否使用负载均衡和分布式

如果你的服务器架构为传统的多组服，比如1-5区在同一组服务器（game服+缓存服+数据库+其他）上，6-10区在第二组服务器上，开第11区时发现第二组服务器还没什么负载，那么11区可以继续开在第二组服务器上。这种情况就没必要使用分布式，也基本用不到负载均衡，程序中可以使用文件锁做为逻辑锁（这比redis等缓存锁安全但性能略低）。该模式最大的缺点是不方便和服。

如果您的服务器只有一组（和服很easy），那么game服就需要分布式或者负载均衡，具体看业务怎么切割，水平切割就是负责均衡，垂直切割就是分布式集群。另外负载均衡的流量大推荐使用服务器提供商的SLB服务（不同运营商叫法不一样），流量小的话nginx完全可以胜任了。

同样数据库部分也可以读写分离或者主主复制或者根据业务垂直切割，这个就根据自己的情况自由定制了。

7.定时作业

游戏一般都有定时处理作业的需求，比如定时发奖，定时分配比赛等。这样一个定时任务处理的server是必须要有的了，最好不要混在game服中。如果可以做成linux的crontab的配置形式是最好的，用起来很舒服。但是定时作业这块笔者还不知道怎么使用swoole来做，目前是脱离swoole基于php-cli模式做的，不过也没太大问题。不知道您有什么高见？