业务新增审批流业务一项，综合现有业务形态分析己包含多块包含工作任务流的内容，考虑产品侧统一逻辑及优化用户体验，避免重复开发，维护多套相似代码。规划统一任务流类业务通用模块开发，在此次业务小版本落地，并逐步替代现有业务逻辑，以提升团队工作效率。

2设计过程

2.1分析多业务业务需求抽出用例模型，在设计上支持通用化需求

2.2整体分析及设计

分为业务层及工作流层，二者通过工作流模块层门户接口连接。业务层为多个业务逻辑实现。工作流层主要为工作流过程处理，由于需要进行上下文传递，主流程不错采用责任链，主链路始终支持事务，消息等非实物由外部事件到末端处理。并提基础数据统计供业务层

2.3模块细节设计分析

2.3.1工作流程处理

工作流过程处理各级单元，以链式处理完成单元，并且处理该层级自定义业务逻辑，诸如查询更新当前结果

设计细节

设计模式：责任链模式

责任链处理整个单元提交，处理结果及后续异步消息及异步事件通过上下文形式传递到末端地最终事件执行器。处理器在初始化时根据配置形成顺序，入口串行调用，整个过程除去末端外支持事务，保障了过程的原子性

2.3.2事件监听

处理审批事件，完成事件。在业务侧，事件需要审批结果，审批完成时通知等事件处理

设计细节

设计模式：观察者模式，单例

处理单元完成后产生事件，通过事件处理器分发给监听者，任务状态事件山监听者实现任务流状态变化处理。监听者以单例形式注入监听者池

2.3.4单元过程内容处理

单元在处理过程由不同的处理策略以应对不同的业务特殊需求，例如层级单元无人处理后自动走到下一层，或者通知管理者处理等

设计细节

设计模式：策略模式，装饰器模式，单例

读取该层级配置，根据层级配置来选取不同的策略算法处理下一步执行动作

2.3.5模块入口

提供模块对外交互的入口，隐藏模块内部细节，以达成清晰的交互界面

设计细节

设计模式：外观模式

使用外观模式统一操作入口，业务调用，提供配置，发起，通过，查询等，API模块部协同调用不同的子模块进行处理

3.总结

通过抽象通用流程处理模块，提高工作效率及代码质量，降低工程风险合理化应用设计模式实现模块内部代码复用，并提供充分的可扩展性以适应变化的业务需求。此次模块主要围绕责任链及观察者模式，设计了处理流程及消息处理器，并可应用装饰器、模板、组合等设计模式扩展各层级功能来应对不同业务需求
足够抽象的框架以支撑多样化的业务

1.摘要

设计复杂业务框架时，需要着重关注点在需求的满足及实现它们之间的平衡。在研发过程中应用ADD流程，支撑设计达成需求落地的完整性及质量要求，防止过度设计，其作为框架及架构设计工具，支持持续迭代及文档化，可有效梳理设计过程。本文以用户信息模块为例

2.设计过程

2.1用例模型

用例模型由需求转化，来源于需求及具体场景，区分是否核心用户或用优先级评估重要程度

2.2质量属性

针对用例及系统提出质量指标，具体地量化目标，评价指标的重要程度及实现难度。质量属性是设计的核心依据，架构的设计决定的主要来源。针对用例和系统整体多角度提出系统的质量属性要求，不仅限于功能性，性能，可靠性等方面系统设计目标更具体。

2.3约束条件

指在架构中的客观因素，包括不限于系统现状，基础建设，人员配备等影响设计的关键因素

2.4架构关注点

在设计过程中前置的设计意见，包括外部意见，保证设计逻辑完整同时兼顾环境因素

2.5设计决定

由用例及质量属性输出设计决定，设计决定不是具体的代码或者逻辑，而作为系统开发的指导规定系统的方向及实现的概况。设计输出不是一蹴而就的，通过多轮迭代完善满足需求目标，可通过看板等工具进行完成度管理。多轮的迭代支持需求的新增或敏捷方法提升系统的完成度，实现阶段交付

2.5设计视图

设计图有利于设计高效直观地展示并文档化。作为设计文档化的阶段部分，有设计总图和局部图，形式不局限于常见的UML，ADL，或者设计草图。以下以简单设计草图为例。

2.6总结

综上，质量驱动设计可广泛用于架构，框架设计等质量指标要求的系统当中，通过需求的分析转化结合多种因素输出设计决定形成逻辑闭环。设计过程流程化文档化，形成有效输出成果以指引开发工作，并支持不断迭代。在复杂需求中能有效梳理和问题发现，控制项目质量与成本，降低项目风险

