数美科技首席架构师陈建:基于云上弹性的高可用实时风控架构实践

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 2023年10月31日-11月2日,2023云栖大会在中国杭州·云栖小镇举行,北京数美时代科技有限公司首席架构师陈建在【CloudOps云上运维专场】发表了题为《基于云上弹性的高可用实时风控架构实践》的主题演讲,从在线实时风控架构及高可用解决方案等方向做了分享。


2023年10月31日-11月2日,2023云栖大会在中国杭州·云栖小镇举行,北京数美时代科技有限公司首席架构师陈建在【CloudOps云上运维专场】发表了题为《基于云上弹性的高可用实时风控架构实践》的主题演讲,从在线实时风控架构及高可用解决方案等方向做了分享。


陈建 北京数美时代科技有限公司首席架构师


以下是他的演讲内容整理。


本文大纲:

  1. 风控架构的设计
  2. 高可用技术架构的稳定性建设
  3. 如何借助云上弹性实现风控架构与高可用



数美科技成立于2015年,在过去八年一直专注于为企业客户提供风控服务,使用AI的技术帮客户真正去解决他遇到的业务风险和内容风险的问题,真正让客户专注于自己的业务发展。


一、风控架构的设计


首先,看一下数美科技的业务风控产品——天网,在这个产品之前先介绍一下数美科技是怎么定义我们要解决的业务风险问题,因为业务风险的范围非常大。



数美科技解决的是哪些业务风险?举个例子,以互联网的C端APP为例,整个互联网的C端APP在整个产品生命周期主要专注于用户的获取和运营,那势必会做流量推广、用户注册激励、活动激励等运营工作,这里的成本是很高的。但是这些钱有没有花在刀刃上、有没有带来相应的转化和相应的收益?互联网上有一批人叫黑产,它会提供虚假的流量、虚假的用户、低质的用户去薅取大量运营费用,导致大量的钱都白花了。那数美科技的天网就是解决这个问题,我们去识别虚假流量、虚假用户、低质用户,让客户的运营成本、钱真正地花在实处。


天网产品的使用其实非常简单,提供了一个API接口,客户只需要把注册等行为推送给数美,数美就可以通过用户以及用户的行为综合识别,区分虚假用户、低质用户和正常用户,并把这个结果反馈给企业,企业就可以根据这个结构进行决策,就可以选择把钱分给正常用户,大大提升运营转化效益,这对很多互联网客户是有很大的收益。



再来看内容风险。


比如,内容的爬取也是很多风险的,那内容风险是什么?企业如果在自己平台有内容,内容带来的监管类风险以及内容的平台氛围风险,如果我们不对内容进行风险管控,企业的运营会受到极大的影响,企业的平台氛围或平台的质量,也会有比较大的下降。比如,平台APP上只有几百万用户的时候,你会发现上面全是广告,那用户的体验是很差的,数美的天净产品就是为了解决内容风险的问题而推出的。内容风险有三个特点:


  1. 支持全媒体格式的识别。从最基础的文本、图片到音频文件、视频文件、音频流、视频流都是要支持的。
  2. 支持全行业、全风险内容的覆盖。内容风险本身是一个很难定义的,比如,这幅图是色情图,那色情它分很多档,它的风险定义是非常清晰的,数美通过定义的上千种业务标签去将所有内容的风险做了清晰的定义,这样客户就可以针对不同的风险做非常细粒度的控制。
  3. 不同行业、不同场景管控力度不同。同一个风险在不同的行业、不同场景,管控的力度是不一样的,我们需要客户在不同的场景下可以灵活配置内容管控,这些能力是天净和天网能提供的。


总结来说,天网是做用户和用户行为的识别,天净是做内容的识别,那么如何使用一套统一的架构比较优雅、高效的去支撑所有的产品,这是风控架构设计需要考虑的第一个问题;其次,大部分客户来自于互联网,互联网的特点是有很多热点、同时这些热点流量有很大不确定性,当流量发生突增的时候,我们如何保障系统的稳定性和可用性,这是面临的第二个问题。



