贷记卡系统设计

1. 概述

目前我行境内贷记卡核心系统单体使用了复杂的会员模型和冗余的账户结构，无法支持快速地业务创新来改善客户体验和提升管理能力。传统主机价格高昂，无法通过简单扩展的方式实现处理能力的水平扩展。

由此，我们发起了贷记卡重构项目，构建一套完善可推广的分布式技术体系，综合利用云、单元化、分布式数据库的优势，建设满足业务及技术要求的新一代贷记卡系统。

本文将给出新贷记卡系统的总体技术方案。

2. 总体规划

在外围系统基本保持现状的前提下，新一代贷记卡业务系统在银行信息系统架构中的位置与原主线基本保持一致，如下图所示：

系统架构图

2.1 主机下移

与 BSSP 和 GEMS 系统交互，新贷记卡原则上将只与对应的主机系统交互，不再与 HCIF 和 GBKS 主机端交互。 但由于贷记卡建设计划无法与 BSSP 和 GEMS 的下移计划匹配，在贷记卡账户初期还需要继续保持与 BSSP 和 GEMS 的接口。 需要与 GBKS 、BSSP 、XCIF 各相关方讨论确认调用接口。

2.2 功能外迁

1. 原贷记卡系统内的分析 Triad 、外卡清算 V1 、会计 CAC 三个功能模块下移：
   1. Triad: 原贷记卡客户行为分析模块，将由卡中心负责新建系统，贷记卡提供数据跑批出等相关支持。
   2. V1: 原贷记卡国际清算模块，下移至开放系统，由总行外卡侧负责系统 (COPS) 承接。V1 的功能除了清算文件之外，还包括黑名单发卡上报等功能。所有与国际组织交互的部分都由 COPS 负责，贷记卡核心不再保留 NIP 、MIPS 、EP 等的管理功能。
   3. CAC: 原贷记卡会计模块，下移至开放系统，由 GAPS 承接贷记卡模块承接。

2.3 保留系统

贷记卡实时反欺诈系统 Falcon ，部署在卡中心，拟保留，新贷记卡系统联机调用反欺诈系统。

2.4 保留改造

其余总行保留系统主体功能不变，联机、批量的接入点全部切换到新贷记卡业务系统，根据新贷记卡业务系统的接口和文件格式进行改造。共计 43 个系统，分类如下：

1. 联机授权: ESB1 报文类交易系统，CPS 、COPS 、AOF 、GEMS 、MIXS...
2. 联机查询维护：采用 TCP 定长或 XML 报文，HCES 、买单吧、客服等。
3. GSP 查询维护接入：采用 SOAP+MQ 报文，手机银行、网银等。
4. 联机外调：TCP 直连，ECSS 短连接、FALCON 长连接。
5. 联机外发：通过 MQ ，直接或通过 GSP 中转异步外发数据类，卡中心、消息中心、HCES 、ODSS 等。
6. 文件输入：通过 FTP 或 CD 传输数据，CPS 、COPS 、GEMS 、卡中心等。
7. 文件输出：通过 FTP 或 CD 传输数据，数据仓库、历史库、ODSS 、卡中心、HCES 、GEMS 等。

2.5 业务目标

新系统将在业务能力上有较大的提升。

• 账户结构优化：向客户、原系统体系产品维度发展。每个产品在系统里都有自己的清算账户，这样在体现满足客户的透支在多张卡片之间分配比较困难，所以新系统打算做成多个“产品”之间汇总出账单，减少客户多张卡的还款和管理状态不一致的情况。
• 计息粒度细化：原系统只支持按大粒度的余额进行定价，最细只能识别到“存款”“消费”“取现”这些大类别的余额，并且只能根据周期来做汇总。新系统将会对计息粒度做进一步的细化，支持更多的灵活定价方式，支持多维度的余额汇总，可以支持按日、按单笔交易进行计息。
• 入账时效增强：原系统是双信息系统，使得交易入账与授权时效至少相隔一天。新系统将支持准实时入账，将境内单信息交易入账与授权的时间间隔缩短到几分钟，可以大大提高持卡体验。
• 参数功能增强：原系统太多地方写死的，新系统将对参数做重新规划，实现快速高效配置，并支持进程级参数缓存。

2.6 业务模块

新系统将为我行贷记卡提供授权、账务、额度、发卡、用卡、参数等方面提供业务能力支撑。

2.7 容量规划

目前贷记卡核心系统 (包含主机、开放、代码库) 的业务量如下：

• 卡量：7000 万
• 客户量：5000 万
• 账户量：1.1 亿
• 总记录数：180 亿
• 存储量：6T
• 每日授权交易：1500 万，最高 400TPS ，双十一 4000TPS 。
• 每日查询维护交易：1.8 亿，最高 4000TPS 。
• 批量作业 1600 个，每日运行 9 小时。

新系统设计容量支持 2 亿客户，日末交易量等数据按照现有数据预估。金融交易高峰支持 20000TPS 。

2.8 资源预估

3. 架构设计

3.1 设计原则

通过分布式、单元化的技术实现系统高性能、高可用、可扩展。 综合考虑贷记卡核心系统的数据量、交易并发量、响应时间等要求，我们计划采用“单元化分布式微服务架构”的实施方案。

3.2 微服务架构

