2023年10月31日-11月2日，2023云栖大会在中国杭州·云栖小镇举行，北京数美时代科技有限公司首席架构师陈建在【CloudOps云上运维专场】发表了题为《基于云上弹性的高可用实时风控架构实践》的主题演讲，从在线实时风控架构及高可用解决方案等方向做了分享。
陈建 北京数美时代科技有限公司首席架构师
以下是他的演讲内容整理。
本文大纲：
- 风控架构的设计
- 高可用技术架构的稳定性建设
- 如何借助云上弹性实现风控架构与高可用
数美科技成立于2015年，在过去八年一直专注于为企业客户提供风控服务，使用AI的技术帮客户真正去解决他遇到的业务风险和内容风险的问题，真正让客户专注于自己的业务发展。
一、风控架构的设计
首先，看一下数美科技的业务风控产品——天网，在这个产品之前先介绍一下数美科技是怎么定义我们要解决的业务风险问题，因为业务风险的范围非常大。
数美科技解决的是哪些业务风险？举个例子，以互联网的C端APP为例，整个互联网的C端APP在整个产品生命周期主要专注于用户的获取和运营，那势必会做流量推广、用户注册激励、活动激励等运营工作，这里的成本是很高的。但是这些钱有没有花在刀刃上、有没有带来相应的转化和相应的收益？互联网上有一批人叫黑产，它会提供虚假的流量、虚假的用户、低质的用户去薅取大量运营费用，导致大量的钱都白花了。那数美科技的天网就是解决这个问题，我们去识别虚假流量、虚假用户、低质用户，让客户的运营成本、钱真正地花在实处。
天网产品的使用其实非常简单，提供了一个API接口，客户只需要把注册等行为推送给数美，数美就可以通过用户以及用户的行为综合识别，区分虚假用户、低质用户和正常用户，并把这个结果反馈给企业，企业就可以根据这个结构进行决策，就可以选择把钱分给正常用户，大大提升运营转化效益，这对很多互联网客户是有很大的收益。
再来看内容风险。
比如，内容的爬取也是很多风险的，那内容风险是什么？企业如果在自己平台有内容，内容带来的监管类风险以及内容的平台氛围风险，如果我们不对内容进行风险管控，企业的运营会受到极大的影响，企业的平台氛围或平台的质量，也会有比较大的下降。比如，平台APP上只有几百万用户的时候，你会发现上面全是广告，那用户的体验是很差的，数美的天净产品就是为了解决内容风险的问题而推出的。内容风险有三个特点：
- 支持全媒体格式的识别。从最基础的文本、图片到音频文件、视频文件、音频流、视频流都是要支持的。
- 支持全行业、全风险内容的覆盖。内容风险本身是一个很难定义的，比如，这幅图是色情图，那色情它分很多档，它的风险定义是非常清晰的，数美通过定义的上千种业务标签去将所有内容的风险做了清晰的定义，这样客户就可以针对不同的风险做非常细粒度的控制。
- 不同行业、不同场景管控力度不同。同一个风险在不同的行业、不同场景，管控的力度是不一样的，我们需要客户在不同的场景下可以灵活配置内容管控，这些能力是天净和天网能提供的。
总结来说，天网是做用户和用户行为的识别，天净是做内容的识别，那么如何使用一套统一的架构比较优雅、高效的去支撑所有的产品，这是风控架构设计需要考虑的第一个问题；其次，大部分客户来自于互联网，互联网的特点是有很多热点、同时这些热点流量有很大不确定性，当流量发生突增的时候，我们如何保障系统的稳定性和可用性，这是面临的第二个问题。
对于”如何使用一套统一的架构比较优雅、高效地去支撑所有的产品“，这个架构设计在业界有一些标准的方法。第一看产品架构，第二看业务架构，先不看怎么实现，先看业务架构是什么样子，第三步才是技术架构。
业务架构的核心是能够清晰地定义业务对象是什么，做业务和内容的风险识别，核心对象叫审核对象，识别什么内容，有很多包括用户、内容和不同形式的，再往下深究会发现真正审核的就是四种：第一，是文本片段，给一个片段，它有没有问题；第二，是图像，图像不是图片，图像是视觉的图像，图像也没有问题，他是色情还是某个人物；第三，是音频的片段，有没有特殊的形式；第四，是行为。最后，会发现所有的内容识别对象最终会归类到这四类，只有把这四类做好之后就可以做各种不同的组合和聚合。
第二类叫基础产品对象，以图片为例，图片是可以看到图片是带有文字的，所以会把它拆分出来一部分到文字对象，同时图片一定要有图像，图片是由文字和图像组成的。再看一个音频文件，它是由音频的片段以及音频里面AI的文字来组成的，列了更复杂的叫复合类的产品，它是基础产品对象组合。
PPT里可以看到融媒体里会存在音频文件、视频文件、文本、图片，视频文件里面又有节帧、又有音频片段，节帧里会有图像会有文字，会有音频片段的文字，可以看到是很多、是纷乱复杂，通过这种层层的拆解发现就是三类对象，最复杂的是策略对象，其他都是组合，策略对象本质就是我给你策略对象，你告诉我有没有风险，再进一步抽象出两个对象来一个叫特征一个叫规则。
再举一个例子，当去识别图像是不是色情的时候，先产生模型特征，图像里面它的色情得分是多少，一般得分是零到一之间，这就是特征，叫模型特征。第二个，会产生规则，就是当图像特征中-色情图像特征大于多少的时候，返回或者认为这个图片是色情图片的这叫规则，所有的风险类型到最后全是特征和规则组合，通过这个就可以看到整个业务架构里面它整合对象和策略对象下面的细分，当我们做完这个业务对象的处理之后，就可以可以看到最后的架构是什么样子。
其实，风控架构就被很简单分为三层：
- 产品接入层，它做的是比如说限权、限流等通用服务，那下面叫PI image，就是每一个模块代表的是一个基础产品对象或者符合产品对象的实现。比如，以视频文件为例，它做的就是对文件的格式进行解析，把它解析出需要去识别的下面的策略对象然后把它调到下面就可以了，这是第一层。
- 策略层，它本质做的就是能够去对每一个策略对象识别出来它有没有风险，因为我们有只有四个策略对象，只有四个大框，每个对象里面主要可以看到叫AE开头叫advance engine高级引擎，它做的就是规则引擎的事情。BE开头的就是basic engine基础引擎，就是特征实现，还有一层做一些特征的编排，特征之间可能是有一种依赖的，策略对象也比较简单，就实现规则和特征就够了。
- 基础服务层，不管什么架构它都是通用的，一般是云提供的计算存储的资源以及服务的发现、日志采集等通用服务，因为它是比较通用的，它的稳定性、它的成本控制对整个架构的影响是非常大的，我们和阿里云这边配合得比较紧密，采用了非常多的技术，比如用Tair取代Redis MySQL，使用ESS去管理等，也大大地提高稳定性和降低成本，这就是整个风控架构的设计部分。
二、三大扩容方案应对流量突增，打造高可用架构
怎么去应对流量突增，去实现高可用？高可用的话题非常大，很多因素都会导致可用性的不足，我这里把这个话题限定在“怎么去很好地应对流量突增”。当遇到这个问题的时候，第一步还是做问题的定义， 流量突增可能想起来非常简单，但可以看到对象是分两个，一个叫产品对象、一个叫策略对象。
那到底我们要解决哪一个问题、解决什么的突增？其实产品对象和策略对象里面都会存在突增的问题，但问题是不一样的，产品对象可能是文本图片的QPS瞬间的上涨，音视频文件、音视频流是流速的快速上涨，它是比较薄的一层，他的问题不是很大，真正的问题在于策略对象的突增。
图里面大量的模块是在实现策略对象，策略对象的突增是我真正需要关注的，它决定了系统的稳定性。解决的是策略对象的流量突增的问题，第二个怎么定义已经解决了这个问题，直观上来就是不出问题，但是还是比较粗颗粒，我们把问题的解决目标做了更细的定义：
第一层，不出问题，不管你流量怎么突增，通过很好的集群容量管理，我都可以很好的把它化解。
第二层，如果真的发生了非常大的流量突增，它超过基础容量之后怎么能应对突增的流量，并且影响的时间尽可能短，通过自动扩充的机制能够把流量尽可能地恢复下来。
第三层，对于第二个层，有可能保证不了，可能确实有很多比如流量的限制做得不好或者说整个单机性能的预估不是很准。可能会到第三个情况，是模块确实产生了过载，它的性能遇到瓶颈了，怎么能保证最次兜底的情况下，也是可以保证不挂掉，就是它可以处理流量范围之内的流量，多出来的流量就把它丢弃掉，这里已经不能区分是突增的还是原有的，我们称为三个层次。
接下来分开介绍一下。
第一个，通过集群容量的管理来实现集群不受影响，列了几个对于这个目标非常有价值的模块，第一个非常符合常识，就是要有流量预测模块，它是根据历史的流量以及给客户冗余的承诺来去实时计算，这个容量应该是多少的问题。
第二个，计算出来之后怎么才能让集群容量达到真正的水位，这是第二个模块需要做的叫集群容量管理模块，它维护着系统里面每一个核心模块的能力、数量，它就可以计算出来当前这个集群到底实际上是多少容量。这是第一个数，第二个数同时知道我应该是多少，会触发自动扩容的机制，它会调用一个集群扩容模块来去实现这个模块的扩容来达到预期的集群容量。那这里有三个扩容方案来应对流量突增：
方案一：使用ESS自动扩容
早期模块部署大量的都使用ECS，并且是我们来进行管理的，每次去扩容的时候就需要自动买机器、自动初始化、自动安装模块、自动取服务，这个过程非常复杂并且非常耗时的，对于我们年轻人是非常的大的隐患，后面使用的ESS工具产品能够很好的去解决这个问题，这是第一个层次。
方案二：集群限流
本质上来讲如果是非常有钱的公司，可能不会到第二个阶段，我花了几倍的冗余就不会出问题。但实际上是不一样的，资源是有限的、能力是有限的，很多时候会出现第二种情况就是集群的容量不能够满足集群流量的突增，这个时候引入新的模块叫集群限流模块，它的核心是会实时计算出来每一个用户、每一个客户，他实时的QPS是多少，这是第一点；第二点，他可以推算出来实时的增量是多少，就是当真正出现这种集群流量不足的时候就可以很轻松地知道到底是谁产生了突增，那就会对产生突增的用户进行现金限流，这是第一步。
第二步为了进行后续的恢复还会触发扣除容量的机制，这个和上面是一样能够去快速的把人括起来，扩容的机制相当于我已经知道哪个客户突增了，突增了多少，那我会加一个阈值，加一个比例。可能是突增了三百，也可能会增加九百的QPS，突增出来了三倍，达到一个比较好的方法。
方案三：单模块扩容
这个第二个方法做得比较极致的话，很多问题也已经解决了。但是不幸的是，架构是复杂的，架构是很多时候是意想不到的，会有一个兜底的方法：
1. 当对某个模块的QPS预估不那么准确的时候可能会出现部分模块确实到了能力的极限，这个时候会触发单模块的过载保护，会丢弃超过自身能力的请求；
2. 它会触发单模块的扩容，这里的扩容和前两个场景有很大的差别，前两个场景都属于集群容量的扩容，第三个场景属于单模块的扩容，用的是ESS本身的扩容的机制来做的，也是非常好用的方法；除了本身模块会有过载保护之外会使用上游模块来去作为熔断的处理，确保不会持续地把某个模块压垮。
那经过以上三个方案之后，流量带来的稳定性问题基本就差不多解决了。
为了再走一步，做了更多的事情，因为前面是对单一集群的容量保护或者容量的管理，会增加跨集群的流量调度，当流量过来之后会把它分发到多个集群让多个集群来去同时释放这个流量，可以达到更好的效果，这些就是高可用做的一些解决方案。
以上是分享的内容，谢谢大家。
