直播房间服务基于CQRS的架构演进实践( 四 ) _CQRS

其中CQRS中的数据同步的相关指标，在数据保证数据最终一致性的背景下，尤其重要。整个实时性由三个部分组成，pub时间，网络传输耗时， sub处理数据，其中在我们的CQRS大盘中，就包含B端业务pub的时间监控，和C端sub业务处理的时间监控，目前网络传输耗时在毫秒级别，并且这块指标也已经在灰度阶段。

文章插图
图片
系统鲁棒性 System RobustnessCQRS的引入帮我们解耦了截然不同两种场景的系统，但是也确实引入了mq，从全局视角看又增加了一个依赖，所以系统的复杂度是增加的。为了增强系统架构的鲁棒性，我们考虑到引入另外一种备选手段来做数据同步，通过直连服务接口调用的方式，这块我们使用了我站自研的railgun消息处理组件。当两种本身可用性就很高的方法互为补充时，那么出现问题的可能，相当于两个系统同时出问题的概率，这种概率是极低的。
在整个CQRS数据链路上，我们还针对一些写场景做了异步重试来系统自愈，抵抗服务可用性的长尾不可用，另外我们也考虑到异常场景下，虽然降级到http调用同步数据，但是存量消息恢复时，数据不是最新的，所以加入过时消息走回源，保障数据正确性的设计，来尽可能让系统在各个环节的抗风险能力提升。
数据对账脚本 Data Verify Job有一种比较常见的方式，即流式对账，依靠我们数据流监控组件去实现，在设定一个经验值的时间窗口阈值内，对两边数据源的流式binlog做对比。这种对账方式比较适合终态业务对账，而我们实时直播属于反复跳变场景，目前我们利用最简单有效的方式，连接双方从库，以B端库为准进行数据对账，并且满足30s内数据一致比较，来兼容数据最终一致性，当对账脚本发现不一致后，通过日志+主动告警+机器人等手段，配合自动化修复任务做自愈的设计，从而cover住大多数异常case，做到平常0职守。
线上事故响应SOP Incident Response SOP上文的系统鲁棒性设计，最大程度保障服务的健壮稳定，以及上文兜底的数据对账机制，最大程度客观地帮助系统发现异常，而线上永远有我们意想不到的情况，所以我们设计了一套线上事故响应机制，来应对“意外” 。
首先我们从CQRS和BC服务的角度，预设配置了不同领域的关键日志或者指标告警，而且划分了不同的紧急程度。二是我们提前管理规划了告警组成员，覆盖两边领域的一线研发，并且配置不同的通知渠道，可以让最合适的同学最快地感知异常。三是我们从不同角度预设了我们可以枚举异常现象，再去枚举不同现象发生的根因，再输出可以解决的方案list，所以基于这套sop，配合我站alchemy平台tracing链路追踪能力可以迅速定位故障点，以最快速度执行预设标准步骤，达到最快恢复可用性的目的。
生产配套 Production Support一个安全的生产系统是需要一整套的“生产配套”体系，可以快速定位排障。这块我们借鉴了很多类似系统，参考了医院体系的”问诊台“，目前发育出开播互动问诊台生产配套，提升问题排障效率几乎80% 。

文章插图
图片
技术项目管理最后想聊聊技术项目的价值和实施周期。技术项目有些时候由于不会带来明显的业务增量价值，往往会被质问“为什么要做如此变更，不做这个变更业务难道不能用吗？”诸如此类的灵魂拷问。
每个阶段技术建设需要有一条经过设计的baseline，这条线应该略快于业务发展的基线一步。建设落后，技术跟不上业务，如同沙地之上建高楼，业务连续性会受到技术系统稳定性可用性的lost而直接受损。
建设过快，又有Over Design/Over Engineering的问题，所以略快过一步是合适的，保留了弹性扩展的余地，可以在需要时适配业务快速调整。
架构师和Tech Leader需要协同阶段性review当前技术建设baseline和业务的适配情况，并决定是否投入有效资源进行技术架构迭代。
技术项目从立项之日起，就需要更严格于业务项目的管理机制。业务项目的业务目标（试错/AB实验/明确性收益延展）往往不由工程师来制定，而技术项目的目标感也是需要从开始就建立起来的，这有助于关键行为路径拆解，并在项目收尾阶段进行目标&结果比对。
技术项目要有阶段性Milestone管理，技术立项 -> （原型方案讨论） -> 技术方案确定 -> 技术实施（大项目应分阶段实施，过程指标也被Track） -> 测试/验证方案（测试用例收集&review） -> 发布方案 -> 线上验收方案 -> （线上问题处理预案） -> 项目结果复盘。