微服务架构就是把一个大系统按照业务功能分解成多个职责单一的小系统，通过轻量级通信多个小系统互相协作，组成一个大系统。

3.3 单元化架构

单元化是将较大规模的系统按照某种维度进行水平划分，成为若干个小型系统，实现每一个单元内数据可控的一种设计方法。 单元化的需求主要来源于开放系统的分库分表架构。将数据以某种维度进行拆分，分别存储在不同的单元中。应用与数据库配合，将应用层的数据拆分规则和数据库的拆分规则保持一致，确保单元内应用只访问本单元的数据，实现自闭环。最低级的单元化是整个单元都能作为一个可对外提供完整服务的小型独立系统。

单元内各应用的联机批量均共享同业务数据，各个应用之间通过报文进行内部通信，实现单元内业务的完整闭环。

1. 单元化带来的好处

   • 扩展性好，几乎无上限。
   • 分布式系统运行高效，成本有明显的降低。
   • 更容易进行多地部署，可按单元进行数据主从和异地部署配置。
   • 单元内 SQL 语句限制较少。

2. 单元化的额外开销

   • 应用层分布式事务支持。
   • 独立的基础分片管理模块，包括应用、缓存、数据库等组件。
   • 公共数据需单独统一处理，如卡号池、各类卡号管理。
   • 整个单元部署架构较为复杂，总体系统资源开销较多。
   • 跨单元的聚合查询、批量操作等场景性能较差。

3.4 单元的规划

在贷记卡单元化架构下，数据将会严格按客户维度分区，每个分区称为单元。每个单元拥有完整的应用与数据库，可独立提供该单元客户的全部分业务服务。每个单元中的数据并不全，也不重复，一个客户只存在于一个单元中。涉及跨单元的应用，应用间以 RPC 方式互调。 机构和服务商在同一个单元中，减少了一个事务中跨多个单元的情况发生。需要尽可能把有关联的客户落到同一个单元中。

单元化的原理如下图：

单元拆分方案 (基于 OceanBase):

• 数据方面: 规划 100 个分片，每个分片内客户 200 万，分片内记录数量 2 亿，每日金融交易 60 万 (授权+入账)。每日周期账户 16 万，交易峰值为 200TPS 。对应数据库 1~2 万 QPS 。
• 应用方面: 规划 10 个逻辑单元，应用与单元数据分片形成 1 比 10 的关系。每个单元负责承载 2000 万客户，记录数量 20 亿，每日金融交易 600 万 (授权+入账)，每日周期账户 100 万，交易峰值为 2000TPS ，对应数据库 10~20 万 QPS 。
• 部署: 部署 6 套 OceanBase 集群，其中 1 套负责承载公共区域数据，5 套负责承载单元应用数据。

3.5 单元的扩展

可实现应用单元的便捷扩展。在准备好物理机、虚拟机、容器等资源并完成应用部署后，通过网关路由规则配置变更便能新单元生效。 网关自动路由支持从单元内数据量、单元内交易热度两种方法进行客户的单元分配。 新客户单元完成部署后，即可将新客户分配到新的单元。为了更单纯用数据和交易量保持平衡，可以考虑建立一个新单元，并将新客户分配到新的单元。 单元扩展后，原有单元的数据不需迁移，单元只支持扩展，不要回收。

4. 系统分层

为提高系统的可靠性和扩展能力，我们设计将系统分为几个层次。通过层次间的隔离来减少下层设施的变化对上层应用的影响。共分为通用基础平台、通用业务平台、专属业务平台、业务应用。

4.1 通用基础平台 (PaaS)

通用基础平台 gRaaS ，简称 GP ，负责与 PaaS 云平台网关、注册、配置、治理、链路、日志、监控等进行对接，屏蔽不同云平台选型对上层通用业务平台的影响。

通用基础平台不是云平台，而是基于云平台从应用层架构出发对业务应用提供的运行态支撑和运维治理体系。

4.1.1 网关服务

API 网关通过 Servlet 暴露端口，支持 REST 接入接出。支持参数校验、Jwt 认证、渠道认证、访问控制、黑白名单、灰度路由等 API 治理功能。还支持并发、熔断、降级、超时、限流等控制。

网关服务启动后注册到管控端后台，并获取管控端的配置数据加载到内存、初始化功能数据，然后异步写入本地文件中。管理员可以操作管控台前端将网关配置参数下发到网关服务端。服务端将数据刷新到内存，初始化功能数据，然后异步写入本地文件中。

4.1.2 注册中心

采用 Nacos 作为注册中心。支持服务列表查询、查看列表详情。为每个服务提供 "上线" 和 "下线" 的功能。

4.1.3 配置中心

采用 Nacos 作为配置中心进行统一的配置管理，与我行统一的云配置中心对接。

配置中心支持的管理操作包括有：创建配置、配置列表、配置详情、删除配置、配置历史版本、配置历史版本详情以及配置回滚等；同时提供配置模板来快速地创建配置。

利用 Nacos 的 Namespace (命名空间) 实现系统环境隔离。每一个 Namespace 对应一组系统（授权、发卡用卡、账务、额度等），系统下可以对应多个不同应用集群（ cps 授权服务集群、发卡用卡服务集群等），还包含一组公共服务组件。通过应用名绑定具体配置文件来监听配置信息。

