3、SDK网络架构设计：同步与异步模型归纳总结

做SDK网络层，最绕不开的就是同步还是异步。说白了，就是你的请求发出去后，调用线程是原地等着，还是扔出去就忙别的。我在第一期SDK重构时，就因为选错了模型，线上出现一堆线程饥饿，教训挺深的。这章咱们把两种模型掰开揉碎，讲透。

同步模型（阻塞式）

同步调用，就是发起网络请求的线程一直等，直到响应回来或超时。伪代码长这样：

Response resp = httpClient.execute(request);
// 线程在此阻塞，resp不为空才能继续
process(resp);

优点很明显——代码直来直去，调试方便。你想想看，if-else 一路写下来，心智负担最低。我曾经在内部工具SDK里用过同步，开发效率确实高。

但坏处也致命：一个线程只能处理一个请求。如果后端慢（比如3秒），这个线程就傻等3秒。并发一高，线程池瞬间打满，新请求要么排队要么拒绝。嗯，这里要注意——同步模型适合低频、低延迟的场景，比如管理后台的配置拉取。

异步模型（非阻塞 + 回调/事件）

异步调用，发起请求后立即返回，线程可以干别的事。响应回来时通过回调、Future、或协程通知你。以Java的CompletableFuture为例：

CompletableFuture.supplyAsync(() -> httpClient.execute(request))
    .thenAccept(resp -> process(resp));
// 调用线程不阻塞，马上继续往下走

我个人习惯把异步模型分成两类：

• 回调驱动：OnSuccess / OnFailure 回调函数。
• Promise / Future 模式：链式调用或 await 语法糖。

异步的核心价值是线程利用率高。一个线程可以管几百个连接，靠IO多路复用（epoll、kqueue）等待事件。我做过一个即时通讯SDK，用异步+长连接，单线程扛了3万心跳包，CPU才跑到12%。

核心对比：同步 vs 异步

下面这个表是我每次设计架构时都要拿出来对照的，你也留着用：

如何选择——我的经验决策树

我自己一般按这三步来：

1. 看请求频率和并发量：日均几十万次、并发几百以内 → 同步足够。日均千万、并发上万 → 必须异步。
2. 看调用方环境：如果是主线程（比如Android UI线程），不能同步——会ANR。如果是后台线程池，可以接受同步，但要控制线程数。
3. 看错误处理复杂度：同步用try-catch搞定；异步需要设计retry、fallback、超时复活逻辑，复杂度高一个量级。

下面这张图把两种模型的处理流程画出来了，你可以直观感受差异：