混合云架构演进的四阶段模型：从接入层代理到真正双活

把本地机房和远端公有云机房之间的关系拆成接入层、服务层、数据层三层来看，混合云架构的演进呈现出一条清晰的递进路径，每一步都对应着”进一步把更多能力挪到远端”这个方向，同时代价和复杂度也随之提升。第一阶段只在接入层做代理回源，目的是借助公有云在全球的部署能力，实现让用户就近接入（用户请求先到最近的公有云节点，再回源到本地机房处理业务），这一步几乎不涉及数据一致性问题，改造成本最低。第二阶段开始在远端接入层旁边铺设当地的服务层，让业务逻辑本身也能在远端就近处理一部分，而不是所有业务逻辑都要回源到本地。第三阶段更进一步，远端的服务层开始直接请求本地的数据（不再仅仅处理逻辑，而是需要访问真实数据），这时如果远端只需要做只读逻辑，只需要把数据做单向同步到远端即可，复杂度相对可控。第四阶段是真正的”双活”：如果远端也需要支持写操作，就必须考虑数据的双向同步，这时对数据一致性和冲突处理的要求急剧上升，不同机房之间的流量切换往往需要借助DNS级别的负载均衡（比如自建HTTP DNS）来实现精细控制。雪球当时的架构演进到了第三阶段——在公有云上部署了一定量的只读服务，获得了部分弹性能力，但还没有真正走到双向同步的双活阶段。这个四阶段模型给出了一条评估自己团队”混合云走到哪一步了”的清晰标尺：从只做接入层代理，到部署远端服务层，到只读数据单向同步，再到真正的双向双活，每一步跨越都伴随着数据一致性复杂度的显著提升，团队应当清楚自己当前处在哪个阶段、下一步跨越需要额外解决什么问题，而不是笼统地追求”上混合云”。

结构图：

flowchart TB
    A["阶段1：接入层代理回源\n借助公有云全球部署就近接入\n复杂度：低"] --> B["阶段2：远端铺设服务层\n业务逻辑在远端就近处理\n复杂度：中低"]
    B --> C["阶段3：远端服务层直接请求本地数据\n(只读场景：数据单向同步)\n复杂度：中"]
    C --> D["阶段4：双活\n(支持写操作：数据双向同步)\n需DNS级流量切换(如HTTP DNS)\n复杂度：高"]
    C -.->|"雪球当前所处阶段\n公有云部署只读服务"| C