当你真正把一个简单问题反复打磨，你会发现：系统复杂度从来不是“设计出来的”，而是被现实一步步逼出来的
一个看似普通的比价功能，最终可以演变成一个高并发分布式系统，这中间的差距，就是工程能力的分水岭。
如果仅仅把“价格聚合系统”理解成“调用几个接口然后返回结果”，那么在实际业务中，大概率会在性能、稳定性和成本控制上栽个大跟头。
同样一个需求——查询“iPhone 15”的多平台价格——从最初的一段简单Ja va代码，到最后演变为一个高并发、低延迟、可扩展的分布式系统，本质上是一场架构能力的进化。
这篇文章不讲空话，只做一件事：把一个比价系统从零开始，重构到工程级架构，并讲清楚每一步为什么必须这么做。
最原始版本：单线程串行调用
先看最直观的实现方式：一个类，按顺序调用所有供应商接口。
package com.icoderoad.aggregator.simple;
public class PriceAggregator {
public static void main(String[] args) {
VendorClient amazon = new AmazonClient();
VendorClient flipkart = new FlipkartClient();
VendorClient walmart = new WalmartClient();
List vendors = List.of(amazon, flipkart, walmart);
for (VendorClient vendor : vendors) {
PriceResponse price = vendor.getPrice("iphone-15");
System.out.println(vendor.getName() + " -> " + price.getPrice());
}
}
} 问题本质
这个实现的问题不在代码，而在模型：
请求是串行执行的，总耗时等于所有接口耗时之和。这意味着，任意一个慢接口都会拖垮整体响应。
举个简单例子：
最终耗时：1500ms
在用户侧，这种体验基本等于不可用。
第一步进化：并发请求（CompletableFuture）
要解决性能问题，本质是让IO并行执行。
package com.icoderoad.aggregator.async;
ExecutorService executor = Executors.newFixedThreadPool(10);
CompletableFuture amazon =
CompletableFuture.supplyAsync(() -> amazonClient.getPrice(product), executor);
CompletableFuture flipkart =
CompletableFuture.supplyAsync(() -> flipkartClient.getPrice(product), executor);
CompletableFuture walmart =
CompletableFuture.supplyAsync(() -> walmartClient.getPrice(product), executor);
List prices = CompletableFuture
.allOf(amazon, flipkart, walmart)
.thenApply(v -> List.of(
amazon.join(),
flipkart.join(),
walmart.join()
))
.join(); 性能变化
此时，总耗时由最慢的那个接口决定。
也就是：
600ms，而不是1500ms
这是第一次质变。
第二步进化：容错能力（超时 + 降级）
真实环境中，第三方接口“失败”才是常态。因此，必须引入容错机制。
package com.icoderoad.aggregator.resilience;
CompletableFuture amazon =
CompletableFuture.supplyAsync(() ->
amazonClient.getPrice(product), executor)
.completeOnTimeout(defaultPrice(), 800, TimeUnit.MILLISECONDS)
.exceptionally(ex -> fallbackPrice()); 关键点
超时保护：避免线程被无限占用。异常兜底：保证系统始终有返回值。支持部分成功：不要求所有平台都成功。
这个阶段，系统仍然是单体，但已经具备“生产可用性”。
服务化：基于 Spring Boot 提供 API
当系统需要对外提供能力，就必须变成服务。
package com.icoderoad.aggregator.controller;
@RestController
@RequestMapping("/prices")
public class PriceController {
private final PriceAggregatorService service;
@GetMapping("/{product}")
public List getPrices(@PathVariable String product) {
return service.getPrices(product);
}
} 关键增强点
使用连接池减少资源开销，引入异步HTTP客户端（WebClient），实现服务接口标准化。
引入缓存：把性能再压一层
第三方接口慢且昂贵，缓存是必须的。
package com.icoderoad.aggregator.cache;
@Cacheable(value = "prices", key = "#product")
public List getPrices(String product) {
return fetchFromVendors(product);
} 请求流程
图片
效果
延迟从：
600ms → 20ms
这是第二次质变。
隔离与限流：避免被第三方拖垮
问题开始从“快不快”转向“稳不稳”。必须解决资源争抢问题。
核心策略
线程池隔离（Bulkhead），熔断机制（Resilience4j），限流控制。
示例思路
Amazon -> 线程池 10
Flipkart -> 线程池 10
Walmart -> 线程池 10任何一个平台异常，都不会影响整体系统。
拆分系统：迈向微服务架构
当流量继续增长，单体架构开始成为瓶颈。
架构拆分如下：
图片
为什么必须拆？
因为每个供应商的鉴权方式不同、数据结构不同、限流规则也不同。将它们拆成独立服务，可以彻底解耦。
事件驱动：用 Kafka 重塑数据流
继续优化：不要在用户请求时才去查价格，改为提前采集 + 实时更新。
图片
示例事件
{
"productId": "iphone-15",
"vendor": "amazon",
"price": 799,
"timestamp": "2026-03-09T10:30:00"
}收益
查询不再依赖外部接口，延迟降至5~20ms，系统稳定性大幅提升。
最终形态：高可用分布式架构
系统特征
水平扩展能力强，延迟极低，完全解耦供应商，数据实时更新，具备高容错能力。
真正的难点在哪里？
一个成熟的比价系统，核心挑战并不在代码，而在这些问题：
1. 扇出问题（Fan-out）
一次请求要打几十甚至上百个接口。
2. 尾延迟问题（Tail Latency）
最慢的那个接口决定整体响应。
3. 不稳定的第三方
接口失败是常态，而不是异常。
4. 数据时效性
价格是动态变化的。
5. 成本控制
调用次数越多，成本越高。
架构演进的本质
一个优秀的系统设计，往往不是一步到位，而是这样一步步演进：
串行调用 → 并发调用 → 容错机制 → 缓存优化 → 服务拆分 → 事件驱动这条路径，体现的不是技术选型，而是工程思维。
结语
当你真正把一个简单问题反复打磨，你会发现：系统复杂度从来不是“设计出来的”，而是被现实一步步逼出来的。
一个看似普通的比价功能，最终可以演变成一个高并发分布式系统，这中间的差距，就是工程能力的分水岭。
写代码不难，把系统做“稳、快、可扩展”，才是真正的门槛。