业务涵盖C端用户提交文本输入功能,需要进行内容审查控制。商品评论等互动即时需要,要对文本进行敏感词检测及模糊处理, 并风险提示。实现基础敏感词检测，采用Trie树组织字典，针对业务场景进行组织多词典及歧义处理，达到更准确识别效果

2 方案设计

基于 Trie 树的词检查, 改造开源分词方案 analyze-ik, 实现敏感词检测。 模块功能需求： 1- 检测并去除评论中的敏感词汇 2- 词典包括基础初始配置,热加载 3-词典租户隔离

1.2 核心功能

Trie (也称为基数树或前缀树)是基于树的数据结构,通常节点存储的是字符串。它和 HashMap 类似存儲的是关联数组结构,但它的每个节点存的是部分的字符串数据。HashMap 仅支持完 全匹配的查找,Trie更支持前缀匹配 （不然怎么叫前缀树）。例如在文本"场上有杂耍", 在哈希表中只能精准匹配"广场上有杂耍"这一句,字典树的搜索在搜到"广场","杂耍"更细 的词。 Trie 树构建, 它的实现是多叉树,每个节点是具体的字符及它的状态。如果构建"广场","广播",广播站","杂耍", 实际上的词典, 根节点为空, "广场" 在树中占两个节点, 黑色节点标识 这个词的结束。"广播"和"广场"有共同的节点"广,"广播"和"广播站"有共同的两个节点"广“和"播”。由于中文字数较多, 词普遍在四字内,则 可以认为树的宽度要远大于高度。

实现中 childrenArray/childrenMap存储下级节点, 当下级节点 小于一定值时使用数组, 超过才使用 map, 以达到节省内存空间目的,nodeState为节点状态标志, 是否是词的最后一个字符,nodeChar是字符本身

Trie树的建构是为了更高效的查找，前缀的数据结构下，符合DFA(确定性有限自动机)模型,下图是对应词库的状态转移图，图中同Trie树相似，每个节点表示一种状态，双线的状态是Final态，表示结束可以匹配输出一个关键词，有向的边表示事件，对应的是某个字符。
比如我们输入一个“广播”字符串，那从A开始，第一个字输入是“广”，则顺利到X,第二字是“播”，则到E，输出“广播”，没有后续输入了，便到此为止。同样一个匹配不到的例子，输入“天天早起”，同样从A开始，“天”转移到U, 下一个“天”没有匹配的事件，那么这次就找不到匹配的词了，“天天早起”就没有匹配的输出。

那么问题来了，“天天广播“有没有输出呢，按照之前的前缀匹配规则自然是没有的，但我们需要把“广播”这个词识别出来，所以此处不能是前缀匹配，也不是精准匹配，“天”虽然失败了，“广”字也要成功，那么就要从“广”字重新去匹配，这样就要每次逐字从头匹配或者回溯，去匹配失败点。这里采用类似广度遍历的方式，而非回溯，从原字符串逐字匹配字符，通过上下文进行传递，实现的穷举最大复杂度为O(n*m)，但由于中文词普遍较短的特点，匹配串的m其实是个有限常值。
例子 “天天广播“ ，逐字演示它的匹配过程：

a.从字符串天(1)开始，匹配到A的“天”，将天(1)添加到上下文
b.读取第二个字天(2)，上下文中U-天(1)没有下一个“天“的事件，不到下一轮。天(2) 匹配到A的“天”，将天(2)添加到上下文
c.读取第二个字广(3)，上下文中U-天(2)没有下一个“天”的事件，不到下一轮。广(3) 匹配到A的“广”，将X-广(3)添加到上下文
d.读取第四个字播(4)，上下文中X-广(3)有下一个“播”的事件，将E-广(3)播(4)添加到上下文。E-广(3)播(4)到达词尾，输出关键词“广播”到结果
e.到达字符串结尾，输出结果

1.2歧义优化

“下雨天留客天留我不留”，这是一句广为人知的典故，说是雨天客人求宿，主人留语送客，客巧解为“下雨天，留客天，留我不？留！”，而主意为“下雨，天留客，天留我不留。”汉语复杂，巧思断句，同时也为正确理解句子增加了难度。比如“你是刹笔“的”刹笔“在是典型的骂人词汇，但在“前车急刹笔者撞车了”，句中这两个字显然不是。
这里就需要区分常规词汇和敏感词汇，用多组Trie树对字符串进行多次标记，优先加载敏感词汇

这样通过多次标记定位语句中的敏感词汇，但问题也来了，刚说在“前车/急刹/笔者/撞车/了”这句话中，显然“刹笔“不是一个符合断句逻辑的词汇，这里就要通过歧义裁决处理”急刹笔者”这段冲突
方案A是 急刹/笔者
方案B是 刹笔

