问题场景是：服务A生产大量请求消息call到服务B，服务B瞬间达到消费能力的瓶颈，导致服务A堆积大量的yield状态协程，服务B消息队列堆积大量待处理消息，业务上出现卡顿、超时甚至物理机器内存吃满被瞬间击穿的问题；
我们使用云服务器产品部署游戏业务，起因是游戏线上收到反馈在某些时间节点频繁出现卡顿延迟现象，查看云服务器机器实例监控信息发现某单点节点内存明显波动，业务定位到指定服务，skynet控制台打印当前任务数量、打印指定服务消息队列长度超2w。
这看上去只需要简单做一些优化就能避免上述问题，比如将服务B扩展成批量服务、控制服务A的请求频率等，这里想讨论的是，如何在游戏内加入监控并抛出类似的性能风险；
（1）调整服务消息队列长度阈值告警；通过skynet_mq_overload
（2）增加yield协程数量阈值告警；统计一个yield_cnt值（比如简单地在coroutine yield时自增），服务启动时开启定时心跳检查，当yield_cnt值超出阈值时抛出提示信息；
ps: skynet通过lua-coroutine机制将异步回调的消息处理模型模拟出rpc调用的效果—> 服务处理消息时，会为消息分配（get or new）一个协程，在协程内执行消息的处理逻辑，当处理流程中发生对服务外的消息发送时，yield挂起协程，等待收到对应session的RESPONSE消息回应后，重新resume唤起协程继续往下执行处理逻辑；协程的唤醒依赖引起yield操作的那次call操作的回应。
标签：服务,service,yield,lua,消息,skynet,协程,告警 From： https://www.cnblogs.com/linxx-/p/18091083