Wise如何用850人管理千亿资金：一个反直觉的工程故事

「2024年，我们的系统自动拦截了数百次可能引发事故的发布。」Wise工程师在博客中写道。没人盯着，系统只把5%流量切给新版本，观察30分钟，发现异常就回滚。三年前，他们还在用内部工具「推完代码听天由命」。

这家每季度处理360亿英镑跨境转账的公司，65%的汇款能实时到账。你以为是中央集权的工程体制？恰恰相反——850多名工程师分属自治小队，各自做技术决策。这种架构能运转，全靠一套精密的「内部平台」。

从1000个微服务到一套「底盘」

Wise的后台有超过1000个微服务、700多个Java代码仓库、40个Web应用，iOS和Android原生应用各自包含数百个模块。15.6百万活跃用户无感使用的背后，是一套共享工具、框架和自动化系统，让「正确的工程选择」成为最容易的选择。

当几十个独立团队维护1000多个服务时，最危险的复杂度不是规模，而是不一致。如果每个团队各自接入安全认证、数据库连接、Kafka消费者和日志系统，你会得到1000个略有不同的系统——难以调试、难以升级、难以保障安全。

Wise的解法叫「微服务底盘框架」（microservice chassis framework）。这是一个预设好规范的底层基础，每个新后端服务从这里起步。底盘统一管理安全、可观测性、数据库连接、消息消费和日志。团队不用重复造轮子，也不能随意造轮子。

底盘用Java 21和Spring Boot 3构建，运行在AWS EKS（弹性Kubernetes服务）上。它内置了Wise定制的库，覆盖可观测性、功能开关、数据库连接、Kafka消费者、日志、安全、后台任务等模块。团队只需在配置里填几行，就能拿到生产就绪的服务骨架。

这套设计有个隐性代价：自由度降低。但Wise认为，在「团队能随意选择技术栈」和「全公司能统一维护」之间，后者对金融基础设施更重要。底盘不是建议，是默认。想偏离？需要强有力的理由。

部署流水线：从「推完祈祷」到自动防御

2021年的Wise用一套内部工具管理部署，流程粗暴：打包、推送、完工。没有渐进发布，没有自动回滚，没有指标监控。一次发布搞崩服务，全靠人工救火。

2024年的系统完全不同。每次发布走「金丝雀部署」：先切5%流量，跑30分钟，同时监控技术指标（错误率、延迟、资源占用）和业务指标（交易成功率、客户投诉）。任何异常触发自动回滚，全程无人干预。

这一年，系统自动拦截了数百次问题发布。不是工程师变谨慎了，是基础设施让「谨慎」成为默认行为。

这套流水线的核心设计是「可观测性优先」。底盘框架自动注入监控埋点，每个服务的黄金指标（请求量、错误率、延迟、饱和度）无需配置即可采集。团队发布前能看到基线，发布中能看实时对比，发布后能做影响分析。

另一个关键决策是「部署即代码」。所有环境配置、发布策略、回滚规则都存进Git，走代码评审。这意味着发布历史的完整可追溯，也意味着「谁改了什么」永远不会成谜。

数据层：实时转账的隐藏挑战

65%的转账实时到账，这个数字背后是一整套数据架构的取舍。Wise的核心数据库是PostgreSQL，但用法和普通应用完全不同。

首先是分片策略。客户数据按地理区域分片，既满足数据驻留合规要求，也将写入负载分散到多个集群。每笔转账涉及至少两个分片（付款方和收款方），协调通过Saga模式实现：本地事务+补偿操作，而非分布式两阶段提交。

其次是读写分离。报表和分析查询走只读副本，绝不碰主库。Wise内部有个硬性规则：任何面向客户的操作，响应时间P99必须低于200毫秒。分析查询如果慢，可以等；转账如果慢，客户会走。

Kafka是另一个关键组件，但用法经过严格约束。底盘框架提供的Kafka消费者库，内置了幂等性保证、死信队列、自动重试策略。团队不能随意调整消费偏移量，不能随意跳过消息。这些限制在初期引发过抱怨，但在一次Kafka集群故障后，没人再质疑——所有消费者按预期行为恢复，没有数据丢失，没有重复处理。