应用通过对接域管理服务 (domain)，将服务注册到 domain 中，用户在对应域的配置管理页面配置参数及应用的绑定关系，domain 将绑定的配置下发给对应的应用。应用在启动时从配置中心拉取监听的配置，运行时可以接收配置中心的推送。

4.1.4 治理中心

治理中心整合开源组件 Alibaba Sentinel ，提供对各类资源的保护、监控统计等支持。可根据预设的规则，结合对资源的实时统计信息，对流量进行控制，支持限流熔断。提供规则定义和修改的接口，还提供实时的监控系统使运维人员能够快速了解系统状态。

Sentinel 服务启动可以通过配置 SentinelDashboard 地址，之后会在客户端首次调用的时候进行初始化，开始向控制台发送心跳包。之后该 Sentinel 服务会与 Sentinel Dashboard 做交互，Sentinel 管控端有规则数据发生变化就会将数据 push 给 Sentinel 服务，Sentinel 服务再将规则数据更新到内存中。

1 、流量控制

支持两种统计类型，并发线程数和 QPS ，通过 Sentinel 的 StatisticSlot 实时统计获取。

并发数控制用于保护业务线程池不被下游慢调用耗尽。通过统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，类似于信号量隔离。并发数控制通常在调用端进行配置。

当 QPS 超过某个阈值的时候，则采取措施进行流量控制。可以配置直接拒绝、预热（冷启动后出现交易峰值）、匀速排队（间隔性突发流量）三种限流措施。

可以针对调用方、调用链路、关联流量配置限流策略。

2 、熔断降级

在 1 秒内，最小请求量达到 5 次，且满足熔断策略，将会触发熔断，熔断后睡眠时间 5000 毫秒，期间拒绝所有请求并返回降级报文，睡眠过后，尝试接受一笔请求，如果请求失败，继续熔断 5000 毫秒。如此循环，直到一笔交易成功后，不再熔断。以上参数可在配置中心配置。

支持三种熔断策略：平均响应时间，异常比例，异常数。

3 、超时控制

超时控制，对接入接出和网关路由模块尤为重要。每个请求/连接需要占用线程资源，当发生网络延迟、FullGC 、下游服务慢等情况造成上游服务延迟时，线程池很容易会被打满，造成新的请求被拒绝，但这个时候其实线程都阻塞在 IO 上，系统的资源没有得到充分的利用，因此需要超时控制机制来避免以上情况的发生。

4 、并发控制

设定 API 访问最大并发数，当并发数达到设定值时，限制访问后端服务，防止超出容量范围的请求导致服务崩溃。

4.1.5 链路追踪

基于 SkyWalking 技术，配合 Zipkin 和 Elasticsearch 技术，进行全链路数据采集、分析、存储、追踪、查询。 由 ElasticSearch 接收数据并索引到磁盘。控制台页面通过查询条件或链路 ID ，向 SkyWalking 发起请求，通过 ElasticSearch 提供的查询接口获得数据，处理后给到页面展示。

4.1.6 日志管理

综合 FileBeat 、Kafka 、LogStash 、ElasticSearch 等技术进行数据采集、预处理和存储，可通过系统控制台执行数据的查询展示。

日志格式按照 log4j2 pattern 定义如下：

[%d{yyyy-MM-dd HH:mm:ss:SSS}] [%-5level] [%X{ltts_log_type}]
[${sys:edsp.application}] [${sys:edsp.group}]
[${sys:edsp.instance}] [%X{trace.id}] [%X{SW-traceId}]
[%X{SW-segmentId}] [%t] [%C{1}] %m%n

pattern 用中括号来分隔字段，每个右中括号后跟着一个英文空格，最后的 %m%n 表示日志内容后跟着一个换行符。字段含义从左到右依次为： [机器日期时间] [日志级别] [日志类型] [应用名] [应用实例 id] [链路 id] [链路节点 id] [线程名] [类] 日志内容。

4.1.7 监控预警

监控平台可及时捕获系统运行过程中发生的错误异常等信息，具备实时监控、历史错误率汇总监控、定时自检、事后分析、历史查询、数据统计等功能，对业务系统的所有模块提供基础的监控支持。

其中业务监控，主要通过主控程序中针对报文输入输出情况进行埋点，在监控系统上进行统计和汇总，然后编写监控规则对交易进行监控。 资源监控，可以对虚拟机的硬盘、内存、CPU 、端口、服务情况进行监控。 必要时可与我行现有监控平台对接，以利用现有的监控预警等能力。

利用探针技术，采集链路和 JVM 相关指标，配合 gRPC 、SkyWalking 和 ElasticSearch 组件，进行链路数据采集、分析、存储、查询追踪、实力探测。支持对交易量、响应时间、服务调用等数据进行监控，并可以根据参数以分钟、小时、天等维度进行汇总和展示。

4.2 通用业务平台

通用业务平台，基于通用基础平台，与云平台无关。实现所有应用系统需要的基础功能，如防重幂等、序号管理、分布式事务、服务编排、缓存管理等基础技术机制。

在开发层面，通用业务平台为应用系统提供一套通用开发平台，提供元数据、接口、代码框架、参数同步、缓存、服务调用、分布式事务、路由、编排等方面的开发支持。详见开发平台章节。

