🔥 socket长连接在手游场景下的技术实践原创

Saki常连接在手游场景下的的技术实践。本文介绍了37手游基于B站go in框架自研长连接系统的实践。系统采用分层设计，支持多协议和发布订阅机制，用于直播弹幕、实时推送等场景，实现了高性能与业务适配。一、常连接对于大部分公司的意义，实时的响应总是让人兴奋的，就如你在微信里看到对方正在输入，如你在王者峡谷里一呼百应，如你们在直播弹幕里不约而同的666。他们的背后都离不开长连接技术的加持。每个互联网公司里几乎都有一套长连接系统，他们被应用在消息提醒、及时通讯推送、直播弹幕、游戏共享定位、股票行情等等场景。而当公司发展到一定规模，业务场景变得更复杂后，各可能是多个业务都需要同时使用长连接系统。二、长连接是什么？长连接是一种概念，它。

指的是在网络发送、接收双方保持一个持续连接的状态，双方都可以发送或接收消息，全双攻当然，成连接系统听起来好像高深莫测，但实际不可能说完全脱离于我们实际公司的业务去触发设计。这就引出来我们今天的主题，长连接技术在37手游内是如何设计以及实践的？三、技术痛点从服务端而言，缺乏在SDK内实时推送通知用户的能力，如防沉迷的弹窗通过HTTP定时轮来实现，给服务造成很大的压力。从客户端而言，也缺乏低成本告知服务端自身在线的能力，如维持用户在线状态，靠客户端定时上报心跳到防沉迷服务实现。四、搭建背景手游的SDK需要提供内嵌直播弹幕的功能，供玩家在看直播的时候进行沟通发言，业界一般会用到长链接来进行实时的推送。

降低服务的轮训和请求。常连接系统的这次搭建，本质是通过SDK内嵌直播弹幕为切入点，从0~1为平台提供了完整的一套实时推送、触达用户的能力。从以上角度出发，我们便着手想要设计一个高可用且高性能的长连接系统提供给我们使用。五方案选型从实际来说，我们考虑三个方向，云服务、开源框架和自研易云服务，市面上可购买的服务如环信等大多数都以即时聊天通讯为主，常连接往往支持附带产品，过于偏向于社交业务，在花钱的同时也很难适应到自身游戏业务。2、开源框架，B站的逛框架、nit chat框架、mob and SDK框架等。好处是免费潜能快速接入，但业务还是不相适应，且语言站和技术站不一定相契合。3、自研B开发成本高且容易踩坑，B基础组件完善统一框架好进行监控和问题查询，且能充分契合自身业务进行拓展，并将数据源掌控在自己手中。4、结论出于扩展性的考虑，肯定是自研的方式更加合适，但完全自研相应的成本和不确定性会非常高，因此最终的选型方案为借鉴B站的惯框。

框架设计和部分代码，并做了符合自身技术站和业务架构的改善，可认为是基于开源框架的自研方案，被形式完成了长连接这个系统的落地。6、go技术概况go应是B站开源研发的一个支持集群的应急实时推送服务，业务上为直播间的弹幕发送场景，主要考虑到，1、技术站契合语言站为GOLA，消息队列为cof，卡缓存设计为radius 2、高性能有压测报告，性能设计有保障，3、多协议支持web、萨克TCP 7、手游长连接系统的设计实践长连接架构的设计总是大同小异的，通用的有这几点，业务层次分明，协议通用，上行和下行收敛消息校方。根据以上的通用试剂原则，我们不难得出需要针对怪物的架构如何做适配，才能实际满足我们的业务需求。

性能评估在说性能之前，我们先抛出一个疑问，携程数过多实际占用的是什么？连接数过多是否影响CPU？从实际上来说，长连接的性能瓶颈一般卡在接入层，因此以接入层为评估维度，通过全链路压测的出来结果，性能结果是这样的，3000连接加3000QPS的实时推送，推送内容msg test的推送类型群推，推送持续时长5分钟，资源使用一核2g的容器，CPU的使用达到100%。