HUAWEI河图项目后端高并发探讨

HUAWEI河图项目后端高并发探讨
一、需求
    河图项目是HUAWEI的数字新世界，可用于地图、虚拟交互等数字化服务。应对未来发展，可能会出现千万级用户同时在线、局部有十万人同时交互体验的超高并发需求。
二、需求分析
    1、超高及时并发要求：
        项目要求同场景（例如某景区前）存在十万人，并且产生交互（例如放烟花、与九色鹿对话、自身移动、定会议室、寻路等），假如每个人都在交互并且实时通知其他人，在局部场景内会产生十万*十万=百亿次广播并发，如果每人每秒同步一次（合并数据包、降低刷新频率），每秒也有百万广播并发。
    2、与其他各项目比较
        1）MMORPG网游等：业务耦合性非常高且复杂，实时性要求非常高，但是同时在线低，并发广播最多几千人（具体游戏内业务是核心，实时性要求高，对并发等要求不高）；
        2）微博、交友APP等：业务耦合度中偏低，同时在线较多，并发广播较多但不要求实时性太高（因实时性要求较低，所以虽然业务较多但是可以顺序处理）；
        3）电商：业务耦合度非常低，同时在线非常多，并发广播非常多，实时性要求非常高（因为具体业务耦合度非常低，所以较容易建立并发业务模型）；
        4）直播、聊天室等：业务耦合度非常低，同时在线较多，并发广播较多，实时性要求高（由于具体业务是一对多，所以也较容易建立并发业务模型）；
        5）钉钉等聚合APP：业务耦合度比较低，同时在线较多，并发广播不太多，实时性要求不太高（通常用事件总线搭建后台服务）；
        6）12306平台：业务耦合度比较低，同时在线非常多，并发广播比较少，实时性要求较高（不同线路天然没有耦合，所以较容易建立并发业务模型）；
        7）百度春晚红包：业务耦合度非常低，同时在线非常多，并发广播比较多，实时性要求较高（参考我以前文章浅谈如何从业务逻辑角度将百度春晚红包服务器从10万台优化到200台）；
        而本项目与以上各个项目特点均不相同，在不同的应用场景中（景区、写字楼等）可能业务耦合度较高，实时性要求高，同时在线多，并非广播非常多等特点，使项目后端架构难度很大。拿位置同步（这个业务广播量最大）来说，由于在同一场景内交互的人太多，用传统的九宫格、四叉树、八叉树方式同步位置，会造成广播量过大（很难建立并发模型）。
三、解决方案
        1）高并发的逻辑业务层借用“事件总线”的概念，对相同业务（如位置同步）建立可插拔式并行业务总线（总线间需要人为降低耦合，总线间会同步/广播数据），例如旅游景点；
        2）非高并发的简单业务可以采用聚合微服务，例如写字楼的会议室、电梯、停车场等；
        3）数据层传统的读写分离、NoSQL、分布式文件系统
        4）底层用F5做负载均衡，用LVS等做事件总线负载均衡，单点用DPDK+MTCP+KCP在5G网络上实现高速数据传输
四、效果
    采用上述架构后，对于业务耦合复杂度不太高、实时性要求不特别高的应用场景，可以支持十万用户在同场景交互，每秒并发产生千万级交互/广播数据。