4.2.1 防重幂等

通过统一的报文头规范，识别渠道、交易类型、交易码、全局业务流水号等数据。防止外围多次以相同数据请求服务，导致同笔请求数据多次处理的问题。依赖于外围系统，如外围系统无业务流水号，则无法实现防重幂等功能。

防重机制主要用于客户联机交易。针对相同请求数据的请求，除第 1 次请求外，其它请求都响应“重复请求”的异常并返回第 1 次处理的处理状态（成功、失败、正在处理）。

幂等主要用于批量转联机的交易。针对相同请求数据的请求，除第 1 次请求外，其它请求都响应第 1 次处理的结果，如果第 1 次处理未完成则响应“正在处理”的异常。

部分交易需要对报文解析后由业务系统执行检查，如授权交易中根据 8583 报文要素识别重复交易。

4.2.2 序号管理

序号管理模块以 SDK 的形式为应用系统提供调用。支持流水号、库表键值等生成。

序号组件提供统一的序列号获取的功能，并通过缓存序列号提高序列号获取的效率，从而提高交易的执行效率，采用单元号+序号段的方式实现单元间序号的隔离。

序号管理主要涉及到以下三种功能：

• 序号初始化：根据数据库表中配置的序列号名称、缓存来源、步长间隔初始化一个序列化对象，并把步长内的序列号缓存到内存中。
• 序号使用：提供统一的序列号获取的 API ，业务开发只需要根据序列号名称即可获取到所需的序列号。
• 序号回收：应用正常停止时，会把当前 JVM 内存中未使用完的序列号段注册到数据表中，下次应用重启时回收未使用完的序列号重新使用。

当系统异常宕机重启后，已分配的序号可能会丢失，因此该逻辑不适用于卡号分配。

4.2.3 事务管理 (TCC)

支持跨单元、跨服务交易的分布式事务组件。由应用和分布式事务管理模块协调完成分布式事务。

所有的分布式事务处理逻辑都通过可配置的方式实现。分布式事务对业务开发人员的影响仅限于对 TCC 标准接口的支持。事务的提交、回滚等动作交由事务控制组件完成。

在贷记卡系统中已识别出的分布式场景包括优选卡号（ AMN/DSN ）、卡号生成（ AMN/DSN ）、制卡分流（ AMN/DSN ）、副卡客户信息查询（ DSN/DSN ）、账号生成（ AMN/DSN ）、名单类信息同步（ AMN/DSN ）、主副客户查询额度授权等（ DSN/DSN ）。其中账号生成场景可以优化到单元内生成，名单类信息同步可以优化为参数模式。

1 、TCC 事务模型

应用系统需要进行应用服务拆解，为跨单元的交易提供交易的“尝试”、“确认”、“取消”接口。事务流程由分布式事务管理模块负责。

• Try：分支事务执行相应的业务逻辑，对应一次提交（资源的预留）。
• Confirm：确认提交，Try 阶段中各个分支事务执行成功后，则开始执行 Confirm 阶段，释放应用锁。如果执行报错的，也会进行事务回滚。
• Cancel: Try 阶段业务执行出现异常，执行业务取消操作，预留资源释放。如果某事务节点的 Confirm 阶段失败。

2 、事务模型优化

为简化业务开发，我们将 TCC 事务模型进行了优化。 将 Try 、Confirm 步骤合二为一，避免了对正交易代码逻辑的侵入。 保留修改前的数据现场，减轻了业务人员开发 Cancel 交易的复杂度。

3 、事务控制流程

事务控制流程中主要使用到了全局事务提交、分支事务执行、分支事务确认、全局事务回滚、分支事务回滚、这几个操作 API 。

分布式事务框架负责登记所有事务状态，提供 API 以及回调接口给外部调用，控制事务的走向，可以基于事务状态数据还原每一笔交易调用。

当全局事务开启之后，即可开始分支事务的执行，分支事务全部执行成功，执行全局事务提交，全局事务的提交会触发每一个分支事务的二次提交；如果执行分支事务有失败的，则执行全局事务回滚，全局事务回滚会触发每一个分支事务的回滚。

以上接口的调用全部由交易平台发起。

4 、嵌套事务调用机制

分布式事务框架支持嵌套事务调用，外调单元也受主控事务的控制。 整个事务登记过程涉及到两张流水表，一张是单元内事务流水表，一张是分支事务流水表，单元内共库。下图是跨单元调用流水登记过程图：

单元 A 是全局事务的发起者，称之为主控单元。单元 B 和单元 C 需要由业务开发人员提供主控交易外调的原子服务。紫色节点为系统接入时构建全局事务时登记的流水，该流水登记在单元 A 事务流水表，一笔交易涉及到几个单元，表中就会生成几条流水数据；其余的单元各自单元内登记分支事务流水表。橙色的节点表示除了服务外调之外，本地也包含数据库操作，这些操作也是需要被回滚的，因此也需要抽取成一个分支事务。

5 、异常处理机制

• 平台异步处理机制：事务框架在取消阶段出现异常的情况下，将取消失败的交易状态转成失败，同时将后续的取消操作转异步线程去处理，异步的重试次数可配置，如果异步重试还是失败将转人工处理。
• 人工处理机制：事务框架集成在交易服务框架之内，其人工处理接口由交易服务框架进行二次封装，可以通过事务框架管控端或者外部系统 API 调用的方式完成人工处理流程。