移动端：数百模块的解耦战争

Wise的iOS和Android应用各自包含数百个模块。这不是炫技，是组织结构的映射：每个业务小队维护自己的功能模块，独立发布。

关键设计是「特性模块化」+「接口隔离」。公共能力（网络、存储、安全、UI组件）沉淀为平台层，业务功能按域拆分。一个团队修改转账流程，不需要编译整个应用，只需要自己的模块。发布节奏从「每月火车」变成「按需发车」。

模块间的依赖通过显式接口管理，禁止直接访问内部实现。这在代码层面强制执行：编译器会拒绝违规调用。初期开发速度确实变慢了——写个功能要先定义接口，要协调依赖方。但六个月后的数据说话：特性交付周期从3周降到4天，生产崩溃率下降60%。

移动端也复用了底盘的核心理念。网络层自动注入请求追踪ID，崩溃上报带完整上下文，功能开关支持远程控制。这些不是可选插件，是模块接入的强制门槛。

组织与技术的咬合

Wise的工程组织设计，和它的技术架构是镜像关系。850人分成约80个「小队」（squad），每个小队8-12人，端到端负责一个业务域。小队自主决定技术方案，但必须在底盘框架内行事。

这种「有约束的自治」是刻意设计。完全自治会导致技术碎片，完全集权会扼杀创新。底盘框架划定了「必须统一」的边界（可观测性、安全、部署模式），边界之内小队自由发挥。

有个细节体现这种平衡：底盘的演进由专门平台团队维护，但新功能需求来自小队投票。每年两次，各小队提交痛点，平台团队排序实现。2023年高票通过的需求是「本地开发环境一键启动」——此前新成员配环境要两天，现在15分钟。

另一个机制是「架构决策记录」（ADR）。任何偏离底盘默认的选择，必须写一份ADR，说明问题、备选方案、决策理由。这些记录存进Git，全公司可见。不是为了审批，是为了知识沉淀。三年后，当有人问「为什么这个服务用Go而不是Java」，能直接找到当时的上下文。

2024年的关键迭代

这一年Wise工程团队的重点是「AI辅助」和「成本优化」两条线，但做法很克制。

AI方面，内部开发了代码审查助手，基于公司代码库微调的开源模型。它不自动合并，只标记潜在问题：未处理的异常、缺失的测试、性能反模式。工程师可以选择忽略，但数据显示，被标记的代码生产事故率高3倍。慢慢地，「无视AI建议」需要额外说明理由。

成本方面，FinOps团队和小队合作，把AWS账单拆解到服务级别。底盘框架新增了资源配额提示：当服务的CPU利用率连续7天低于20%，部署时会收到警告。不是强制缩容，是信息透明。2024年下半年，闲置资源下降了34%，而性能事故零增长。

最激进的实验在数据库层。部分分析查询从PostgreSQL迁移到ClickHouse，底盘框架为此新增了「双写」模式：交易数据仍写PostgreSQL，异步同步到ClickHouse。小队可以逐步迁移查询，随时回退。没有「大爆炸」式重构，只有渐进验证。

一个反直觉的结论

Wise的工程故事，和硅谷流行的「去中心化」「团队完全自治」叙事不完全一致。它证明的是另一件事：大规模分布式系统的可靠，来自「有纪律的一致性」，而非「放任的多样性」。底盘框架、强制规范、默认安全，这些听起来不性感的词，支撑了360亿英镑的季度流转。

对于正在建设内部平台的团队，Wise的路径有个可复制的内核：先定义「绝对不能妥协」的边界（安全、可观测性、部署安全），用框架强制执行；再在边界内最大化团队自主权；最后用数据和反馈循环，让「正确的事」成为「容易的事」。不是每个公司都需要1000个微服务，但每个增长中的工程组织，迟早会面临「一致性vs灵活性」的权衡。Wise的选择是提前回答这个问题，用基础设施投资换取长期速度。

如果你也在设计内部平台，不妨从这个问题开始：你的「底盘」边界划在哪里？