混合云两种部署方案的取舍：把公有云当完整数据中心镜像，还是只迁移弹性计算能力

决定要用外部公有云做混合云的第三机房之后，具体怎么部署还有两条截然不同的路径。第一种方案是把公有云当成一个完整的数据中心来镜像部署——底层架构和内部机房完全一致，中间的Web层框架、RPC层、中间件也保持一致；但考虑到存储数据需要处理的一致性、持久性等因素更复杂，初期把公有云单纯当作应付流量峰值的方案更简单，像MySQL、HBase这类存储永久性数据的组件暂不部署到公有云上。第二种方案是只把应付峰值事件所需要的”弹性计算能力”迁移到公有云，其余部分（尤其是有状态的存储层）继续留在内部机房——这个方案的难点在于需要对微博内部业务本身做改造，让内部的中间Web层能够直接对公有云机房发起RPC调用，但换来的好处是整体部署结构相对简单得多，也让混合云架构真正具备了落地可行性。微博团队最终选择了第二种更聚焦的方案。这个案例给出了一条评估”上云该迁多少”的实用判断标准：不必追求”公有云上要有一份和内部机房一模一样的完整副本”这种理想化的对称部署，而应该聚焦于真正驱动这次上云决策的核心诉求是什么——如果诉求是应付流量峰值的弹性计算能力，那么只需要把承载计算能力的这一层迁移上去，有状态、对一致性要求高的存储层完全可以继续留在更可控的内部环境，这样既能达成弹性扩容的核心目标，又能避免把最复杂、最难处理好的部分（数据一致性、跨云同步）过早引入到架构里，用聚焦的迁移范围换取更高的落地可行性。