中介者模式不能直接用于分布式路由，因其仅适用于单JVM内对象解耦，缺乏网络传输、节点发现、状态同步等分布式能力；应分层实现：通信层（gRPC/Kafka）、状态管理层（Nacos/Etcd）、路由策略层（面向对象的RoutingMediator接口及其实现）。
中介者模式本身不解决分布式通信问题，它是一种集中化协调对象间交互的本地设计模式，适用于同一进程内多个对象解耦。将它直接用于“分布式节点间通讯状态路由”存在根本性误解——Java 的中介者模式（如 Mediator 接口 + ConcreteMediator）运行在单 JVM 中，无法跨网络、跨机器传递消息或管理远程节点状态。
为什么中介者模式不能直接做分布式路由
中介者模式的核心是：消除对象间的直接引用，让所有交互流经一个中心协调者。但它不具备：
- 网络传输能力（无序列化、无 socket/HTTP 封装）
- 节点发现与心跳机制（不知晓哪些节点在线）
- 消息持久化、重试、幂等、顺序保障等分布式必需语义
- 跨 JVM 的状态同步（如路由表、节点健康状态）
真正可行的分层实现思路
若目标是“让分布式节点按状态智能路由消息”，应采用分层架构：在分布式通信基础设施之上，用面向对象方式封装路由逻辑。关键分层如下：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 通信层：用 gRPC / Spring Cloud Feign / Apache Kafka / Redis Pub/Sub 等实现节点间可靠消息收发
- 状态管理层：用 Consul / Nacos / Etcd 维护节点注册、健康检查、元数据（如：node-id、role、load、region）
-
路由策略层（面向对象建模）：这才是中介者思想的合理延伸——定义
RoutingMediator接口，由不同策略实现类（LoadAwareRouter、RegionAffinityRouter、StatefulSessionRouter）根据实时状态决策目标节点
一个轻量但可运行的 Java 示例（伪代码级）
假设使用 Nacos 做服务发现，gRPC 做调用，用面向对象方式组织路由逻辑：
立即学习“Java免费学习笔记（深入）”；
// 路由中介者接口 —— 承载“根据状态选节点”的职责
public interface RoutingMediator {
String route(String messageType, Map<String, Object> context);
}
// 具体实现：按当前负载最低的节点路由
public class LoadAwareMediator implements RoutingMediator {
private final NacosDiscoveryClient discovery;
public LoadAwareMediator(NacosDiscoveryClient discovery) {
this.discovery = discovery;
}
@Override
public String route(String messageType, Map<String, Object> context) {
List<Instance> healthyInstances = discovery.getHealthyInstances("msg-processor");
return healthyInstances.stream()
.min(Comparator.comparingDouble(i -> (Double) i.getMetadata().get("cpu-load")))
.map(Instance::getIp)
.orElseThrow(() -> new RuntimeException("No available node"));
}
}
// 使用方（如 API 网关或消息生产者）只依赖 RoutingMediator
public class MessageDispatcher {
private final RoutingMediator router;
private final GrpcChannelPool channelPool;
public void dispatch(String msg, String type) {
String targetNode = router.route(type, Map.of("user-id", "u123"));
ManagedChannel channel = channelPool.get(targetNode);
// 发送 gRPC 请求...
}
}
避免踩坑的关键提醒
- 不要把
ConcreteMediator实例部署到每个节点——它必须是中心化或至少强一致共享的（如部署为独立路由服务，或通过分布式缓存共享状态） - 节点状态（负载、延迟、会话亲和性）必须定期采集并上报，否则路由失去依据；建议用 Micrometer + Prometheus + AlertManager 构建可观测闭环
- 路由结果应支持 fallback（如主区域不可用时切备区）、降级（如全链路失败时走本地默认处理器）
- 如果强调“状态驱动”，可引入状态机库（如 Spring State Machine）管理节点生命周期状态（INIT → ONLINE → OVERLOAD → OFFLINE），再让
RoutingMediator基于状态机查询做决策