6 、服务间同步调用，配合冲正模式

分布式事务框架需要在交易开始即识别出分布式事务。 针对某些在运行过程中才能识别出分布式事务的交易，则采用同步外调模式进行。单元间服务调用需要经过网关路由区。 单元 1 调用单元 2 的服务。如果单元 2 执行失败，则单元 1 执行回滚。如果单元 1 执行失败，则单元 1 向单元 2 发起冲正。 同步调用模式下，分布式事务流程也是由事务管理模块负责的。

4.2.4 服务编排

以服务维度，对复杂交易流程进行配置化的编排。支持服务引用调用、远程服务调用。服务编排与分布式事务组件结合，支持跨服务的事务管理。

服务编排主要用于 DSN 单元内部的联机交易管理，通过 REST 接入。组合服务层用于组件业务逻辑管理，提供交易流程编排、事务管理、报文映射等功能。基础服务层用于编写简单业务逻辑，达到逻辑复用效果。数据和业务基础方法层，提供元数据管理、代码生成、基础业务方法等功能。

服务调用接入表 (tsp_service_in) 可配置的服务参数有：系统编号、子系统编号、外部服务码（接入）、内部服务码、内部服务实现（交易、服务），服务类别（流程类、业务类）、业务服务类型（检查、try 、notify 、cancel 、confirm ），事务模式（只读、原子、分段外调、TCC 分布式事务）、日志级别、超时时间、缓存使用方式（按配置、强制不使用）、通讯日志登记模式（不登记、登记、登记且防重、登记且幂等）。

凡是涉及到分布式事务的，不管是本地还是远程调用，都需要再配置服务调用控制表 (tsp_service_control)，可配置的参数有：系统编号、子系统编号、业务服务调用标识、内部服务码、内部服务实现标识、配置服务实现的标识、路由关键字 (DSN 单元定位)、冲正服务标识、二次提交服务标识、事务模式（不支持分布式事务、支持回滚、支持回滚和二次提交）、业务服务类型、是否登记调用日志、服务执行类型（本地、远程）。

可通过可视化的界面进行配置，执行新增、修改等操作。

4.2.5 缓存管理

为提高数据访问效率，系统引入了缓存支持。包括交易级缓存、全局（进程级）缓存两种缓存机制。

无缓存时，SQL 操作不使用缓存机制，直接查询数据库的最新数据。

使用交易级缓存时，缓存的生命周期与交易一致，每笔交易请求都会开辟一块线程级缓存区域，交易结束后清空并释放。交易开始后只有第一次读取参数表的时候才会查询数据库，其余相同查询操作均访问缓存。insert/update/delete 三类 ODB 操作将同步更新缓存和数据库信息，即在当前交易中进行这三类操作后，缓存和数据库都是变更后的数据。

该缓存级别适用于一笔交易内会频繁访问同一条记录的场景，如卡账号等一个交易中会被多次主键调用的表，以及数据量很大的参数表。

全局（进程级）缓存是指缓存在 JVM 内存的数据。系统中的大部分参数访问就采用这种应用级缓存模式，参数以副本的形式在各个单元内落库，并缓存到业务应用系统中。JVM 启动时自动加载，与 JVM 生命周期保持一致，JVM 退出则缓存自动释放。

全局（进程级）缓存主要适合于参数等不会在交易过程中发生变化且修改频率不高的表。

各库表的缓存模式通过 tsp_table_control 表进行配置。缓存使用封装在数据访问层，对业务系统透明。

• 交易结果缓存: 线程空间 LRU 缓存。
• 全局逻辑缓存: JVM 内存缓存静态参数。

4.3 专属业务平台

专属业务平台，将通用业务平台中适用于贷记卡的提炼成贷记卡专属平台，导入贷记卡元数据、接口、编号规则等业务功能和数据。为贷记卡系统开发提供高效支持。详见开发平台章节。

4.4 业务应用系统

基于专属业务平台部署应用系统，包括新贷记卡系统中的授权、账务、额度、发卡用卡几个主要业务应用系统。

在扩展性方面，可基于“传统核心专属业务平台”开发借记卡、储蓄、对公等应用。

5. 部署架构

5.1 总体架构

新的贷记卡系统架构中包含 6 个主要功能区域，分别是接入接出区 TA 、网关路由区 GR 、公共管理区 CM 、公共服务区 CS 、业务单元区 DSN 、管理单元区 AMN 。各个区域在逻辑部署上实现分离，通过 HTTP 协议进行 REST 或组件直连协议进行通讯，部分存储和数据库实现共享。

架构区域示意图

5.2 接入接出

接入接出区，简称 TA 。负责承接外围系统的交易接入，是所有外围系统调用贷记卡交易的接入点，还负责部分通过长连接外调的交易。针对部分交易，还会根据需要对报文格式进行加工，如添加标准报文头等。

接入接出区面向外围提供多种交易接入协议和报文格式的支持，与后方的贷记卡网关路由区通过 HTTP+JSON 交互。

接入接出区域共分为授权接入、非授权接入、云上系统接入、外调、代授权共 5 组服务，各服务均需实现多节点高可用。

