skynet框架下的业务开发,单点服务是存在理论瓶颈的。当业务上存在并发请求的场景时,服务会成为性能热点,达到服务的消费瓶颈,出现过载。
原则上讨论,当业务需求一个执行单位成为并发热点,那么实现这个执行单位就需要是足够支撑业务上限的方案。
基于这个思路,讨论几个优化:
- 解耦;降低过载造成的直接影响
服务过载时请求延迟响应,需要将请求与关键业务流程(比如登录)解耦,使过载造成的影响可控。比如将可能引起并发的请求操作在单独的coroutine里执行,不阻塞核心主coroutine;
- 拆分热点服务;提高并发能力
拆分思路:对热点服务按业务拆分成多个服务或对请求单位根据指定规则分组划分对应并行的多个服务。根据经验,并发的请求方大部分情况是client的代理服务,那么并发的量级是当前online玩家总量,这种场景下适合的拆分方案应该是按规则拆分,比如按玩家角色id拆分,热点服务数量按玩家量级动态扩展;
- 过载统计预警;
监控统计请求耗时信息、队列堆积信息、coroutine堆积信息,针对优化耗时请求,提高单位时间消费能力。这里加入yield coroutine统计的原因是,热点服务可能位于skynet外部。当外部热点服务出现过载,需要支持在skynet内部请求侧捕获到异常并抛出告警;
- 过载保护;
比如请求方做超时返回处理,热点服务做过载时缓存区处理。
标签:服务,请求,框架,过载,并发,skynet,单点,热点 From: https://www.cnblogs.com/linxx-/p/18202736