/>

如果觉得本文对你有帮助，欢迎关注、点赞、收藏、评论，谢谢

前言

“Lift

and

Shift”（云迁移）通常被宣传为将遗留系统迁移到云端的阻力最小的路径。

理论很简单：将你的本地虚拟机（VMs）复制到像Azure这样的IaaS提供商，然后立即享受可扩展性。

然而，在处理大规模、关键任务系统时，云的物理特性与本地数据中心不同。

关于网络邻近性和连接限制的假设可能导致灾难性的性能故障，这些故障只有在全负载测试期间才会出现。

基于最近一次涉及大量批处理和数千并发用户的大规模迁移回顾，本文重点介绍两个在标准文档中不会出现的特定架构"陷阱"——以及如何修复它们。

#云架构

/>

1、陷阱1：性能与可用性悖论

在现代云架构中，黄金法则是可用性。

我们被教导要将资源分散到不同的可用性区域（AZs）。

如果区域A出现故障（由于电源或冷却故障），区域B可以保持应用程序运行。

然而，在遗留的"云迁移"场景中，这种最佳实践可能会扼杀性能。

场景：批处理失败

考虑一个遗留批处理过程，它执行100万条顺序SQL语句。

在本地，应用程序服务器和数据库服务器位于同一个机架中，通过交换机连接。

延迟可以忽略不计。

在迁移到Azure期间，架构遵循标准HA指南：

• 数据库服务器：部署在区域2（或在区域之间浮动）
• 批处理服务器：部署在区域1

结果

批处理过程有一个严格的SLA窗口，但未能按时完成。

无论进行多少SQL调优、索引优化或查询并行化，都无法解决这个问题。

根本原因：物理限制

问题不在于代码，而在于光速。

数据中心（区域）之间的物理距离引入了网络延迟，这对于单个请求来说可以忽略不计，但在数百万次操作中累积时却是致命的。

延迟的数学计算

• 跨区域延迟：约470微秒
• 区域内延迟：约27微秒

如果你的批处理作业顺序运行1,000,000个查询：

• 跨区域开销：1M

  470

  27秒

这是纯网络等待时间的17倍增加，与CPU或磁盘I/O无关。

解决方案：邻近放置组（PPG）

要解决这个问题，你必须明确地用可用性换取性能。

Azure提供了一个名为邻近放置组（Proximity

Placement

Groups）的功能。

PPG是一个逻辑分组，强制Azure将你的VMs物理定位在尽可能接近的位置——通常在同一数据中心大厅内。

架构权衡：通过使用PPG，你接受如果该特定数据中心出现故障，你的应用程序和数据库都会宕机。

对于批处理窗口，这通常是一个可接受的风险，相比错过SLA。

/>

2、陷阱2："流计数"上限

在调整专用云连接（如Azure

ExpressRoute或AWS

Connect）的大小时，工程师通常关注带宽。

“我们有一个1

Gbps的管道，所以没问题。

”

然而，网络设备（防火墙、负载均衡器和云网关）有第二个通常不可见的限制：网络流。

场景：随机连接断开

迁移后，用户报告各种应用程序出现间歇性连接错误。

带宽利用率很低（低于30%），但数据包被丢弃。

根本原因：流耗尽

流由5元组定义：（源IP、源端口、目标IP、目标端口、协议）

现代SaaS应用程序（Office

365、Teams、OneDrive）是"健谈的"。

单个用户打开浏览器、同步文件和Teams聊天可能会生成50-60个并发流。

如果你有10,000个用户通过标准VPN或ExpressRoute网关路由流量，你不仅仅是在推送数据——你正在维护数十万个状态表条目。

计算

总流数

=

600,000并发流

如果你的ExpressRoute网关SKU仅支持500,000个流，第500,001个连接将被静默丢弃，无论可用带宽如何。

解决方案：流量分流（本地突破）

你无法简单地通过"调优"来摆脱硬基础设施限制。

你必须围绕它进行架构设计。

1. 本地突破（分离隧道）：最强大的架构修复是停止通过你的私有隧道路由SaaS流量。

   配置客户端网络以将受信任的互联网流量（M365、Zoom等）直接路由到互联网，完全绕过Azure网关。

2. 升级SKU：升级到支持更多流的高层网关（例如，Ultra

   Performance）。

   这是快速修复，但会产生更高的成本。

/>

3、迁移前估算流

不要等到生产环境才发现流限制。

你可以使用数据包捕获分析来估算当前流使用情况，对样本用户进行分析。

以下是一个Python代码片段，说明分析.pcap文件（使用Scapy）并为单个用户会话计算唯一流的逻辑：

fromscapy.allimportrdpcapdefcount_unique_flows(pcap_file):packets=rdpcap(pcap_file)flows=set()forpktinpackets:ifpkt.haslayer('IP'):#
通过5元组定义流src=pkt['IP'].src
dst=pkt['IP'].dst
proto=pkt['IP'].proto
sport=pkt.sportifhasattr(pkt,'sport')else0dport=pkt.dportifhasattr(pkt,'dport')else0#
创建唯一的可哈希元组flow_signature=(src,dst,proto,sport,dport)flows.add(flow_signature)returnlen(flows)#
用法：在典型用户的10分钟捕获上运行此代码#
将结果乘以总并发用户数以估算网关大小。
print(f"检测到的唯一流:{count_unique_flows('sample_user_session.pcap')}")

/>

4、总结

云迁移看似简单，实际上很复杂。

移动VMs的工具已经成熟，但从LAN环境迁移到WAN环境的架构影响往往被忽视。

在设计规模时：

• 计算流，而不仅仅是比特：仅通过带宽调整网关大小是不够的。

  建模用户行为并计算并发连接，以避免触及网络设备的硬限制。

• 尊重物理限制：如果延迟很重要（例如，批处理作业），使用邻近放置组在物理上共同定位你的计算和存储。

通过在设计阶段解决这些"不可见"的约束，你可以避免在全面测试阶段中间重新架构网络的恐慌。