先说结论
应急呼叫系统的 AI 层跑在 Azure，基础设施跑在 AWS。这是一个有意的决定，不是历史遗留，也不是「两边都用一点」的骑墙。
面试官和技术尽调看到这种架构，第一反应通常是「为什么不统一」。这是个好问题，值得认真回答。
为什么 AI 层在 Azure
客户是一家欧洲五百强电梯企业，这个系统服务的是中国市场。也就是说，语音识别和合成必须在中文上表现足够好 —— 不是「能用」，是「在一个人恐慌、语速不稳、背景有噪音的情况下仍然能用」。
当时评估下来，Azure Speech 在三件事上明显更强：中文识别准确率、中文合成的自然度、以及中文的实时流式支持。AWS 的 Transcribe 和 Polly 在英文场景下完全够用，在中文上差距是能听出来的。
在一个应急语音系统里，这不是可以妥协的维度。如果 AI 听错了乘客说的楼层，或者听起来像个机器人让本来就紧张的人更慌，那这次交互就是失败的 —— 后面的架构做得再漂亮也没有意义。
为什么基建在 AWS
理由朴素得多：团队更熟，生态更顺。
- ECS 是成熟的容器编排，团队有实战经验
- 我们需要 ElastiCache 做托管的 Redis —— 不想自己运维 Redis 的复制和故障转移
- 监控体系已经在 CloudWatch 上，自动扩缩要用自定义指标
换句话说：AI 层的选择是被质量驱动的，基础设施层的选择是被可靠交付驱动的。这两个驱动力指向不同的云，所以我们就让它们待在不同的云。
多云的正确理由只有一个：某一层的最优解恰好不在同一家。为了「不被锁定」而多云，通常是在为一个还没发生的问题提前付钱。
这笔账怎么算
代价是明确的：每次识别或合成的调用，比同云多付大约 100 到 300 毫秒的网络开销。在一个以延迟为产品指标的系统里，这不是小数字。
我们做了三件事来压这个成本：
- 区域对齐。AWS 和 Azure 选在同一地理区域，跨云往返压到 50 到 100 毫秒。
- 流式抵消。因为识别和合成都是流式的，这部分开销大量被重叠掉了 —— 它不落在串行关键路径上。
- 长连接。维持常驻 WebSocket，省掉每次调用的握手开销，这一项本身就覆盖了跨云的一大半。
最后落在端到端 2.3 秒。如果当时选了中文表现更差的同云方案，我们会省下这 100–300 毫秒，然后在识别准确率上输掉更多。
什么时候我不会这么做
这个决定是有前提的。换掉任何一个前提，答案就变了：
- 如果语言是英文 —— 两家的差距会小很多，为了这点差距跨云不值得。
- 如果数据要跨云传输且涉及合规 —— 跨境、跨主体的数据流动会带来审计负担，这个成本经常比延迟高得多。
- 如果团队只有两三个人 —— 两套 IAM、两套监控、两份账单、两个故障面。运维复杂度是真实成本，小团队扛不住。
- 如果这条链路不是产品的核心 —— 为一个边缘功能承担跨云复杂度，是典型的过度工程。
带走的规则
跨云是一笔交易，不是一个信仰。写下你用什么换什么、换来的东西值多少、以及你打算怎么把代价压下去。如果这三句话写不出来，那就统一在一家云上。
The conclusion first
In the emergency call system, the AI layer runs on Azure and the infrastructure runs on AWS. That was a deliberate decision — not historical accident, and not hedging by using a bit of both.
Whenever someone reviews this architecture their first reaction is "why not consolidate?" It's a fair question and it deserves a real answer.
Why the AI layer is on Azure
The client was a Fortune 500 Europe elevator company and this system served the Chinese market. Which means speech recognition and synthesis had to be good enough in Mandarin — not "functional", but "still functional when someone is panicking, speaking unevenly, with background noise".
On evaluation, Azure Speech was clearly stronger on three things: Mandarin recognition accuracy, the naturalness of Mandarin synthesis, and real-time streaming support for Mandarin. AWS Transcribe and Polly were entirely adequate in English; in Mandarin the gap was audible.
In an emergency voice system that is not a dimension you compromise. If the AI mishears which floor the passenger is on, or sounds robotic enough to make an already frightened person worse, the interaction has failed — and no amount of elegant architecture behind it matters.
Why the infrastructure is on AWS
Much plainer reasons: the team knew it, and the ecosystem fit.
- ECS is mature container orchestration and the team had run it in anger
- We wanted ElastiCache for managed Redis — nobody wanted to operate Redis replication and failover by hand
- Monitoring already lived in CloudWatch, and autoscaling needed a custom metric there
Put differently: the AI layer was chosen for quality, the infrastructure layer for reliable delivery. Those two forces pointed at different clouds, so we let them sit in different clouds.
There is exactly one good reason to go multi-cloud: the best answer for one layer happens not to live at the same vendor. Going multi-cloud to avoid lock-in is usually paying early for a problem that hasn't happened.
What it costs and how we paid it
The cost is explicit: every recognition or synthesis call carries roughly 100 to 300 milliseconds more network overhead than a same-cloud call. In a system where latency is a product metric, that is not a rounding error.
Three things brought it down:
- Region alignment. AWS and Azure in the same geographic region, which pulls the cross-cloud round trip down to 50–100ms.
- Streaming absorbs it. Because recognition and synthesis both stream, most of that overhead overlaps with work instead of sitting on the serial critical path.
- Persistent connections. Warm WebSockets remove the per-call handshake, which by itself covers a good half of the cross-cloud penalty.
It landed at 2.3 seconds end to end. Had we taken the same-cloud option with weaker Mandarin, we'd have saved that 100–300ms and lost considerably more on recognition accuracy.
When I wouldn't do this
The decision rests on premises. Change any one of them and the answer flips:
- If the language were English — the vendor gap narrows sharply, and crossing clouds for that margin isn't worth it.
- If data crossing clouds raised compliance questions — cross-border, cross-entity data flow brings audit burden that routinely costs more than latency.
- If the team were two or three people — two IAM models, two monitoring stacks, two bills, two failure surfaces. Operational complexity is a real cost and a small team can't absorb it.
- If this path weren't core to the product — carrying cross-cloud complexity for a peripheral feature is textbook over-engineering.
The rule I kept
Multi-cloud is a trade, not a belief. Write down what you're giving up, what you're buying, what that's worth, and how you intend to claw the cost back. If you can't write those four things, consolidate on one cloud.