Apollo Federation是否为松耦合架构？子图故障致系统崩溃疑问

Apollo Federation确实属于松耦合架构，你遇到的网关失效、系统整体崩溃的问题，本质是容错配置缺失导致的，并非架构本身的耦合特性问题。

为什么说它是松耦合？ #

• 子图完全独立：每个子图可以独立开发、部署、迭代，甚至使用不同的技术栈（不是必须都用Node.js），子图之间没有直接的代码依赖，仅通过Schema定义的契约进行交互。
• 职责边界清晰：每个子图只负责自己领域内的业务逻辑和数据，不需要关心其他子图的实现细节，符合微服务松耦合的核心要求。

网关失效的根源与解决方法 #

你遇到的网关因单个子图不可用而崩溃，是默认配置下的行为，但并非不可避免：

• 启动阶段容错：可以配置网关（比如Apollo Router）的skip_subgraphs参数，允许网关在部分子图不可用的情况下正常启动，只加载可用子图的Schema。
• 运行时故障隔离：开启网关的熔断、超时、重试机制，当某个子图出现故障时，网关会自动隔离该子图的请求，不会影响其他健康子图的正常服务。
• 子图健康检查：配置网关定期对子图进行健康检查，只同步处于健康状态的子图Schema，避免故障子图影响整个网关的运行。

简言之，单个子图的运行故障（比如Node.js环境无法运行）是部署层面的问题，Apollo Federation架构本身具备隔离这类故障的能力，只要做好容错配置，就能真正体现松耦合的优势——单个子图故障不会拖垮整个系统。

内容的提问来源于stack exchange，提问作者Ertan Özdemir