3、微服务架构基础：微服务核心概念、服务拆分原则、特征服务在信用评分中的定位
3.1 微服务核心概念
微服务架构是一种将单一应用程序划分为一组小服务的设计方法，每个服务运行在独立的进程中，并通过轻量级通信机制（通常是 HTTP/REST 或 gRPC）相互协作。在信用评分系统中，微服务架构解决了传统单体架构在数据量激增、模型频繁迭代、合规要求多变场景下的扩展性与维护性瓶颈。
| 核心概念 | 定义 | 在信用评分中的体现 |
|---|---|---|
| 服务自治 | 每个服务独立开发、部署、扩展，拥有自己的数据存储 | 特征服务独立管理特征库，不依赖其他服务的数据库结构 |
| 轻量级通信 | 服务间通过 API 网关或消息队列进行异步/同步交互 | 特征服务通过 REST API 提供特征值查询，通过 Kafka 推送特征变更事件 |
| 去中心化治理 | 允许不同服务使用不同的技术栈和数据存储方案 | 实时特征服务用 Redis 缓存，离线特征服务用 HBase，两者技术栈不同但协同工作 |
| 弹性与容错 | 服务故障被隔离，通过熔断、重试、降级机制保证系统整体可用 | 当人行征信接口超时时，特征服务降级返回历史缓存特征，不影响评分主流程 |
| 自动化运维 | CI/CD 流水线、容器化部署、服务网格监控 | 特征服务版本更新通过蓝绿部署，注册中心自动摘除旧版本实例 |
实践要点：信用评分系统对实时性要求极高（通常要求 P99 < 200ms），因此特征服务的通信协议优先选择 gRPC 而非 REST，以减少序列化开销。注册与发现机制必须支持健康检查与快速摘除，避免路由到已宕机的特征服务实例。
3.2 服务拆分原则
服务拆分是微服务架构设计的核心决策。在信用评分领域，拆分不当会导致特征调用链路过长、数据一致性难以保证、重复计算浪费资源。以下是在特征服务场景下必须遵循的拆分原则：
- 单一职责原则：每个特征服务只负责一类特征的计算与存储。例如“收入特征服务”只处理工资流水、税务数据、社保缴纳等收入相关特征，不混入多头借贷特征。
- 数据边界原则：按数据源归属拆分。人行征信数据、百行征信数据、运营商数据、电商消费数据各自独立成服务，避免跨服务频繁 JOIN 查询。
- 变更频率对齐：将高频变更的特征（如实时交易行为特征）与低频变更的特征（如学历、职业类别）拆分到不同服务，降低高频变更对低频特征的部署影响。
- 计算复杂度隔离：将需要大量 CPU/GPU 计算的模型推理特征（如深度学习违约概率）与简单规则特征（如年龄、性别）分离，便于独立扩缩容。
- 合规与安全边界：涉及敏感个人信息的特征（如身份证号、手机号）必须独立成服务，并设置严格的访问控制与审计日志。
拆分案例：某头部消费金融公司将特征服务拆分为 12 个独立微服务，包括：
- 基础身份特征服务：年龄、性别、户籍、学历（低频，缓存命中率 95%+）
- 收入偿债特征服务：月收入、负债率、信用卡使用率（中频，依赖外部数据源）
- 行为时序特征服务：近 30 天登录次数、近 7 天交易金额波动（高频，实时计算）
- 社交网络特征服务：通讯录好友逾期率、紧急联系人风险分（低频，批量计算）
3.3 特征服务在信用评分中的定位
在信用评分系统的整体架构中，特征服务处于数据接入层与评分决策层之间的核心枢纽位置。它不直接生产原始数据，也不直接输出最终评分，而是将异构、多源、非结构化的原始数据转化为标准化、可复用的特征向量，供评分引擎调用。
特征服务在信用评分中的具体定位可以归纳为以下四个关键角色：
| 角色 | 职责描述 | 典型实现 |
|---|---|---|
| 特征计算引擎 | 从原始数据中提取、转换、衍生特征，支持实时与批量两种计算模式 | Flink 实时计算窗口特征 + Spark 批量计算历史统计特征 |
| 特征存储与缓存 | 提供高性能特征读取能力，减少重复计算，降低下游延迟 | Redis 缓存高频特征（TTL 按特征类型设置），HBase 存储全量特征历史 |
| 特征版本管理 | 管理特征定义、计算逻辑、衍生规则的版本变更，支持回滚与 A/B 测试 | Git 管理特征定义 YAML + 注册中心存储特征元数据版本号 |
| 服务注册与发现 | 动态注册特征服务实例，供评分引擎通过服务名而非 IP 地址调用 | Consul / Nacos 注册中心，健康检查间隔 5s，故障摘除时间 15s |
常见误区：不要将特征服务与评分引擎合并部署。合并部署虽然减少了网络开销，但会导致特征计算与模型推理的资源争抢，且特征变更时必须同时发布评分引擎，违背了微服务的独立部署原则。正确的做法是通过注册中心解耦，特征服务独立扩缩容，评分引擎通过服务发现动态路由。
3.4 特征服务注册与发现的架构关系
在微服务架构下，特征服务的注册与发现机制是保证评分引擎能够动态、可靠地调用特征服务的核心基础设施。下图展示了特征服务、注册中心、评分引擎之间的协作关系：
关键设计决策：特征服务的注册信息除了基本的 IP 和端口外，必须包含特征元数据，包括：特征名称列表、特征版本号、计算延迟等级（实时/准实时/离线）、数据源类型。评分引擎根据这些元数据在运行时动态选择最合适的特征服务实例，实现基于特征的智能路由。例如，当评分请求需要“近 30 天交易金额标准差”这一实时特征时，评分引擎优先路由到延迟等级为“实时”的特征服务实例；若该实例不可用，则降级到“准实时”实例返回缓存值。