对于”如何使用一套统一的架构比较优雅、高效地去支撑所有的产品“,这个架构设计在业界有一些标准的方法。第一看产品架构,第二看业务架构,先不看怎么实现,先看业务架构是什么样子,第三步才是技术架构。


业务架构的核心是能够清晰地定义业务对象是什么,做业务和内容的风险识别,核心对象叫审核对象,识别什么内容,有很多包括用户、内容和不同形式的,再往下深究会发现真正审核的就是四种:第一,是文本片段,给一个片段,它有没有问题;第二,是图像,图像不是图片,图像是视觉的图像,图像也没有问题,他是色情还是某个人物;第三,是音频的片段,有没有特殊的形式;第四,是行为。最后,会发现所有的内容识别对象最终会归类到这四类,只有把这四类做好之后就可以做各种不同的组合和聚合。


第二类叫基础产品对象,以图片为例,图片是可以看到图片是带有文字的,所以会把它拆分出来一部分到文字对象,同时图片一定要有图像,图片是由文字和图像组成的。再看一个音频文件,它是由音频的片段以及音频里面AI的文字来组成的,列了更复杂的叫复合类的产品,它是基础产品对象组合。


PPT里可以看到融媒体里会存在音频文件、视频文件、文本、图片,视频文件里面又有节帧、又有音频片段,节帧里会有图像会有文字,会有音频片段的文字,可以看到是很多、是纷乱复杂,通过这种层层的拆解发现就是三类对象,最复杂的是策略对象,其他都是组合,策略对象本质就是我给你策略对象,你告诉我有没有风险,再进一步抽象出两个对象来一个叫特征一个叫规则。


再举一个例子,当去识别图像是不是色情的时候,先产生模型特征,图像里面它的色情得分是多少,一般得分是零到一之间,这就是特征,叫模型特征。第二个,会产生规则,就是当图像特征中-色情图像特征大于多少的时候,返回或者认为这个图片是色情图片的这叫规则,所有的风险类型到最后全是特征和规则组合,通过这个就可以看到整个业务架构里面它整合对象和策略对象下面的细分,当我们做完这个业务对象的处理之后,就可以可以看到最后的架构是什么样子。



其实,风控架构就被很简单分为三层:


  1. 产品接入层,它做的是比如说限权、限流等通用服务,那下面叫PI image,就是每一个模块代表的是一个基础产品对象或者符合产品对象的实现。比如,以视频文件为例,它做的就是对文件的格式进行解析,把它解析出需要去识别的下面的策略对象然后把它调到下面就可以了,这是第一层。


  1. 策略层,它本质做的就是能够去对每一个策略对象识别出来它有没有风险,因为我们有只有四个策略对象,只有四个大框,每个对象里面主要可以看到叫AE开头叫advance engine高级引擎,它做的就是规则引擎的事情。BE开头的就是basic engine基础引擎,就是特征实现,还有一层做一些特征的编排,特征之间可能是有一种依赖的,策略对象也比较简单,就实现规则和特征就够了。


  1. 基础服务层,不管什么架构它都是通用的,一般是云提供的计算存储的资源以及服务的发现、日志采集等通用服务,因为它是比较通用的,它的稳定性、它的成本控制对整个架构的影响是非常大的,我们和阿里云这边配合得比较紧密,采用了非常多的技术,比如用Tair取代Redis MySQL,使用ESS去管理等,也大大地提高稳定性和降低成本,这就是整个风控架构的设计部分。


二、三大扩容方案应对流量突增,打造高可用架构


怎么去应对流量突增,去实现高可用?高可用的话题非常大,很多因素都会导致可用性的不足,我这里把这个话题限定在“怎么去很好地应对流量突增”。当遇到这个问题的时候,第一步还是做问题的定义, 流量突增可能想起来非常简单,但可以看到对象是分两个,一个叫产品对象、一个叫策略对象。



那到底我们要解决哪一个问题、解决什么的突增?其实产品对象和策略对象里面都会存在突增的问题,但问题是不一样的,产品对象可能是文本图片的QPS瞬间的上涨,音视频文件、音视频流是流速的快速上涨,它是比较薄的一层,他的问题不是很大,真正的问题在于策略对象的突增。


