金融微服务落地清单：安全、高可用与常见的翻车点

把大型金融系统拆成可独立部署的服务单元，支付、风控、用户管理各自独立扩缩——这是金融微服务的基本盘。真正的难点不在拆，在拆完之后：资金流动容不得漏洞，监管红线一条不能碰。落地顺序应该是先安全、再高可用、最后才谈迭代速度。

安全三件套

端到端加密、身份认证、访问控制，从用户端覆盖到数据库。API 网关做第一道防线过滤恶意请求，服务间通信交给 Istio 这类服务网格加密，实时监控日志盯异常行为。合规基线按 PCI DSS 和等保要求来；国内金融机构基本绕不开国密改造，SM4 做静态数据加密是常见配置。

认证安全基线如下。

认证选型有个新变化要注意：OAuth 2.1 把 PKCE 变成公共客户端的强制项，隐式流被明确淘汰。新项目直接上授权码加 PKCE，别再参考带 implicit 的老文档。

@RestController
public class AuthController {
    @PostMapping("/login")
    public ResponseEntity<String> authenticate(@RequestBody UserCredentials credentials) {
        // 验证用户凭据并生成JWT令牌
        if (validateCredentials(credentials)) {
            String token = generateJWT(credentials.getUsername());
            return ResponseEntity.ok(token);
        }
        return ResponseEntity.status(401).body("Authentication failed");
    }
}

高可用与弹性

单服务故障不拖垮全局，靠无状态部署加自动扩缩：支付高峰时支付服务独立扩容，交易不断。断路器做依赖隔离，依赖服务挂掉时自动降级，防止级联故障。选型提醒一条：Hystrix 已进入维护模式，新项目用 Resilience4j 或 Sentinel。

分布式事务是拆分后的第一道坎。一笔转账跨多个服务，Saga 用补偿事务回滚已完成步骤，事件驱动架构做最终一致性；强一致场景才考虑 TCC，实现复杂度会翻倍。

两个实测翻车点

mTLS 握手失败，报 certificate verify failed 或 unknown ca，多数情况不是配置错，是中间证书没部署全，服务端只发了叶子证书。把完整证书链配上，再用 openssl s_client -connect host:port 验证握手输出，Verify return code 为 0（ok）才算过。

网关默认 60 秒超时会截断长事务——转账冲正这类慢操作被打断后状态不明。正确做法是改成异步任务加状态查询，别硬调大超时时间。