• 几十万人同时在线的直播间聊天,如何设计服务端架构?


    一个热门视频直播间人数可能达到几十万甚至上百万人,几十万人发消息,几十万人接收,流量相当惊人,那么服务端要如何设计才能保证系统流畅?本文作者将结合他在网易云信多年IM开发的经验进行深度分析。

    推荐阅读

    高并发IM系统架构优化实践

    IM即时通讯:如何跳出传统思维来设计聊天室架构?

    聊天室架构应满足哪些条件

    高可用:任何一个节点故障都不应该引起服务不可用;

    易扩展:具有水平扩展的特性,对不同量级的在线用户数都有应变的能力;

    高并发低延迟:能支持大量的用户同时收发消息,消息从发出到送达所有在线端的延时在毫秒级;

    客户端兼容性:新型的应用都是能同时跨多种设备实现消息互通的,比如网页端,手机端和桌面端,甚至智能电视等。

    聊天室架构如何设计

     

    客户端层

    处理各种设备的兼容问题,包括对ios,Android,Windows, Web等各种开发平台的语言适配;消息通道的管理维护,包括移动设备上的弱网络管理,断线重连等;保证数据安全,所有上行下行的数据包都需要加解密处理,规避数据泄露或中间人攻击等各种安全风险。

    网关接入层

    管理大量客户端连接,单个节点可以维护的客户端数量在数十万量级;处理不同类型客户端的协议兼容,由于客户端实现技术的多样性,导致客户端与网关之间底层的数据通信协议存在差异,需要由不同的接入网关做协议转换;处理数据安全逻辑;跨网络的高可用逻辑,网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?);广播消息的高效下行分发,将收到的广播消息分发到所有连接在本节点上的客户端。

    路由层

    作为业务层接入的中转,同时承担负载均衡和高可用的作用,单个业务节点处理能力达到瓶颈时更方便的扩容,路由层使业务层扩容对前置网关层完全透明;当一个网络的业务集群出现网络故障时,可以切换到备用网络,保证服务可用性。

    业务层

    处理聊天室内的业务消息,一个集群内有众多节点,节点角色相互对等,任何一个节点的故障会使整个集群的处理能力下降,但不会引起服务的中断,因为其他节点可以继续接管业务数据包的处理;业务集群同样有多个网络环境的热备,以应对可能出现的区域性网络故障。

    难点在哪里

    客户端多样性

    目前的应用都存在跨平台的需求,iOS、安卓和PC端,网页端,甚至IOT物联网设备,能连多少是多少,多多益善;但是不同开发平台之间的技术差异性极大,不是所有公司都有这么全的全栈程序猿的;如果团队开发的话单就客户端开发人员就不是几个人可以完成的。

    数据安全的保证

    当前的网络安全形势异常复杂,开发应用时如果不在通信安全上花心思,那你的用户就是在互联网上裸奔;开发者需要针对不同的平台,不同的通信技术实现可靠的安全方案,避免用户数据在传输过程中泄露,避免中间人攻击等安全风险。

    跨机房网络级的高可用方案

    当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了,用户需要的是故障无感知。

    所有环节的单点故障排除

    任何硬件和软件都存在故障的可能,我们无法避免应用罢工,那就需要随时准备替补上场。

    能应对任何用户量级的需求

    架构级做到水平扩展的能力,当用户量增长时随时可以通过堆服务器来解决,而不是将架构推倒重来。

    看完文章还是不知道怎么做?那么可以尝试借用目前已有的平台或工具,现在应用需要关注的是怎么以最快的速度抓住用户。网易云信是一个面对开发者的很好的IM云平台。十余年的研发积累,使其在即时通讯技术方面处于全国领先水平。网易云信至今已申请了60余项IM专利,远超市场同类产品。欢迎大家与我们讨论IM技术,也欢迎大家多多关注网易云信。

    另外,想要获取更多产品干货、技术干货,记得关注网易云信博客~

  • 相关阅读:
    软件工程实践2019第一次作业
    SDN第三次作业
    SDN第二次作业
    SDN第一次作业
    软工第二次结对
    #软件工程第三次作业
    2019软件工程第一次作业
    php-长文章分页函数
    Sqlilab靶机配置
    目录遍历(复现及修复)
  • 原文地址:https://www.cnblogs.com/wangyiyunxin/p/9241637.html
Copyright © 2020-2023  润新知