涨姿势 – 不一样的服务端长连接方案 – 客户端代理
仔细再看一次腾讯云的小程序解决方案，发现一个新大陆。
传统的 LAMP 架构，PHP-CGI 这种方式是很难处理长连接的。要么写死循环的方式来握住请求，要么使用 swoole 这种，通过 C 拓展来支持。
而 NodeJS 由于官方 DEMO 就是支持跑一个 HTTP 服务，所以处理这些长连接会方便一些（大家好懂一些，我觉得 PHP-CLI 方式也是一样的）。
信道服务
建立连接过程
- 小程序请求业务服务器
- 业务服务器和信道服务建立连接
- 业务服务器告诉小程序你可以和信道服务建立 ws 了
- 小程序和信道服务建立 ws
- 信道服务请求业务小程序的 ws 建立完成
连接成功后的通信方式
- 小程序请求信道服务，信道服务转发请求给业务
- 业务请求信道服务，信道服务推送到客户端
我最开始看的时候，没注意信道服务是一个云服务，琢磨着腾讯云的 SDK 难道有什么新的黑魔法来实现 PHP 的长连接。
看里面的代码，各种 onConnect/onRequest，看着就很像长连接的 API，但他基于 CI 是怎么实现的长连接了？看 composer.json 里面没有用什么黑魔法，搜索代码里面没没看到任何死循环。
客户端代理
为什么信道服务的 icon 是一朵云？
原来腾讯云把这个信道服务抽象成了一个 PaaS 的云服务，这根本就是一个客户端代理。而开源出来的 PHP-SDK，里面没有任何长连接的实现方案。
- 业务服务器 -> 小程序：业务服务器只需要请求信道服务即可，信道服务接收到业务的请求后，会将 HTTP Body 部分，转成 WS 的消息推送给小程序。
- 小程序 -> 业务服务器：则正常通过 WS 发送消息给信道服务，信道服务转成 HTTP 请求转发到业务服务器。
对于一些使用 PHP 开发的历史业务，大规模的长连接改造是非常困难，但部署一个长连接转发服务却容易很多（比如用 NodeJS 来写一个）。
腾讯云的这个思路可以帮助各种业务快速支持包括 SSE 和 WS 这两种长连接方案。并且由于业务服务器本身是 HTTP 方式，可以很容易给低版本 IE 做轮训兼容。
最后感谢腾讯云开源了他们的方案。
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
