【架构艺术】变更元信息分析框架设计

在变更风险防控领域,对于线上变更元信息的分析是非常重要的一部分,这是因为,只有理解了变更元信息,结合自主定制的变更规范,才能够知道具体的变更风险在哪里。不同的变更风险防御能力,实现的思路可能是不同的,因此很有可能出现对于一次变更,在信息的理解上有所不一致,从而导致检测结果不够置信。基于此,我们需要一个独立的变更元信息分析框架,把所有的变更元信息分析过程和结果都归到一个独立的系统当中。这样,从变更风险防御能力的视角,变更分析的结果都是共享的、全局的、一致的,从而能最大限度提升变更风险防御能力可挖掘的潜力。

本文,就简单聊一下,变更元信息分析框架设计的部分重点。

首先第一个问题是,变更元信息的来源是什么?简而言之,如果要获取到变更元信息,一个变更平台需要在发起变更、变更期间和变更结束之后,都上报和当次变更相关的元信息给到分析框架。如果把一个企业内部所有的变更平台都考虑到一起,那么变更上报次数量级是非常大的,因此一个比较好的方法是,通过一个变更事件MQ去承载变更元信息的上报和消费,从而起到均衡性能的作用。在这样的基础上,变更元信息分析工作,就可以是异步的,基于变更事件驱动的模式。

其次问题是,分析的对象是什么?可以简单划分成三类。第一类是变更的对象本身,比如我们需要了解到,某个服务的上下游链路如何,重要度如何,是否涉及资损风险,这些都是服务本身的属性,并且也是在变更过程中需要考虑的;第二类是变更工单过程,这个是核心的变更对象,我们需要判断某次变更是否存在风险,就需要对一次变更工单进行分析,比如是否在高峰期发布,是否通过管控赦免,变更的需求背景等等,都是变更工单维度的分析信息;第三类是变更阶段,这是在变更工单维度上,向下拆解出来的一类分析对象,描述变更过程每一个阶段的实际情况,尤其是小批次灰度阶段的变更元信息,是变更风险防御需要着重去关注的。

变更事件上报的信息,一般是变更工单或者变更阶段维度的,而变更服务实体这个维度,在事件内容里,不一定会有标准化的体现。因此,如果要将变更事件和变更元信息分析结果做映射,就需要标准化三类变更分析的对象的数据结构和元信息提取逻辑。

然后一个问题是,分析结果会怎么出来?这里有多种可能性,一种可能性是框架本身在接收到变更事件后,把事件dispatch给符合事件过滤条件的变更元信息分析器;另一种可能性是,分析器离线(定时)运行,上传结果给到变更分析框架。为了兼容这两种可能性,我们就需要标准化分析结果的存储接口,以及分析对象的生成逻辑。尤其是,有了后者以后,不论是受控被调度的分析器,还是离线分析器,都能通过某种方式,将分析结果映射到具体的分析对象,这样就满足了兼容的需要。

最后一个问题是,如何支持分析器的运作?不论是离线还是受控的分析器,有可能实质也是一个变更事件消费者,是一个多节点运行的服务,这样就会产生分析缓存数据共享的问题。因此,分析框架在研发的过程中,也需要考虑建设一些工具或者分析器框架,去提升分析器的开发效率。就和游戏引擎一样,通过工具插件,为游戏开发赋能。

以上便是变更元信息分析框架设计的一些重点思路和考量。解决了以上问题,一个简约的变更元信息分析框架则呼之欲出。

版权声明
本文为博客HiKariのTechLab原创文章,转载请标明出处,谢谢~~~