图里面大量的模块是在实现策略对象,策略对象的突增是我真正需要关注的,它决定了系统的稳定性。解决的是策略对象的流量突增的问题,第二个怎么定义已经解决了这个问题,直观上来就是不出问题,但是还是比较粗颗粒,我们把问题的解决目标做了更细的定义:


第一层,不出问题,不管你流量怎么突增,通过很好的集群容量管理,我都可以很好的把它化解。

第二层,如果真的发生了非常大的流量突增,它超过基础容量之后怎么能应对突增的流量,并且影响的时间尽可能短,通过自动扩充的机制能够把流量尽可能地恢复下来。

第三层,对于第二个层,有可能保证不了,可能确实有很多比如流量的限制做得不好或者说整个单机性能的预估不是很准。可能会到第三个情况,是模块确实产生了过载,它的性能遇到瓶颈了,怎么能保证最次兜底的情况下,也是可以保证不挂掉,就是它可以处理流量范围之内的流量,多出来的流量就把它丢弃掉,这里已经不能区分是突增的还是原有的,我们称为三个层次。



接下来分开介绍一下。


第一个,通过集群容量的管理来实现集群不受影响,列了几个对于这个目标非常有价值的模块,第一个非常符合常识,就是要有流量预测模块,它是根据历史的流量以及给客户冗余的承诺来去实时计算,这个容量应该是多少的问题。


第二个,计算出来之后怎么才能让集群容量达到真正的水位,这是第二个模块需要做的叫集群容量管理模块,它维护着系统里面每一个核心模块的能力、数量,它就可以计算出来当前这个集群到底实际上是多少容量。这是第一个数,第二个数同时知道我应该是多少,会触发自动扩容的机制,它会调用一个集群扩容模块来去实现这个模块的扩容来达到预期的集群容量。那这里有三个扩容方案来应对流量突增:


方案一:使用ESS自动扩容


早期模块部署大量的都使用ECS,并且是我们来进行管理的,每次去扩容的时候就需要自动买机器、自动初始化、自动安装模块、自动取服务,这个过程非常复杂并且非常耗时的,对于我们年轻人是非常的大的隐患,后面使用的ESS工具产品能够很好的去解决这个问题,这是第一个层次。



方案二:集群限流

本质上来讲如果是非常有钱的公司,可能不会到第二个阶段,我花了几倍的冗余就不会出问题。但实际上是不一样的,资源是有限的、能力是有限的,很多时候会出现第二种情况就是集群的容量不能够满足集群流量的突增,这个时候引入新的模块叫集群限流模块,它的核心是会实时计算出来每一个用户、每一个客户,他实时的QPS是多少,这是第一点;第二点,他可以推算出来实时的增量是多少,就是当真正出现这种集群流量不足的时候就可以很轻松地知道到底是谁产生了突增,那就会对产生突增的用户进行现金限流,这是第一步。


第二步为了进行后续的恢复还会触发扣除容量的机制,这个和上面是一样能够去快速的把人括起来,扩容的机制相当于我已经知道哪个客户突增了,突增了多少,那我会加一个阈值,加一个比例。可能是突增了三百,也可能会增加九百的QPS,突增出来了三倍,达到一个比较好的方法。


方案三:单模块扩容


这个第二个方法做得比较极致的话,很多问题也已经解决了。但是不幸的是,架构是复杂的,架构是很多时候是意想不到的,会有一个兜底的方法:

1. 当对某个模块的QPS预估不那么准确的时候可能会出现部分模块确实到了能力的极限,这个时候会触发单模块的过载保护,会丢弃超过自身能力的请求;

2. 它会触发单模块的扩容,这里的扩容和前两个场景有很大的差别,前两个场景都属于集群容量的扩容,第三个场景属于单模块的扩容,用的是ESS本身的扩容的机制来做的,也是非常好用的方法;除了本身模块会有过载保护之外会使用上游模块来去作为熔断的处理,确保不会持续地把某个模块压垮。