5.2.1 系统架构

接入服务需要通过外部 F5 进行负载。接入服务系统架构如下：

接入接出节点采用虚拟机部署。根据交易量的大小为每个分组配置不同数量的节点，如 EPCC 组 10 个节点、CPS 组 10 个节点、COPS 组 5 个节点、本行 (AOP/ECUP) 组 5 个节点、非金融模块 5 个节点、核心 (GEMS/MIXS) 组 5 个节点、MQ 模块 2 个节点、统一接出模块 2 个节点。

5.2.2 交易流程

接入服务的功能流程如下：

接入接出区包含通讯、解包组包、报文转换、路由分发等功能。

接入接出区依赖于配置中心、日志管理、链路跟踪、业务监控告警、持续集成、资源监控告警。

5.2.3 云上接入

如果有新的云上系统对接贷记卡需求，则可以直接通过 HTTP 方式接入。该接入方式需要外围系统通过 Jump-Cloud 接入到贷记卡容器云框架。

5.2.4 授权接入

由授权交易接入服务处理 8583 类交易接口。

进一步细分为 5 个子服务：

1. CPS 接入服务：通过 CPS 系统对接银联、连通。
2. COPS 接入服务：通过 COPS 系统对接维萨、万事达。
3. EPCC 接入服务：通过 EPCC 系统对接网联。
4. 本行接入服务：通过 AOP 、ECUP 对接本行交易。
5. 核心接入服务：通过核心接入服务对接核心主机 GEMS 和异构 MIXS 。

5.2.5 其他接入

由统一的非授权交易接入服务处理非授权交易请求。

由于原有的贷记卡前置系统和贷记卡开放系统已经去掉，而单元化架构的路由模块需要统一的报文头进行单元识别，因此可以通过新的非授权交易接入模块进行报文规范化处理，如解析报文并添加报文头等。

非授权交易接入细分为 2 个子服务：

1. 非金融接入服务：支持 TCP 定长报文、SOAP 报文，如卡中心直连、ECUP 交易等。
2. MQ 接入服务：支持外围通过 EGSP 访问贷记卡的交易。

5.2.6 交易接出

由统一的联机外调服务处理对外的长连接外调，如 TCP 长连接访问实时反欺诈系统。

通过在虚拟机上部署接出服务来维护外系统的长连接。

对于访问安全系统等短连接外调，由单元内应用通过 SDK 方式直接外调，不通过接入接出区。

5.2.7 对接网关路由区

通过 REST 调用网关路由区 GR 的网关服务，调用 GR 的接口中，需要在报文头中加入卡号、证件、客户号、客户键值等一个路由要素。

5.3 网关路由

网关路由区，简称 GR 。包含网关和路由服务，负责接收各类渠道通过接入接出区 TA 发起的交易请求，并路由转发到交易所属单元。

网关路由区的各类运行参数通过公共管理区 CM 控制端完成。网关路由区中的服务发现、监控告警、日志分析、链路追踪等功能依赖于公共服务区 CS 的支持。

从层次上，分为网关、路由、数据存储 3 个层次。

5.3.1 网关服务

通过高可用的网关服务，承接来自于接入接出区的 HTTP 服务请求。网关服务通过路由服务查询单元映射关系后，将交易转发到对应的单元。网关通过服务注册发现机制调用单元内的服务。

从全局上将网关分为系统内部 APIGW 及 JumpCloudGW 。内部 APIGW 按照业务的模块归属细分为授权、发卡用卡、额度、账务网关。JumpCloudGW 负责转接行内上云渠道交易的接入。APIGW 负责系统内部的交易的单元路由转发。此外 JumpCloudGW 提供全行角度的服务治理，而 APIGW 提供系统内部的服务治理功能。

网关集成了路由模块 SDK ，可以根据请求中传递的路由信息（客户键值、卡号、证件等）查出当前请求的分区信息，然后将交易路由到具体业务单元分区定位的后端服务上。

由于所有联机交易都需要通过网关路由区进行接入和单元识别，因此必须具备良好的性能和可用性，确保无单点故障。需要具备良好的运行性能，保证整个网关路由区域的时间开销小于 5ms 。支持横向扩展，当网关应用出现性能瓶颈时，可快速动态横向扩展。

当后台业务系统因为软件或硬件故障而导致服务不可用，或者应用报错次数在单位时间内到达熔断设定的阈值时，网关可以自动对异常服务进行隔离，直接以业务报错的形式返回请求方。并在后台业务恢复后自动或手动解除熔断。

网关交易流程及与路由模块调用关系如下图所示：

1 、负载均衡

网关统一使用 REST 协议进行接入接出。接入流量的负载均衡，由外置负载均衡设备 F5 实现，容器化部署的场景则依赖于容器云本身的负载均衡实现。接出流量的负载均衡，基于服务注册发现机制及开源 Ribbon 客户端负载均衡器实现。

2 、接入接出流程

网关暴露 REST 端点给外部访问，接收外部请求，进行解包前处理，然后进入网关过滤器链执行前处理过滤器进行 API 治理（限流、参数过滤、灰度路由等），最后通过 REST 方式接出到单元系统。单元系统返回后，由默认后处理过滤器处理，并将响应信息返回给调用方。

如发生异常，则由默认异常处理过滤器进行统一异常处理。

