摘要：直播是云栖社区的主要模块之一，弹幕服务是在直播频道上线之后，为了更多的互动，提出的。 我主要做了下面的一些迭代： 使用 netty 构建弹幕应用 授权服务与弹幕服务的分离 专题页本地缓存 使用 nginx lua 为 web 应用加速 实时监控在线人数 使用 netty 构建弹幕应用 抽离出来的小demo https://github.
直播是云栖社区的主要模块之一，弹幕服务是在直播频道上线之后，为了更多的互动，提出的。
我主要做了下面的一些迭代：
使用 netty 构建弹幕应用
授权服务与弹幕服务的分离
专题页本地缓存
使用 nginx lua 为 web 应用加速
实时监控在线人数
使用 netty 构建弹幕应用
抽离出来的小demohttps://github.com/zhoumengkang/netty-websocket
├── WebSocketServer.java启动服务器端口监听├── WebSocketServerInitializer.java初始化服务├── WebSocketServerHandler.java接管WebSocket数据连接├── dto│ └── Response.java返回给客户端数据对象├── entity│ └── Client.java每个连接到WebSocket服务的客户端对象└── service ├── MessageService.java完成发送消息 └── RequestService.javaWebSocket初始化连接握手时的数据处理
客户端授权与弹幕服务的分离
客户端请求 web 服务器 api 获取弹幕服务请求的完整地址
https://yq.aliyun.com/yqapi/webinar/barrage/url?id={id}
然后返回类似于
wss://barrage.aliyun.com/websocket/?rid={id}&code=xxxxx
然后客户端使用返回的websocket地址发起请求即可。
因为在获取code的过程中，需要读取集团 cookie，和账号中心交互验证用户身份合法性。获取用户的基本信息
{uid: xxx, name: xxx, level: xxx, isAdmin: xxx}
然后和时间戳对称加密运算得到最终的code，这样弹幕服务器只需要验证解密code验证数据的合法性，就可以使用客户端传递过来的用户信息了，免去了弹幕服务身份认证，获取用户信息等操作的网络I/O。
专题页本地缓存
很多直播页面都是静态的专题页面，我们原来的做法是在tms里面运营编辑好了，我们再抓取过来缓存在redis里面，然后最后通过后端框架呈现。这样还是有一次web服务器到远程的集中式的redis缓存的网络I/O。
做了以下的修改，在nginx配置单文件来操作
rewrite^/promotion/(.*)$/promotion.phplast;
promotion.php需要做两个个工作
判断客户端是移动端还是PC端，然后读取不一样的数据
本地缓存文件不存在则从远程redis里读取，然后缓存到本地
同时后台在抓取页面到redis时的同时，我会推送缓存到各个web服务器的指定目录
#!/bin/bash# 更新同步 html 静态缓存到各个服务器servers=(xxx.xxx.xxx.200xxx.xxx.xxx.201xxx.xxx.xxx.202xxx.xxx.xxx.203)forserverin${servers[@]};docd /path/to/cache/output/ rsync -aR promotion/pc/$1.html username@$server:/path/to/cache/output/rsync -aR promotion/mobile/$1.html username@$server:/path/to/cache/output/done
还需要验证文件发布是否成功，对比最终的md5
使用 nginx lua 为 web 应用加速
有了上面的缓存文件的推送之后，我想缓存的读取直接在nginx 里进行。需求也就是：
pc、mobile 一个地址有两套页面，需要在后端根据浏览器的 user_agent 来显示不同的页面。
具体参考：https://mengkang.net/998.html
我在我们自己私人的web服务器上做了性能测试的对比，性能提升了近1倍，稳定性也挺高了很多。
实时监控在线人数
我们自己使用Grafana+telegraf+InfluxDb搭建了一个简单的监控系统，然后我编写了一个脚本来每秒监控统计端口ip
压测
websocket 压测
脚本https://github.com/zhoumengkang/netty-websocket/blob/master/benchmark.py
并测试为N个客户端，每个客户端发送10条消息，服务器配置2核4G内存，广播给所有的客户端，我们测试1000个并发的时候，负载在后期陡升。
实际情况下，不可能那么多人同时说话广播，而是说话的人少，接受广播的人多。
实际线上之后，在不限制刷帖频率大家狂轰滥炸的情况下，1500多人在线，半小时，负载一直都处于0.5以下。
web 服务的压测
ab-n8000-c800http://mengkang.net/promotion/1Completerequests:8000Failedrequests:0Requestspersecond:7046.66[#/sec](mean)Timeperrequest:113.529[ms](meanab -n10000-c1000http://mengkang.net/promotion/1Completerequests:10000Failedrequests:0Requests persecond:5670.38[#/sec] (mean)Time perrequest:176.355[ms] (mean)
