刘开展--状态机分层架构在直播连麦业务应用实践.pdf

《刘开展--状态机分层架构在直播连麦业务应用实践.pdf》由会员分享，可在线阅读，更多相关《刘开展--状态机分层架构在直播连麦业务应用实践.pdf（43页珍藏版）》请在三个皮匠报告上搜索。

1、例：支撑海量数据的大数据平台与架构 例：茹炳晟例：腾讯Tech Lead，腾讯研究院特约研究员正文要求：微软雅黑：最小字号 8号 宋体：最小字号 10号 等线：最小字号 12号状态机分层架构在直播连麦业务应用实践刘开展字节跳动前端工程师刘开展字节跳动前端工程师2018年毕业于哈尔滨工业大学，是论文阅读器Paperly（https:/lify.app）作者，开源笔记插件Context-note作者。2021年先后加入CloudKitchens、字节跳动等企业，主要研究低代码平台、前端提效工具等领域；当前在字节跳动直播团队，主要负责连麦业务相关架构设计与开发，在Electron、NodeJS、RT

2、C音视频等领域有较多的沉淀与实战经验CONTENTS目录1.背景介绍2.整体架构3.核心模块4.辅助基建5.设计开发流程SOP6.总结背景介绍背景介绍随着一个业务模块的复杂度逐渐升高，它所需要维护的状态（State）、上下文（Context）以及功能函数（Function）也会越来越多50+的功能函数30+的事件回调80+的上下文变量缺点示例说明充斥隐晦的状态定义【状态】=【变量判断代码】，我们很难直观发现这里其实是进入了一个明确的【状态】，这将导致后续维护的遗漏状态流转日趋复杂【拦截代码】（想象50+个执行函数前置都充斥着拦截判断而非一个纯函数）随着拦截代码&/|更多的代码逻辑，后续维护和改

3、动成本会节节攀升（一个if判断里面有10几个条件）充斥临时变量（如锁、队列等）来维持状态的生命周期由于缺乏框架层面的【状态】定义，状态的进入、退出等实现都需要额外多个临时变量来控制代码耦合模块之间为了实现状态互斥，频繁地互相引用形成耦合如果仍然基于传统的开发思路和设计模式，不久将会遇到以下瓶颈和问题：背景介绍背景介绍而以上问题，通过【有限状态机】，有望得到较好地解决有限状态机（Finite State Machine，FSM）：是表示有限个状态以及在这些状态之间的转移和动作等行为的数学计算模型。优势说明状态明确可视化将【状态】具现化为【节点】后，整个业务逻辑变成一张单向流动的有向图，我们可以清

4、晰的知道当前在哪个状态，它是从哪一个状态流转过来的状态独立原子化，函数式调用由于每个状态节点都是一个Solid的原子模块（没有闭包和生命周期），我们可以放心信任每一次状态机运行的结果是相同的得益于状态节点的原子化，因此其所依赖的Services和Executors也是函数式的，这大大方便了我们对代码的复用和抽象流程清晰，过程可回溯每一条状态流转链路都是一条【链表】，基于链表我们可以对业务流程进行回溯和快照，方便问题的快速排查和定位背景介绍Scheme-Graph整体框架整体框架整体框架核心模块核心模块-States-状态机分层模型核心模块-States-并行状态Parallel StateSp

5、awn Actor设计时已知需并行存在的状态，且每个状态都是被明确定义和同时激活可以动态创建和管理独立的处理单元，运行时根据需要创建新的实例，生命周期不局限于某个状态下核心模块-ContextContext代表状态机中的上下文，用来存储每个actor中所有state共有的数据建立在我们前面定义的State分层系统，我们对于Context的更新也是以分层的模式执行，并且遵守以下原则：1.外界只能访问【主状态机】的context，不能直接访问【子状态机】的context2.如果【子状态机】有数据需要同步给外界，则统一定义到主状态机的 ChildCoreContext（其它的则属于ChildSelf

6、Context）隐藏状态机内部细节，只通过主状态机暴露外界需要感知的上下文，降低理解的心智负担核心模块-ContextContext代表状态机中的上下文，用来存储每个actor中所有state共有的数据核心模块 Actions&Events统一在主状态机消费公共事件而不需要重复注册对事件做屏蔽（比如一些互斥场景下不能把事件透传给子状态机）核心模块 Actions&Events-Invoker受限于xstate本身Schema的编码机制，在状态机发送事件后，如果状态机内部执行的是异步逻辑，action就无法等待异步执行完成，导致外界不能感知到当前action对应状态机内部的逻辑执行是否完成以及结