Practise

第一章 全面的风险业务流程分析 为了深入理解海外风险中台的技术架构，首先必须对其服务的核心业务领域建立清晰的认知。本章将从业务视角出发，解构平台所支撑的完整风险管理生命周期，并以三个典型的业务场景——同步决策的“展期”流程、异步决策的“授信”（“戳额”）流程以及人机结合的“人工审核”流程——作为案例，详细剖析业务逻辑与系统执行之间的精密互动。 核心业务概念与范畴 在金融科技领域，风险是指在未来时间范围内，可能发生某种损失的不确定性。对于公司的海外借贷业务而言，风险特指借款人到期无力或无意偿还债务，从而造成债权人本金与收益蒙受部分或全部损失的可能性。风险控制（风控）的目标并非消除风险，而是通过一系列技术和策略手段，将潜在的风险转化为实际损失的可能性降至最低。 该海外风险中台正是为实现这一目标而构建的核心系统，其服务范围覆盖了菲律宾、巴基斯坦、墨西哥、印尼等多个国家站点，支撑着包括现金贷（Cashloan）、电商消费分期（Lazada FC, TikTok, PPL）、针对海外务工人员的专项贷款（OFW-CL）在内的多种业务线。平台处理的业务事件贯穿用户生命周期的各个关键节点，包括但不限于用户注册、授信申请、发标、提现、还款行为分析以及贷款展期等。 案例研究一：同步决策 — 贷款“展期”流程 同步决策流程适用于那些要求系统在短时间内给出明确答复、用户正在实时等待结果的业务场景。贷款展期便是一个绝佳的例子，它代表了一种低延迟、高确定性的交互模式。 根据系统时序图的分析，一个典型的展期风控流程调用链路如下： 请求发起：上游业务系统（client）因用户申请展期，向风险中台的展期服务（PhiLoanExtension）发起一个同步API调用。 流程实例化：PhiLoanExtension服务接收到请求后，立即组装并实例化一个名为RiskFlow的核心流程对象。这个对象将作为本次展期风控任务的上下文，贯穿整个执行过程。 数据扩充（变量计算）：为了做出决策，系统需要获取与该用户和该笔贷款相关的风险特征。PhiLoanExtension服务会调用内部的“字段变量中心”服务（Irs）的/calVars接口，请求计算展期场景所需的特定字段变量值。Irs服务完成计算后，将结果同步返回。 规则引擎预处理：获得所有必需的变量后，PhiLoanExtension服务根据预设的模板，将这些变量和值组装成规则引擎（drools）能够理解的数据格式。 决策执行与审计：在调用规则引擎之前，系统会将格式化后的请求数据写入日志表risk_flow_log，以备审计和问题追溯。随后，PhiLoanExtension向drools服务发起决策请求。 结果处理与返回：drools引擎执行相应的规则集，并返回决策结果（如“批准展期”、“拒绝展期”）。PhiLoanExtension服务在接收到响应后，再次将其写入risk_flow_log，完成审计闭环。最后，将最终决策结果通过API响应同步返回给最初的调用方client。 案例研究二：异步决策 — “授信”（“戳额”）流程 与展期不同，新用户的授信审批是一个计算密集型且更为复杂的过程。它可能需要调用多个第三方数据源、运行多个复杂的机器学习模型，并可能涉及人工审核环节。这类操作耗时较长，无法在一次同步API调用中完成。因此，系统采用异步处理模式，以优化用户体验和系统吞吐量。 一个典型的异步授信流程如下： 请求接收：用户通过前端应用提交授信申请。上游业务系统（client）将请求发送至风险中台的异步流程入口服务（phi-quechao）。 任务入队：phi-quechao服务在接收到请求后，进行初步的校验和处理，然后将该授信任务封装成一个消息，投递到消息队列（如RabbitMQ）中。投递成功后，它会立即向上游返回一个“处理中”的响应，此时用户界面可以显示“审核中，请耐心等待”，从而将前端交互与后端复杂的处理流程解耦。 任务调度与执行：后台的异步任务批处理服务（phi-job）作为消息队列的消费者，会拉取授信任务。phi-job将任务分发给异步风控业务的调度中心（phi-risk）。 核心风控流程编排：phi-risk服务是整个异步流程的大脑，它依据预定义的Pipeline（管道），按顺序调度执行一系列子任务，这通常包括： 调用Irs服务计算上百个甚至上千个风险变量。 调用模型编排服务（phi-modelschedual），执行多个评分模型。 调用drools引擎，根据变量和模型分执行复杂的策略规则。 决策生成与通知：所有计算和规则执行完毕后，决策服务（phi-riskdecision）汇总结果，生成最终的授信决策（如授信额度、费率、评级或拒绝）。这个结果会被持久化到数据库，并通过另一个消息队列主题，将“决策完成”的事件通知给下游系统，例如更新用户状态、发送通知等。 案例研究三：人机结合 — “人工审核”流程 对于机器决策无法明确判断的“灰色”用户，系统会将其转入人工审核流程，结合人类专家的经验进行最终裁定。这是一个典型的“人机结合”场景，对系统的任务调度、状态管理和外部通信提出了更高的要求。 以巴基斯坦站的人审流程为例，其技术实现如下： 触发与任务生成：当自动化风控流程（如授信）的规则引擎决策结果为“转人工”（manualFlag: 1）时，risk-decision服务会将一个包含用户ID、业务ID和流程ID的人审任务写入任务表（tb_risk_flow_task）中。 后台任务调度：系统采用xxlJob作为分布式任务调度框架。一个名为RiskFlowTaskNonExecutionHandler的任务执行器会定时扫描任务表，捞取待处理的人审任务。 任务执行与数据准备：任务执行器获取任务后，会调用Decision服务，准备该用户用于人工审核所需的各类数据（如基础资料、风险标签等）。 结果持久化与通知：审核员在人审系统（Capital Pata）中完成审核并提交结果。该结果会被Decision服务接收并持久化到人审记录表（tb_risk_user_record）中。该表根据user_id进行了分表处理（如_00到_05），以分散写入压力。 下游通知：决策完成后，Decision服务会将最终的人审结果（如manualTags）通过消息队列（MQ）广播出去。上游业务系统或其他相关方订阅相应的主题（如prod-drools-manual-result），即可获取审核结果并进行后续处理。 失败重试：为了保证流程的健壮性，系统还配置了RiskFlowTaskFailRetryHandler，用于处理执行失败的人审任务，进行自动重试。 业务模式背后的架构考量 系统之所以同时支持同步、异步和人机结合三种处理模式，是基于对不同业务场景下延迟、吞吐量和计算复杂度三者之间权衡的结果。 展期这类操作，业务逻辑相对简单，依赖的数据大部分已存在于系统内部，决策路径短。用户正在界面上等待操作结果，因此低延迟是首要目标。采用同步模型可以提供最直接、最快速的用户反馈。 相比之下，新用户授信是典型的重决策场景。它需要从外部拉取征信数据，处理用户设备信息（SDK数据），运行复杂的反欺诈和信用评分模型。整个过程可能耗时数秒甚至数分钟。如果采用同步模型，不仅会导致用户长时间等待，造成糟糕的体验，还会长时间占用API网关和前端服务的连接资源，极大地限制系统的并发处理能力和整体吞吐量。异步架构通过消息队列作为缓冲，将前端请求的接收与后端耗时的处理彻底分离。这种设计使得系统能够平稳地处理流量洪峰，并通过水平扩展消费者（phi-job）来提高整体处理能力，保证了系统的伸缩性和鲁棒性。 人工审核流程则体现了系统处理复杂、非确定性问题的能力。通过引入任务调度系统（xxlJob）和人工干预节点，风控决策不再是非黑即白的二元判断，而是形成了一个“自动化初筛 -> 机器决策 -> 人工复核”的完整闭环，在效率和准确性之间取得了最佳平衡。 这种多模架构的设计，体现了平台在满足多样化业务需求与保证系统高性能、高可用性之间的精妙平衡，是其能够支撑多国家、多业务线快速发展的关键架构决策之一。 第二章 海外风险平台的统一架构 尽管海外风险中台服务于菲律宾、巴基斯坦等多个国家，且经历了从Python到Go语言的技术栈演进，但其核心架构思想和功能模块划分具有高度的一致性。本章将通过对不同站点的架构图进行综合分析，提炼出一个统一的、具有代表性的平台架构蓝图，并明确各个核心服务模块的职责定位。 统一架构蓝图 通过综合分析菲律宾和巴基斯坦的风控系统架构图，可以描绘出一个通用的分层架构模型。该模型自上而下分为接入层、编排层、执行层和基础支撑层。 接入层 (Entry Layer)：作为风险系统的统一入口，负责接收和校验来自上游业务系统（如merchant、Rating服务）的各类风控请求。它将外部请求转化为内部标准化的风控任务，并根据请求类型（同步/异步）将其路由到相应的处理流程。 编排与调度层 (Orchestration/Scheduling Layer)：这是风险决策流程的核心控制器。它负责解析风控任务，并根据预设的业务流程（Pipeline）或工作流配置，有序地调度执行层中的各个原子能力（如变量计算、模型调用、规则执行）。该层确保了复杂决策逻辑能够被准确、高效地执行。 执行层 (Execution Layer)：由一系列功能高度内聚的专业化服务组成，提供风控决策所需的原子计算能力。主要包括： 变量计算服务：负责根据原始数据计算生成衍生特征（即风险变量）。 模型执行服务：负责调用和执行部署在模型平台上的各类机器学习或评分卡模型。 规则引擎服务：负责执行预定义的业务规则集（如反欺诈规则、授信策略）。 决策与持久化层 (Decision & Persistency Layer)：该层负责汇总来自执行层的各种结果（变量值、模型分、规则命中情况），并做出最终的业务决策。同时，它还将整个决策过程的输入、中间结果和最终输出完整地记录下来，用于后续的审计、分析和模型迭代。 基础支撑层 (Infrastructure Layer)：为整个风险中台提供稳定运行所需的通用技术组件。这包括： 数据库：采用关系型数据库（如MySQL, PolarDB）存储结构化业务数据，并使用NoSQL数据库（如MongoDB）存储三方数据、SDK埋点日志等半结构化或非结构化数据。 消息中间件：使用RabbitMQ进行服务间的异步通信和任务解耦，同时引入Kafka用于大规模数据的实时流式处理。 配置中心：利用Apollo实现所有微服务配置的集中化、动态化管理，提高运维效率和系统灵活性。 数据服务：统一的数据中台（data-hub）提供对外的标准数据查询接口，屏蔽底层数据源的复杂性。 核心微服务及其功能职责 下表详细梳理了风险中台在技术栈演进过程中，核心功能模块与具体微服务之间的映射关系。它清晰地展示了从Python实现的旧版服务到Go语言重构的新版服务，其 underlying 的功能职责是如何传承和演进的。...