3 、访问控制

当 C1 渠道的非核心服务 A1 失败率较高时，为了防止该服务过多占用资源，可以通过网关管理端进行操作，屏蔽掉该渠道的 A1 服务。从而实现 C1 渠道的 A1 服务请求在网关进行屏蔽。

5.3.2 路由服务

路由模块负责客户与单元映射关系的管理和查询。路由内部分为 3 层架构：应用—缓存—数据库。应用层实现模块的具体功能，缓存层对逻辑应用层提供高性能的数据支持，缓存落库则保证数据安全。

路由模块须具备高可用、可扩展的能力，并高效的利用缓存和数据库实现数据一致性安全保障。

初始单元划分的依据为客户内部键值。需支持客户键值、ECIF 客户号、证件类型和号码、卡号四种单元号查询。根据后续业务梳理，可能还需要加入手机号、卡账客键值、车牌号等对应关系。

1 、路由映射

分布式路由定位服务 DRS （ Distributed Route Service ）。用于定位客户所在单元，为独立部署组件，支持为新增客户分配单元号、路由要素与单元号映射关系查询、容量与分区策略管理。

在新版服务上线的时候，为了少出问题，可以将少量的请求转发到新的服务上，然后其他的请求还是转发到旧的服务上去，等线上的新服务测试通过以后，就可以重新平均分配请求，这种功能就称为灰度发布。通过网关灰度路由结合注册中心的灰度发布功能来实现灰度发布功能。贷记卡的灰度发布与单元化结合，可以按照单元+服务版本综合配置灰度策略。

5.3.3 数据存储

路由模块的数据库，预计需要保存的业务要素与单元对应关系数量不会超过 5 种。按照 2 亿客户量估算，每种对应关系需要支持 2 亿条记录。预计总的数据量会小于 10 亿条。

在开卡开户、续卡、补卡等场景下会对对应关系进行新增或修改，交易量大约每日十几万。查询场景较多，每日会有数亿的查询访问需求。因此需要选择能够支持 10 亿级数据且查询性能高的数据库。

主流分布式数据库如 OceanBase 具有查询效率不会随着数据量的增长而增长的特性，基本符合贷记卡路由模块的需求，可作为备选数据库。

5.3.4 新建客户

开卡开户场景下，要求支持客户的单元分配。分配时以客户为单位，客户下的卡账客、交易、额度、余额等所有数据都分配到同一个单元。新开附卡的数据分配到主卡客户所在单元。

新客户的单元分配规则可以参数化配置，单元内客户量、单元交易热度等维度进行分配。

5.3.5 单元扩展

当新单元软硬件和业务系统完成部署和基本验证后，通过网关路由模块的配置修改，即可将新客户分配到新的单元。为了使单元间数据和交易量保持平衡，可以考虑每次新增一组单元，并将新客户均分到新增的单元。

单元扩展后，原有单元的数据不做迁移。单元只支持扩展，不回收。

5.4 公共管理

公共管理区，简称 CM 。主要面向运维提供分布式架构管理功能，包括网关管控、路由管控、批量管控、参数管控等。根据需要提供运维界面。

5.4.1 管理架构

通过提供统一的管控端来集成公共管理区 CM 内各管控功能。

公共服务区 CS 内的组件资源在管控平台进行管理，Adm-service 为平台管理端后台服务，用于代理系统管理及运维指令的下发。

Domain-service 为域管理服务。域是一组对象的集合，对象包括了系统、应用、实例以及平台管理创建的组件资源。系统、应用、实例只能属于一个域；一个组件资源可以是多个域公用的，也可以由某个域独享。

公共服务区 CS 内的相关组件即域所管理的组件资源，他们的管理操作通过 Adm-service 代理到 Domain-service ，进而下发到对应的组件。

5.4.2 平台系统区域

平台系统级区域，部署服务平台的核心组件，包括管控台前端、管控台后端、网关管控台（ governor ），以及所需要的数据库和负载均衡设施。

5.4.3 平台应用区域

平台应用级区域，支持多个不同业务系统的统一接入，支持基础组件服务和网络区域的隔离（通过域管理服务实现），在单个应用级区域内部部署服务平台的基础组件和所需要的负载均衡设施。包括域管理服务、注册中心（ Nacos ）、配置中心（ nacos ）、治理中心（ sentinel ）、监控中心（ skywalking ）、日志中心（ zookeeper 、kafka 、logstash 、平台日志服务）、ElasticSearch 数据库（日志中心与监控中心共享一套 ES ）。

5.4.4 网关管控

通过独立的控制服务来控制运行服务和执行维护功能。

网关服务 server 启动时会注册到管控端后台 governor ，并获取管控端的配置数据刷新到内存，初始化功能数据，然后异步写入本地文件中。

管理员操作管理台前端将网关配置参数下发到网关服务端，服务端将数据刷新到内存，初始化功能数据，然后异步写入本地文件。

5.4.5 路由管控

为路由提供映射变更、映射查询、容量管理与分区策略管理等功能。

5.5 公共服务

公共服务区，简称 CS 。主要定位为分布式架构提供技术支撑。

公共服务区属于“通用基础平台”，功能包括注册中心、配置中心、消息中心、缓存中心、应用监控、服务治理、链路追踪、日志分析等。