裁决逻辑的优先级：有效文本长度>词元个数>路径跨度>切分终点位置>敏感词占比>词长平均值>词元位置
方案A 有效文本长是4；方案B 有效文本长是2。
所以此处采用A切分方案，即 “前车/急刹/笔者/撞车/了”，不包含敏感词

1.3字典管理

1.3.1 字典热加载

敏感词库自定义添加同Trie树构建不再赘述。从树中删除某个词比如在树中热删除广播和天上，只需要把末字节点置为非末尾。后续词典跟随服务的重启等进行释放。

1.3.2 多租户内存优化

云服务模块需要针对不同租户定义不同的敏感词，常规词字典租户共库，行业分类词典及敏感词字典采用懒初始化。在多租户服务中，大量的前缀树会占用大量内存，使用租户id进行服务实例请求路由及词典池来节约实例内存。

3.性能测试

测试使用30M字共400K条新闻及评论语料作为检测文本，测试不同敏感词数下性能。可见在基于Trie树查找在词汇量上升情况下性能没有明显波动，符合预期，使用正则匹配时间线性增长。在总体正则耗时均高于Trie树查找。在内存使用上Trie树高于正则编译后对象大小

   代码审查本身的必要性其实不必多言，再优秀的程序员也会犯低级错误，代码审查就是在代码成果交付时由开发发起的一次QA。与测试不同，代码审查完全是透明的，所以在这个动作中就有更有效率问题发现和解除能力。在降低风险角度，代码审查等于在开发阶段引入双重保障，减小问题持续暴露到生产的概率。除去业务相关，额外收益是审查带来代码质量的提升，开发者有机会获得优秀的编码意见，从而引导更优雅的实现和自我提升。

   在推进新的审查规范前，原来嵌入研发流程本来是有一个审查规定，即git的master分支的merge权限只在部分有审查能力的员工，规定在发布前进行代码审查。这个流程尴尬点在于，在一般项目推进中，没有给CR分配工时，或者分配了工时在较紧张的开发过程中被挤压掉了，导致动作最终流于形式。

   所以，合理考虑流程与审查质量是强相关的。此外，规范的逻辑完整，实操性，推进层次的规划都是需要在考虑之中的，这些点不多作表述。

   审查内容。一个是代码规范，目前有sonar的平台的检查点，阿里开发手册，以及迄今为止的一些工程问题的汇总，作为参考。再加之必查的高频高风险检查清单。审查内容有时候不是问题，反而审查力度权衡是关键。

   审查过程。作为程序开发，总有一种误区觉得一定要是搭一个什么平台来做这个事情，但回归事情本身，其实做了这件事再去优化效率更重要。所以在推进初期，在规范框架下通过简单的文档和人肉的流程管理更具有灵活性。评审形式也在桌面和会议审查视规模和重要程度来确定。后期在跟踪过程中，支撑异步审查和远程审查的必要，才有规划进行平台的搭建。

    结果和跟踪。问题是不是问题，真的是要一刀切吗？目标和期望往往是完美的，但现实总是缺点意思，毕竟每个人的水平有差异，项目也有很多因素不一定要做到代码的完美。所以让问题留在规范里面更重要。在简单业务堆砌项目中，低风险的低质量代码在日程紧急的场景下上线的可能必须在规范里有所体现，即问题的分级。其优势在于可以构造跟踪能力在后续推进优化。

   实践中负载可在架构中应用于多层，常见的流量在 DNS ->L4->L7 环节皆可设计应用负载均衡策略。

   负载均衡算法中常见有随机，轮询，哈希，最小活跃，最小处理时间。私以为分为开环负载均衡和闭环负载均衡，前三者属于开环，后二者基于反馈调整属于闭环。

   当前成熟负载均衡一般还包括加权策略，慢启动策略。加权策略应用于服务实例算力不均衡场景，慢启动则应用于热加载的实例注册瞬间避免瞬时高压。

     一般负载均衡不区分优劣，只在适合场景选择对应，较通用为随机或轮询。在合理设计本地缓存等指向性优化场景下哈希策略更适用通过关键词将指定关联消息送往同一服务实例以加速。最小活跃度和最小时间策略则能较为动态地将消息指向压力较小的服务实例，在服务实例算力和任务压力不均衡场景，尤其是有动态算力调整能力的云服务场景下较为适配。

     在负载策略设计定制过程中，尤其是高并发或者大任务业务，需要进行充分设计场景还原的验证。