越南头部电子钱包钱包核心与周边系统背后的架构决策——以及我们会做哪些不同的选择。
「微服务」常被理解为把一切都拆开。而在实践中，价值不在于服务的数量，而在于划出正确的边界——围绕业务能力，而非围绕组织架构图。
在为一个国家级电子钱包构建钱包核心与周边系统时，我们在对一致性、安全与可扩展性有严苛要求的条件下处理了数百万笔交易。以下是几条在生产环境中经受住考验的经验。
1. 服务边界要跟随业务
一个服务应当拥有一项完整的业务能力及其数据。如果每次更新时两个服务都必须一起改动，那就说明边界划错了——它们本应是一个。
2. 对无需同步的部分采用事件驱动
- 资金流转需要强一致性——同步处理，并保证幂等。
- 通知、对账、分析——通过事件推送、异步处理，以免阻塞主流程。
- 每个事件都是已发生的事实，而非一条命令——可以在不触碰生产者的情况下新增消费者。
3. 以清晰契约为前提的 API 优先
在编码前先定义 API 契约，能让各团队并行工作，并减少收尾时痛苦的集成。每次契约变更都进行版本管理，且绝不破坏既有消费者。
微服务不会免费带来速度——它用代码的复杂度换取运维的复杂度。只有当规模确实需要时，才去支付这笔成本。
我们会做哪些不同的选择
从更少的服务起步。一个模块化良好的单体，随着扩展压力出现再逐步拆分，几乎总比过早拆分、日后又合回来更划算。可观测性基础设施应当在第二个服务之前就已存在，而不是第十个之后。