5.6 管理单元

管理单元区，简称 AMN 。面向其他业务模块提供公共的业务服务，主要负责与业务相关但无法按照客户维度划分到单元内的服务，如统一的参数管理、批量控制、商户控制、卡商管理等。

5.6.1 参数管理

• 接收：参数服务接收到卡中心参数平台推送的数据后，对参数进行校验和差异识别后落库到管理单元参数库。
• 下发：参数服务将参数变更推送到各单元落库参数副本（同步请求），并设置参数加载标识。
• 加载：各单元中定时运行的监听线程识别到参数加载标识，加载新版本参数到内存中。完成加载后将结果汇报给单元参数管理服务。
• 版本切换：所有单元内服务完成参数加载后，由参数服务通知各单元内服务的所有应用实例切换至最新的版本。

如果自动参数变更失败，需要人工通过参数服务进行补偿操作。

2 、参数缓存

参数缓存基于通用业务平台的缓存管理机制。按表定义的 Qdb Index 索引作为缓存键值，数据只缓存一份，键值通过引用方式映射。

3 、定时生效

针对有严格生效时间的参数，需继承带有有效期的公共字段表，同时必须保证提前加载到缓存中。

单元内服务进程中缓存同一个参数版本的多条记录，在参数读取时由数据访问层封装根据生效时间进行参数选择。

交易前处理统一设置当前的交易时间到公共运行变量，保证整个交易过程中时间的一致性。

由数据访问层公共回调对参数缓存的有效期进行判断，返回有效期内的参数，做到对应用无感。

5.6.2 批量控制

批量控制器，详见批量架构。

5.6.3 文件管理

支持文件批量过程中的文件操作，包括接收、校验、拆分、分发、合并、外传等功能。

5.6.4 卡号服务

对整个信用卡系统提供生成卡号服务。卡号池要求实现全系统级的卡号分配、预留、回收等功能，因此无法放在业务单元内部。 卡池服务包括统一的卡号生成服务和优选卡号服务。

5.6.5 商户维护

提供信用卡系统商户相关功能，如商户额度管控等。商户额度与客户无关，因此无法放在业务单元内部。

5.6.6 卡商维护

负责处理各卡商之间的制卡量分配。卡商数据与客户无关，因此需要放在公共单元。

5.7 业务单元

业务单元区，简称 DSN 。单元内主要部署业务系统。 单元内的业务系统共有 4 个微应用，授权、账务、额度、发卡用卡。 单元内模块间通过 API 引用方式访问，通过微服务调用方式跨单元访问。TA 区接入交易通过 GR 网关路由再分发到具体 DSN ，DSN 与 AMN 区交互采用 REST 或文件方式。DSN 应用连接 GP 层组件采用直连方式，具体连接方式由组件决定。DSN 跨单元交互采用 REST 方式，统一经过 GR 网关路由。DSN 外调采用 REST 方式，如第三方服务不支持 REST 方式，则通过 TA 区统一接出访问。

5.7.1 授权服务

负责处理国内国际卡组织、网联、本行收单、卡中心等渠道的授权类交易。负责授权流程、授权规则、状态检查、额度检查等功能。需要通过 API 访问额度、发卡用卡、账务等应用的数据。 根据实际需求，可能需要为批量转联机提供专用的授权服务。

5.7.2 账务服务

账务主要负责处理贷记卡系统的入账、计息、争议、周期、账单、延滞催收、呆账核销、清算对账、资产证券化等。 账务模块还支持循环和非循环额度类分期业务的处理，包括分期付款的交易处理、计划管理、扣款管理等。 账务联机，为联机交易提供账务支持。 账务批量，为批量转联机提供账务服务，如周期、双信息入账等功能。

5.7.3 额度服务

负责额度的查询、创建、调整、使用、恢复等。在额度、入账、授权模块之间会涉及到较多的数据互相访问。

5.7.4 发卡用卡服务

客户、账户、卡介质及相关信息的建立和维护。按照交易特征不同，细分为发卡服务和用卡服务。 发卡服务，完成卡账客等信息的建立，交易量较小，但单交易内部逻辑复杂，涉及到较多跨模块数据更新。还会涉及到安全系统、数据准备系统等外调工作。 用卡服务，主要是客户服务及运维管理类交易，包括客户、账户、卡片、交易等信息的维护，各类名单和协议的维护等。 根据业务需求，可能需要为发卡用卡提供批量转联机的专用服务。

5.7.5 参数服务

在管理单元 AMN 独立部署参数服务对参数进行管理。在业务单元 DSN 内，参数服务主要体现为与管理单元区的参数服务交互、数据同步、缓存管理等功能。业务单元内参数服务通过 SDK 的方式整合进数据访问层，对业务系统开发人员透明。 业务系统通过参数 SDK 访问参数数据，参数的缓存、版本、生效时间等信息由 SDK 封装，对业务系统透明。 支持多版本参数，必要时在业务系统执行冲正等反交易时，可以查询正交易运行时的旧版本参数。对于跨单元、跨服务的交易，需要确保同一笔业务交易使用相同的参数版本。 支持事实和定时两种参数生效机制。支持多级缓存，包括交易级缓存、进程（容器）级缓存。缓存支持高可用，且要配套数据预热功能。