一、背景
在最近的系统设计中，遇到了一个典型的架构设计问题：新上线的业务模块需要对接多家银行的API，统一接入并进行资金处理。此模块有以下几个特征：
- 并发量不大 每天跟银行交互的业务不多，并无性能问题。
- 稳定性、可靠性要求高 该业务模块承载着客户的真实资金流转，每一次请求都涉及资金的操作，模块一旦不可用，将会对客户的业务造成极大影响。
- 数据交互方式 与银行通信都使用各家银行提供的动态库。
于是问题就来了：
👉 在模块架构设计时，我们应该采用多进程模型，还是多线程模型？
二、多进程 vs 多线程，架构选型的优缺点
| 维度 | 多进程 | 多线程 |
|---|---|---|
| 隔离性 | 强：每个进程独立，单个进程崩溃不会拖垮整体 | 弱：一个线程出错，整个进程都可能崩溃 |
| 可靠性 | 高：通过守护进程/重启机制，可保证核心模块存活 | 较低：共享内存，bug 扩散快，容易整体宕机 |
| 通信性能 | 较低：需通过 IPC（管道、socket、共享内存等），开销大 | 高：共享内存，无锁数据结构，直接传递指针，开销小 |
| 资源占用 | 高：每个进程有独立内存空间，开销大 | 低：线程轻量级，创建/切换成本小 |
| 并发设计复杂度 | 低：进程间共享少，逻辑清晰 | 高：锁、竞争、无锁数据结构设计、内存可见性问题复杂 |
| 长期运行风险 | 分散：单个进程崩溃可隔离，但需监控和自动拉起 | 集中：一个线程问题可能拖垮整个进程 |
| 适用场景 | 高可靠性、关键业务、模块不可挂掉（如金融支付、银行对接） | 高性能、需要频繁数据交互的场景（如计算密集/高并发服务） |
三、银行 API 对接模块，为什么更推荐多进程？
在前面章节我们已经分析过，多进程与多线程各自有优缺点。那么结合「银行 API 对接」这种业务场景，应该如何选型呢？
1. 业务特点回顾
- 并发量不大 对接银行 API，本质是 I/O 密集型，调用频率远低于高并发互联网场景。
- 业务极其重要 每次调用都涉及资金流转，对客户都极为重要。
- 稳定性要求极高 模块一旦挂掉，将直接影响客户交易，后果严重。
- 第三方接口不可控 银行的 API 可能超时、卡死、返回异常，甚至触发底层库的 bug。
- 各家银行业务独立 不同银行之间的接口没有强依赖关系，互不影响。
这几个特点决定了：稳定性和隔离性 > 通信性能。
2. 多线程方案的风险
如果采用多线程：
- 任意一个线程因为调用第三方库崩溃（如银行 API SDK 内部 bug），会拖垮整个进程。
- 即使只是资源泄漏或死锁，也可能随着时间积累，导致整个模块不可用。
- 为了避免风险，需要非常复杂的异常处理逻辑，设计和维护成本都很高。
换句话说，单个线程故障会迅速放大成系统性故障。
3. 多进程方案的优势
如果采用多进程：
- 天然隔离：每个银行 API 对接可以放在独立的子进程中，一个进程崩溃不会拖垮整个模块。
- 易于恢复：通过守护进程或监控系统，异常进程可以被自动拉起，模块整体仍保持可用。
- 容错性强：即使某家银行接口持续出问题，也不会影响其他银行接口的调用。
- 长期稳定：多进程避免了复杂的异常处理机制，设计和排错成本更低。
综上所述，结合此模块的需求特点，多进程方案是最适合的设计方案。
四、总结
在架构设计中，多进程 与 多线程 并不是“性能孰优孰劣”的简单对比，而是要结合业务特点来做权衡。
- 如果是高并发、需要频繁数据交互的场景，多线程的优势明显，可以极大提升性能和资源利用率；
- 如果是高可靠、任务彼此独立、模块绝不能挂掉的场景，多进程的隔离性和容错能力更符合诉求。
银行 API 对接的本质挑战在于：第三方库的质量不可控。无论是超时、卡死，还是 SDK 内部 bug，都可能直接拖垮调用方。
在这种高风险场景下，
👉 多线程意味着“一处出错，全盘皆输”；
👉 多进程则能将故障隔离，保证整体可用性。
因此，对于承载资金流转的关键模块，答案很明确：性能可以妥协，稳定性不容妥协 —— 选多进程，更安心。
📬 欢迎关注VX公众号“Hankin-Liu的技术研究室”，持续分享信创、软件性能测试、调优、编程技巧、软件调试技巧相关内容，输出有价值、有沉淀的技术干货。
