skynet框架：批量服务管理方案

skynet很经典的用法是节点内会有批量的服务跑相同的模块逻辑。服务的生命周期管理显然是跟业务强关联的，需要根据实际业务对应做适配的生命周期管理方案。显然最直接的方案就是服务常驻，跟进程的生命周期同步，当服务的数量级不大时，认为消耗可控，方案是适用的，也避免过度设计。

这里想谈的是单节点数千服务的场景下对应的服务管理，以游戏项目中常用基础模块为例；

玩家代理服务（client）：显然服务的生命周期需要跟玩家上线下线同步，即玩家上线时创建分配服务，下线时销毁服务，当然实际方案通常会多加一些处理，比如优化重登情况：下线时冻结服务指定一段时间，超时才销毁退出，优化玩家频繁上线下线造成的性能消耗；

聊天频道代理服务（chat）：聊天频道的特点是玩家聚集度明显，分布不均。这里以 为每个频道创建独立服务 的方案来讨论。那么不同的服务访问热度是不同的，请求会集中在少数的频道服务中。这时候对服务使用闲置销毁的管理方案，一定时间内没有请求到达则自动销毁退出服务，每次请求都检查服务是否存在，否则先创建服务；

btw，这个方案可能需要关注的地方：1. 服务创建动作由请求触发，当请求存在并发场景时，需要关注处理临界区情况；2. 定时销毁的间隔需要根据实际业务来评估合适的值，不合理的销毁间隔反而会适得其反增大性能压力；

周期赛事服务（activity）：赛事活动的特点是，服务有明显的有效期，在一段固定的时间内生效，那么适用于集中创建销毁的管理方案，在赛事开始时批量创建拉起服务，在赛事结束时批量销毁；当服务量级过大时，可以考虑引入上述闲置销毁处理方案；

团队代理服务（team）：每个团队使用独立服务代理，服务应该是常驻的，但量级是O（N），N是团队总数量，上限不可控，且团队节点通常是单点节点，系统存在理论上限。团队服务的特点是活跃度差异大，这里适用于 lru 管理方案，评估系统安全承载的服务数量上限，按活跃度规则进行有序管理，末位淘汰销毁超出上限的冷服务，当冷热切换过于频繁时，就需要提高节点承载能力（机器配置）了。