那经过以上三个方案之后,流量带来的稳定性问题基本就差不多解决了。



为了再走一步,做了更多的事情,因为前面是对单一集群的容量保护或者容量的管理,会增加跨集群的流量调度,当流量过来之后会把它分发到多个集群让多个集群来去同时释放这个流量,可以达到更好的效果,这些就是高可用做的一些解决方案。


以上是分享的内容,谢谢大家。



相关文章
|
1天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
1天前
|
监控 测试技术 持续交付
构建高效可靠的微服务架构:后端开发的现代实践
【5月更文挑战第14天】 随着数字化转型的浪潮,企业对于灵活、可扩展且高效的后端系统的需求日益增长。本文旨在探讨如何通过微服务架构来实现这些需求,涵盖微服务设计原则、开发流程以及持续集成和部署(CI/CD)的最佳实践。文中还将讨论监控、日志管理与容错机制,以确保系统的可靠性和性能。
|
1天前
|
监控 数据库 开发者
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第11天】在当今软件开发的世界中,微服务架构已经成为构建可扩展、灵活且容错的系统的首选方法。本文深入探讨了设计、部署和维护微服务系统时面临的挑战,并提出了一系列实用的策略和最佳实践。我们将从服务的划分原则出发,讨论如何确保每个微服务的自治性,以及如何通过容器化和编排技术实现服务的高效运行。文章还将涉及监控、日志记录和故障恢复的策略,旨在帮助开发人员构建一个既高效又可靠的微服务环境。
13 1
|
1天前
|
缓存 负载均衡 API
微服务架构下的API网关性能优化实践
【5月更文挑战第10天】在微服务架构中,API网关作为前端和后端服务之间的关键枢纽,其性能直接影响到整个系统的响应速度和稳定性。本文将探讨在高并发场景下,如何通过缓存策略、负载均衡、异步处理等技术手段对API网关进行性能优化,以确保用户体验和服务的可靠性。
|
1天前
|
监控 API 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第8天】在当今快速演进的软件开发领域,微服务架构已经成为实现敏捷开发、持续交付和系统弹性的关键模式。本文将探讨构建一个高效且可靠的微服务系统所必须的策略和最佳实践。我们将从服务的划分与设计原则出发,讨论如何通过容器化、服务发现、API网关以及断路器模式来优化系统的可伸缩性和鲁棒性。此外,我们还将涉及监控、日志管理以及CI/CD流程在确保微服务架构稳定运行中的作用。
|
1天前
|
运维 负载均衡 关系型数据库
MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
MySQL高可用解决方案演进:从主从复制到InnoDB Cluster架构
|
1天前
|
敏捷开发 持续交付 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第8天】 在数字化转型的浪潮中,微服务架构已成为企业追求敏捷开发、持续交付和系统弹性的关键解决方案。本文将深入探讨微服务的核心概念,包括其设计原则、优缺点以及如何在后端开发中实现高效的微服务架构。我们将通过实际案例分析,展示微服务如何帮助企业快速适应市场变化,同时保持系统的可维护性和扩展性。
|
1天前
|
监控 云计算 开发者
探索云计算中的无服务器架构:从概念到实践
无服务器架构作为云计算领域的新兴技术,正在以其高效、灵活的特性吸引着越来越多的开发者和企业。本文将深入探讨无服务器架构的概念及其在云计算中的应用,通过实际案例展示如何利用无服务器架构构建可靠、可扩展的应用系统。
|
1天前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。
|
1天前
|
API 持续交付 开发者
构建高效微服务架构:策略与实践
【5月更文挑战第6天】随着现代软件系统的复杂性增加,微服务架构逐渐成为企业开发的首选模式。本文深入分析了构建高效微服务架构的关键策略,并提供了一套实践指南,帮助开发者在保证系统可伸缩性、灵活性和稳定性的前提下,优化后端服务的性能和可维护性。通过具体案例分析,本文将展示如何利用容器化、服务网格、API网关等技术手段,实现微服务的高可用和敏捷部署。
http://www.vxiaotou.com