网络方案的三级权衡，及公有云包转发能力的隐藏硬限制

混合云场景下打通私有云和公有云之间的网络，主要有三种方案，代表了性能、安全和成本的不同取舍：公网方案性能完全不可控，而且云服务通常按出带宽计费，比较适合业务之间通信量本来就不多的场景；VPC+VPN方案实际链路依然要经过公网，但换来了更好的安全性，并且可以按私有云的IP段来做统一的网络规划；专线方案性能最好，但价格显著更高，而且专线的稳定性会受运营商政策变化影响，存在这方面的风险。除了这三种方案本身的取舍，微博团队还踩到了一个更隐蔽的坑：网络层面除了带宽这个常见指标，还有一个容易被忽视的关键指标——包转发能力，也就是每秒能收发多少个数据包。团队实测发现有些公有云服务的包转发能力被限制在10万这个量级，而且这个上限和虚机购买的CPU核数、内存大小完全无关，也就是说无论花多少钱升级配置，转发能力都不会提升——推测是云厂商出于安全考虑，在虚拟机层面对这个能力做了硬性限制。这个限制在实际业务中造成了真实的故障，比如Redis主从同步不一致的问题，团队给出的建议是对QPS压力比较重的实例主动做拆分，用多个实例分摊转发压力，而不是指望单个实例靠升配置解决问题。这个案例提示了一条评估云服务性能边界的教训：云服务商公开宣传或计费依据的性能指标（CPU、内存、带宽）不一定覆盖了所有真正会影响业务的技术指标，像”每秒包转发数”这类不常被提及、又和常规配置项脱钩的隐藏上限，往往只有在真实高压场景下才会暴露，评估云服务能力边界时应当主动去实测这类容易被忽略的维度，而不能只看厂商标准宣传单页上列出的那几项参数。