这会增加延迟吗？

会多一跳。但在商业运营场景中，主要耗时几乎总是外部服务商自身的响应时间，而不是这一跳路由。

如果引擎挂了怎么办？

那它就是单点故障——这正是真实的权衡所在，应当作为一项可用性要求认真对待，而不是轻描淡写地带过。

选型

因为各建各的连接会不断增殖。每个应用最终都持有自己的一套账号、自己的重试逻辑、自己对"请求失败"的理解——一旦出问题，"这段通信到底发生在哪里"这个问题，有多少个应用就有多少个答案。集中接入用"第一条连接稍慢一点"，换来"第二十条便宜得多"。

写第二条直连并不贵，贵的是长期与十五条直连共存。这种成本以运营摩擦的形式到来：故障时没人说得清哪个系统调用了什么；轮换一次凭证要花一周，因为它存在四个地方；供应商改了一个字段，三个应用同时出问题，因为它们各自的解析方式都不一样。

这些在决定"第一条怎么做"的时候一个都看不见——而这正是这个决策常常被做错的原因。

当确实永远只会有一两个对接、而且它们很稳定的时候。这是真实存在的情形，值得如实说明。常见的错误，是在事情刚开始时就以为自己处在这种情形里。