小编： 17年9月份，PP体育App直播详情页重构，在此之前直播中用户在观看直播中使用的交流互动方式是评论服务，消息传递的实时性差是其显著缺点，尤其对于快节奏观赛氛围的赛事直播，球迷间互动消息无法及时传达与获取反馈，因此需要快速搭建并上线评论与聊天室特点对比），此文会给大家从0到1来介绍赛事直播下聊天室服务设计的思路、原则、技术选型过程以及未来展望
17年9月份，PP体育App直播详情页重构，在此之前直播中用户在观看直播中使用的交流互动方式是评论服务，消息传递的实时性差是其显著缺点，尤其对于快节奏观赛氛围的赛事直播，球迷间互动消息无法及时传达与获取反馈，因此需要快速搭建并上线评论与聊天室特点对比），此文会给大家从0到1来介绍赛事直播下聊天室服务设计的思路、原则、技术选型过程以及未来展望。
首先我们对体育赛事直播场景下聊天室服务的特点进行了分析（见图2赛事直播下聊天室特点）。提到聊天室，大家可以马上联想到的就是直播App中的聊天室，为了区别我们在这就称为主播聊天室，而PP体育赛事直播场景中，例如足球赛事，通常一场比赛为120分钟，直播在线人数往往达到数十万甚至上百万，于此同时球场上还伴随着不确定性的事件，例如判罚，乌龙，进球，球员受伤等等，随时要应对突发消息流量，因此我们把此场景下的聊天服务称为赛事直播聊天室。其次我们内部与云信团队（易购客服服务）、豆芽团队（内部办公协作平台-即时通讯）进行了交流，从中得到了很好的经验和建议。他们的场景更偏向单聊与小群聊（千人），对消息的到达率等要求高，而对于大群聊（数十万到百万在线）应该是广播模式。由此对体育赛事直播的聊天室特征有了更清楚的认识（图3体育赛事直播聊天室特征）。
在做架构方向决策（图4决策）时，影响我们架构决策的因素主要有开发人力、开发周期，研发成本等因素，首先参考《架构即未来》一书中提到的“非核心业务即购买”的原则，我们前期预研时也了解到多数直播产品中的聊天室服务都是引入了外部的第三方服务。结合前面总结的赛事直播聊天室的特征，与主播直播存在一定的差异，同时作为体育赛事直播的引领者，并考虑到后期的业务扩展性，成本、以及对产品、对开发团队的价值，明确了赛事直播聊天室产品和自身的定位。我们决定自研聊天室服务，同时考虑现有的资源和快速上线的需求，肯定要优先使用已有组件，我们最终选用基于Bayeux协议的CometD组件来实现聊天室服务，下文将详细介绍相关通讯协议和组件的特点及选择原因。
设计原则的约束（见图5设计原则约束），为了后期不偏离方向，结合团队现有技术栈能力、赛事直播聊天室的特征，以及系统的稳定性等，开发语言遵守使用Java；消息通道需要单独部署，支持横向扩容，一期暂不支持点对点（用户单聊）；消息通道针对大群聊，采用广播模式。
梳理出需求中基本功能，包括消息互动、安全风控、聊天室基本信息，道具、排行榜等信息。以此整理出系统需要提供的基本服务能力（见图6基础服务能力），多终端接入，聊天室房间配置、消息处理、消息分发、消息储存。
重点在消息通道的搭建，消息通道我们选择开源组件（如图7开源组件选择），对于开源组件的选择，需要从版权协议、兼容性、扩展性来考虑，同时要调研该组件的开源社区的建设情况，最近版本的更新时间，是否应用广泛等，这可以看出组件的稳定性，还有就是官方的指导文档是否组织良好清晰，是否有商业支持服务。是否有成熟的产品在用，我们选型的Bayeux协议就有被gitter.im所应用。
通过上面开源组件选择需要考虑的内容，再结合消息通道应用的场景，我们在CometD、socket.io、goim三者之间进行对比（见图8组件选择对比），最终选了CometD。
在部署方面，如下应用部署简图（见图9），遵循可扩展，解耦（消息通道单独部署），简单可用，图9中上半部分为单独部署的消息通道，通过WebSocket与客户端通信，主要为使用广播方式下发用户消息，可横向扩展多机房部署。下半部分为聊天室基础服务，提供聊天室房间信息，房间多通道信息，拉取历史消息、发送消息（接收用户发送消息）、道具信息等服务。注：图中RSF，是苏宁内部远程服务调用框架；sgcs为聊天室基础服务系统简称；cometd为聊天室push消息通道。
CometD提供了实现这些消息模式的API:包括发布/订阅、点对点(通过服务器)和远程过程调用。这是通过使用一个独立的传输协议(Bayeux协议)实现的，它可以通过HTTP或WebSocket(或其他传输协议)进行传输，该项目提供了Java和Java库，同时开源社区也有其他语言Bayeux协议实现的客户端。可以快速方便的支持Wap页、安卓、iOS平台客户端的接入（见图10）。
消息分发策略，CometD集群作为高可扩展的消息推送集群，实现了消息快速推送到终端，在应用过程中，我们发现面对用户复杂的网络环境，例如弱网，长连接并不稳定，我们实现了推送、拉取及推拉结合等多种消息同步模式。推拉结合模式即客户端长连接等待消息，若5秒内无推送，则客户端发起http请求主动拉取消息。多种模式规则由服务端控制下发到客户端，通过这几种模式，保证了用户在复杂的网络环境下，系统也可以提供稳定的聊天室消息服务。
赛事直播中普通场次的同时在线w在线w条下行消息分发，这个数据量是巨大的，而且如有赛事突发事件发生，用户同时活跃发言，这种情况下每秒消息量是巨大的，10人/s则每秒则为100w/s的消息量，需要足够的带宽流量来支撑。系统最常用的策略就是流量控制，进行限流，当然这种控制是我们基础能力，用户的消息会放入到Kafka中，但是势必会影响用户体验，可能大量消息需要被丢弃。这时我们从产品和用户实际场景来考虑，对于单个用户实际能处理的消息量，每秒最大给到9条就足够了，过多的消息量短时间内推送给用户，用户并不能查看和参与到互动中。针对大群聊下消息洪峰的问题，我们将同一个聊天室划分为多通道，用户是无感知的，我们将用户自动做了大分组，分组人数可以默认5w人划分，根据用户活跃度，用户关注球队、球员数据等形成的用户画像来实现分组，保障每个分组下的活跃度。通过分组的拆分将消息洪峰值成倍降低，而且这种方式保证了用户更好的观赛互动体验，同时节省了带宽。
产品是从0到1的演化，我们的团队在这个过程中从0到0.9...的成长，我们并不满足现状而是在探索中持续进步。
1、组织翻译CometD中文指导手册，并逐步建立CometD中文开源社区，以期团队成员在更宽阔的平台的互补优势，开源协作，提升自我。
本次聊天室服务的研发过程中，通过分析赛事聊天室与主播聊天室的特征，提出了适合直播场景的消息分发策略，并顺利通过专利的申请，对团队成员创新意识、专利意识的培养都有积极的作用。
聊天室服务需要面对数以百万计的用户同时在线的场景，促使团队成员要面对高并发，大吞吐量，内容安全等复杂的情况，需要更加关注网络、应用层面如何合理利用、分配资源，合理进行架构设计。
整合现有平台服务能力/反哺。风控平台，敏感词、黄牛库等已有服务快速接入，快速为聊天室系统提供了基础的风控能力，同时PP体育的用户数据提供给风控，丰富了风控平台数据。创新中心提供的机器学习智能识别广告信息，为打造绿色的聊天室提供了有力支撑，解放了人工审核消息的工作，同时聊天室大量的文本消息为文本检测服务提供了大量的数据样本,AI智能机器人，为不同层次的球迷提供解说服务等等。这些都是在苏宁服务平台的基础上建立起来。
今年在内容安全方面我们会做进一步提升，为用户提供更纯净绿色的赛事聊天室互动服务。我们会在消息分发前增加一层内容分拣过滤服务，让有价值的消息分发到更多的用户，同时对于文本垃圾实现零分发，打造更稳定、更安全、消息质量更高，氛围更佳的赛事聊天室服务。返回搜狐，查看更多
当前网址：http://www.sx-news.com/tiyu/2018-09-15/28299.html
免责声明：本文仅代表作者个人观点，与陕西新闻网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
