作者：铭杰
阿里云云通信创立于 2017 年，历经 5 年发展已经孵化出智能消息、智能语音、隐私号、号码百科等多个热门产品。目前，已成为了国内云通信市场的领头羊，在国际市场上服务范围也覆盖了 200 多个国家。随着业务的不断壮大，云通信面临的安全风险也越来越严峻，线上每天都在发生着短信盗刷、异常流量、违法内容(黄、赌、毒、诈)等风险的入侵。
云通信风控系统的建设就是为了解决这些问题。事实上，伴随着云通信业务的发展，云通信的风控系统已经建设得比较成熟。早期的风控系统仅能支持基于规则的事中拦截，而现如今，已经能够无死角的覆盖事前、事中、事后几十个风险场景。技术手段也从单一的"规则模型"拓展到"规则模型+数据挖掘+人工智能"的复合手段。云通信风控为客户构建了一道最为坚实的防火墙，让通信业务变得安全、可靠。
云通信风控的产品形态虽然比较简单，但其背后的技术挑战十分复杂。
十万级并发，五十毫秒延时要求
云通信的业务体量非常大，且由于电商类业务有大促的特殊场景，经常要面对十倍于日常的脉冲式陡增流量。而通信又是一个有高实时要求的场景，以智能短信为例，一次完整的业务流程平均在一秒内完成。留给风控的响应时间只有 50 毫秒。苛刻的技术指标要求是第一个挑战。
复杂的业务规则
阿里云通信的业务目前已经覆盖全球大部分国家，涉及的行业大类有 30 多个，二级行业有 200 多个。业务复杂度非常高。为达到更优的风控效果，风控必须做到精细化运营，必须能够支持一国一策、一行一策、一客一策。目前，一次风控请求最多需要支持的策略数量已经突破了 500 个。面对数量如此庞大的策略，技术上要保证策略的高效执行，业务上要保证策略的可靠变更。这是第二个挑战。
高精确率、召回率要求
云通信的部分场景有广播属性，一条违法内容没有被拦截住，涉及的影响范围会非常广。所以，云通信的风控对风险识别的召回率要求非常的高。而业务上对通信的成功率也有非常严苛的要求，不能接受过高的误拦率，这又要求风控有很高的精确率。加之风控的强对抗特征，风险特征具有变异多、变种快的特性。如何在海量流量里精准识别出有效的风险特征，其难度犹如大海捞针，这是第三个挑战。
本文将探讨阿里云云通信风控系统的技术，从系统、数据、算法等角度介绍我们是如何应对技术上的各种挑战的。
系统架构及核心组件
工欲善其事，必先利其器。一个好的基础设施会给业务带来加成的效果。为解决云通信风控面对的技术挑战，我们构建了六个核心组件:
其中，决策中心是风控系统最核心的组成部分，提供了风控场景的定义，风控策略的编辑、执行等功能，起到了中枢的作用。
决策中心在执行策略时需要依赖数据中心组件，为其提供决策所依赖的数据标签，机器识别组件则为决策中心提供必要的算法模型。一次风控请求经过决策中心的运算后会得到通过、不通过、待定三种类型的结果。业务系统将根据风控实时返回的结果决定业务是否执行下去。
而对于待定的请求将会送至人工识别组件，进行人工判断再异步通知给业务系统。这里通过决策中心或者人工审核，最终一定会得出这笔请求是否有风险的结论。这个结论将同步给处罚中心，由处罚中心结合处罚策略和人工判断最终决定是否要对违法的客户进行处罚动作。最后，在风控业务的运转中，风控效果的好与坏，从大盘上看各个国家、各个行业、各个客户的风险是否可控，是否需要人工介入。这类风控大盘数据的统计分析则由风险分析组件支撑。
一个完整的风控流程如下图:
风控系统的中枢-决策中心
决策中心作为风控的核心组件至少要解决以下的几个问题：风控场景的拓展性问题；策略执行的性能问题；复杂策略的可运营问题；
为了解决上述的三个问题，决策中心中设计了四个子模块:风控场景、风控引擎、策略编排、仿真实验室来相互配合解决问题。
其中，风控场景模块负责定义接入场景所需要的相关资源：消息源标签(业务系统可以直接给到风控的标签)、算法模型、数据中心标签。通过此模块，风控系统做到了针对不同风控场景的个性化接入，有效的解决了风控场景的拓展问题。通过此模块的能力，线上支持的风险场景由个位数迅速扩展到几十个。
风控引擎承载着风控策略执行的任务。为保证风控策略的执行效果，我们在风控引擎中做了大量的优化，包括自研支持复杂决策树执行的线程模型，通过合并串行任务、策略剪枝等手段大幅度降低策略执行的线程消耗。针对算法模型任务、变量加载任务性能评级，分类管理高 IO 任务的执行，有效提升了策略执行的稳定性。通过大量的优化，风控引擎目前在十万级 QPS 压力，单次处理上百个变量，500 个以上策略，数十个算法调用的复杂度下，能够做到平均在 30ms 内返回结果。
策略编排和仿真实验室解决的是复杂策略可运营的问题。风控是一个重运营的工作，必须把风控策略的编辑权限开放给懂业务、懂数据的风控运营同学。我们构建的策略编排工具屏蔽了复杂的技术细节，隐藏了系统背后数据加载、算法模型执行等概念，给运营同学开放了易于理解的决策树编辑工具，给到运营同学策略编辑极高的自由度。从策略编排交维后，可以看到运营同学业务经验在风控领域产生了巨大的价值。
当然，复杂的策略同时也给策略的可运营性带来了挑战。动辄数百的策略放在眼前，修改任何一条规则带来的影响都是很难评估的。于是，我们构建了仿真实验室来解决这个问题。其中单例仿真可以协助运营同学判断修改的逻辑是否正确。线上仿真可以借用线上的流量验证新增策略的大盘效果是否符合预期。离线仿真则可以采样长周期的数据，在很短的时间内验证出修改的策略大盘效果是否符合预期。
策略中心的建成，彻底做到了云通信风控系统的交维。风控策略不再是研发手里晦涩难懂的代码，而是业务同学都能够理解的规则。更多的有业务经验的同学可以参与到云通信的风控建设中。但是，这就是我们的最终目标么？
数字化实践-数据驱动业务
回看过去几十年的发展，IT 系统一直是人做业务的辅助工具。人驱动系统做业务是标准的作业方式。但是在未来，数据将成为第一生产力。数字化是科学的决策方式，数字化驱动人做业务将是未来的标准作业方式。这个趋势在云通信风控业务上已经有所体现。随着风控业务复杂度越来越高，依靠专家经验的模式越来越难以支持好线上业务了。面对着错综复杂的业务规则，策略结构该如何调整？参数该如何优化？背后的风险特征数据该如何管理？数字化是唯一的答案。
在数字化的方向上我们定的原则是：
-
大方向的运营策略结构由专家经验制定；
-
策略内的效果评价和参数调优由数据驱动;
-
大量沉淀风险特征数据为策略提供弹药；
第一，团队内对于风控策略的通用结构整体采用国家+行业+险等级的模式管理。对于部分大客户，case by case 的采用定制化策略解决问题。对于通用结构需要构建大量的客户画像标签以支持对客户的分类。由于线上的客户所做行业不唯一，单纯的客户维度画像无法解决流量级别风控策略的定义。所以，我们下钻了行业标签的粒度。以智能消息为例，客户的画像不再聚焦于客户上，而是签名和模版上。客户画像组件先通过算法识别对应签名和模板的行业，再通过人工复核大客户的方式最终确定行业标签。最后，再根据信用评级积分算法评估出每个客户在不同行业的风险等级。通过以上的手段，风控策略可以做到了流量级的精细化管理。
第二，在策略结构明确后，对于策略内不同算法的阈值调整，风险分析组件提供了详细的策略调优工具。我们可以清晰的看到不同策略的流量分布，拦截率详情，以及风险 case 覆盖率，并能够通过线上的风控效果给出推荐的策略及算法模型参数的调优建议。通过此类工具的应用，数据可以开口说话，给出比专家更专业的指导意见。线上的策略调优不再是凭着经验试水了。
第三，借力云原生底座+自研风险库组件解决了海量特征数据沉淀的问题。
云通信面对的风险特征数据动辄数亿，且由于业务的易变性，数据集的变化幅度非常大。需要快速支持海量数据的导入、导出。由于风控引擎对特征数据集的使用基本上是 KV 形式的查询，所以技术选型上抛弃了关系型数据库，选择了云原生的 Lindorm 服务。
其宽表模式非常适合风险特征库的动态扩展。但是 Lindorm 的缺点也比较明显，只支持基于 rowKey 的查询，对于后台运营同学需要的检索功能支持的不好。无法支持高性能的模糊检索。对于突增高并发流量的查询冷启动会导致瞬时毛刺。为了解决这些问题，云通信风控团队基于 Lindorm 的宽表模式自研了一套适用于风控场景的风险库：
在这套方案中，首先要解决的是风险库的建库和数据的导入。我们基于 MaxCompute 开发了一套标准的离线风险特征数据的生产、同步流程，可以支持十亿级风险特征数据 T+1 的同步。同时复用 Lindorm 的能力对外封装了动态建表、小流量数据导入 API。Lindorm 作为海量冷数据的存储载体，天然能够支持十万级 QPS 的高并发查询的毫秒级响应。
为了支持高并发流量的冷启动，针对部分有极高性能要求的风险库会采取预加载热数据的方案将部分数据缓存在 redis 中。至此，对于精确查询的场景已经完美的解决了。其次，对于模糊匹配的查询，我们将风险特征数据加载到本地内存里并构建成前缀树的结构，有效的支持了万级风险特征数据的模糊查询。最后，我们采用 OpenSearch 给控制台提供了基于分词的复杂检索能力，解决了风险库的可运营问题。
通过数字化的实践，我们已经能够发挥出风控平台的最大潜力了。但是说到底，风控识别风险最主要的手段还是模型。下面我们来看一下云通信风控团队在规则模型和算法模型上的实践。
规则模型和算法模型的互补
规则模型具有简单，解释性强，开发上线速度快的优点。在阿里云云通信风控的历史上，规则模型解决了大部分问题。但是，随着业务的发展，不法分子使用的手段隐匿性越来越强。规则模型覆盖范围小，误杀率高的缺点越来越明显。很多风险特征必须依赖算法模型去识别。当然算法并不是万能的，很多场景要想达到一个好的效果，更多需要依靠算法和规则组合使用来解决。
在构建风控算法模型时，面对的第一个问题是风控的自研算法是集成至策略中心内还是独立构建。在策略中心内集成的好处是减少了 RPC 调用的环节,RT 比较可控。但是，算法的性能不稳定，很可能一个算法的效果不好会影响策略中心整体的可用性。加之集团内有很多算法团队可以提供现成的算法组件，策略中心一定会集成大量的外部算法依赖。所以，为保持架构的一致性。算法模型的工程服务独立于策略中心构建。这里我们采用了云原生的 PAI+EAS 的解决方案，可一站式完成模型的训练和部署工作。
第二个问题，云通信风控要求的 RT 仅有 50ms，那么留给算法的响应时间不会超过 30ms。这对算法的挑战非常大。所以我们在选择开发哪些算法模型时，会尽量让模型提供和业务无关的原子能力。然后通过规则组合多个模型的结果来达成业务效果。比如在做内容风险识别时，NLP 算法模型识别文本内的可能风险类型、语义通顺度模型会提供语句通顺的程度，而规则模型会识别内容中包含的风险关键字。风控策略会组织所有模型的结果，综合判断本次请求是否有风险。
第三个问题，算法模型上线如何做效果评估。我们比较好的实践是把模型效果的离线评估和模型在业务场景中使用效果的在线评估分开来做。算法团队仅对离线评估数据的精确率和召回率负责，在模型达到预期指标时即可上线。而模型在业务上的使用效果则通过模型上线前和上线后的业务指标对比给出结论。文章来源：https://www.toymoban.com/news/detail-787488.html
阿里云云通信的风控系统经过长期的发展已经打磨出了一套行之有效的解决方案，对于云通信的线上风险能够做好比较好的控制。回首过去，阿里云云通信依托于阿里云的基础架构和云原生架构已经打好了深厚的基础。展望未来，数字化和智能化将是主旋律。阿里云云通信的风控团队将不遗余力的深耕在云通信这篇土地上，为客户打造一朵可信的通信云。文章来源地址https://www.toymoban.com/news/detail-787488.html
到了这里，关于阿里云云通信风控系统的架构与实践的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
