企业官网建设流程全解析

网站备案为什么 没有批复文件,网页制作与网站开发从入门到精通,网页设计图片滑动,网站产品展示方案近期笔者在投入变更风险防控开放平台的额外功能开发#xff0c;目的是希望设计一套更加灵活的变更风险观测策略匹配机制#xff0c;能够在满足面向任意变更场景应用观测策略的同时#xff0c;尽可能保证产品体验#xff0c;让用户清晰地了解到自己配置的什么策略能够在什么…近期笔者在投入变更风险防控开放平台的额外功能开发目的是希望设计一套更加灵活的变更风险观测策略匹配机制能够在满足面向任意变更场景应用观测策略的同时尽可能保证产品体验让用户清晰地了解到自己配置的什么策略能够在什么情况的变更过程中生效。在先前的文章当中有粗浅提到变更观测策略匹配的事情但没有深入探究并且笔者以前接手的项目很多底层设计的技术债也难以偿还要在以前实现的基础上再做重构也不是很现实了。所以趁着扩展新系统的机会笔者重新思考了下变更风险观测策略匹配机制的事情跟随这篇文章来抛砖引玉下自己的想法。首先还是一个根本问题一条变更风险观测策略的粒度是怎样的如果粒度太粗那么从产品视角很容易导致「所见非所得」的问题如果粒度太细那么用户配置起来也会相当麻烦。经评估由单个检测能力执行的粒度代表一条策略这样的形式相对合理不仅方便产品层面做「所见即所得」的设计而且实际执行过程中也可以以原子化的形式做编排从调度角度来讲也很容易扩展。详细来讲一条策略在设计上需要关联以下几类概念检测能力1个变更风险观测能力和1套能力执行/调度参数变更场景以变更渠道/类型/阶段3个维度描述变更场景1条策略匹配1个变更渠道N个变更类型N个变更阶段变更对象1个范围的变更对象同时也要支持细粒度的变更对象KV属性检测能力的执行调度这部分不用太细讲变更场景的话从经验角度每个变更工单有多个变更阶段所以变更观测需要观测的维度也是阶段维度这样的话按照变更渠道/类型/阶段去拆解变更场景也是比较合理的。设计上的纠结点主要在于变更对象匹配在实际场景中如果变更对象是以树的形式管理的那么匹配变更对象可能得匹配某个非叶子节点如果变更对象可以用通用的string表达那么用户也可能希望一条策略匹配多个string或者正则。在这个基础上有时用户也希望某条策略去匹配某个顶层的树节点但又豁免掉下级的某些子节点。所以由这些需求反推我们可以简单得到这样的变更对象Matcher设计typeChangeObjectMatcherstruct{ObjectTypestringjson:object_type// 树类/字符串类变更对象TreeNodeIDs[]stringjson:tree_node_ids// 树类变更对象匹配的树节点ID列表ObjectValues[]stringjson:object_values// 字符串类变更对象匹配的字符串值列表也可以是正则表达式ObjectAttributesmap[string]anyjson:object_attributes// 字符串类变更对象匹配的KV属性键值对ExcludeMatchers[]ChangeObjectMatcherjson:exclude_matchers// 子节点匹配器用于排除某些子节点}在这个基础上我们能够很方便表达出「匹配一个范围的变更对象豁免多个子范围的变更对象」这个事情。当然实际ExcludeMatcher应该往外面提一个字段做成「在多个子变更场景下豁免多个子范围的变更对象」会更加合适。至于前端分页需要从DB筛选一波之后内存再筛选一波然后再做分页这个取决于策略的量级至少在笔者的实战场景下DB查询已经可以变更场景树节点第一波出来的策略数量也不会过百那么在内存里做分页对内存的开销也是可以接受的。即便如此要兼顾产品设计和观测任务运行时的「所见即所得」的话还有两件事情要做。第一件事情是需要从变更对象的角度另外增加一套ExcludeMatcher。这样做是因为用户操作层面可能在前端可以看到某些策略是否匹配上但也希望能够看到这些策略的启禁用情况。这个启禁用是变更对象视角下的所以需要有另一套ExcludeMatcher来表达。第二件事情是需要把前端视角的匹配逻辑和检测任务视角的匹配逻辑区分两个Policy。这是因为前端视角下筛选条件有限理论上肯定无法「所见即所得」比如我们需要匹配细粒度的ObjectAttributes那只有在检测任务运行时才会知道。所以除了产品设计上需要有额外的说明之外检索流程设计上用一个单独的MatchPolicy字段去表达比如MatchPolicy为Runtime就匹配细粒度的变更属性那这样写策略匹配逻辑就比较方便了。