最近在处理一套跨地域多中心的架构方案顺手把多云与混合云这部分内容重新梳理了一遍。这篇文章对应的就是我自己的架构体系笔记里“10.1 跨越边界”这个小节不过写的时候没收着基本把这几年在真实环境里踩过的坑、设计过的方案、复盘过的故障都揉进来了。无论你是在做架构设计、搞基础架构运维还是公司正在考虑从单云转向多云/混合云布局这篇内容应该都能给你一些可以直接抄作业的经验。先说清楚一件事多云和混合云不是同一个东西但它们经常被混着叫。混合云的典型形态是“私有环境一个或多个公有云”组成一个整体私有部分承载敏感数据或核心系统公有部分承载弹性业务和对外服务。多云则是同时使用两个以上公有云目的是避免单一供应商绑定、做地域容灾、或者不同云上各有各的优势产品。实际企业落地时这两者往往叠加出现我就见过不少团队一边用着两家公有云一边还保留自建机房三股力量拧在一起。1. 只上一朵云不够用了到底什么在驱动多云与混合云1.1 先从定义说起混合云是私有公有多云是“多家公有云并存”架构设计里最忌讳的就是概念不清还硬要谈方案。我在跟团队评审时第一步永远是让所有人把术语对齐尤其是混合云、多云、多集群这三个词。很多人把“我在阿里云开了一个Kubernetes集群同时在腾讯云又开了一个”叫混合云其实这严格来说是“多云多集群”根本不涉及私有环境。如果必须给一个容易理解的分法我是这么划分的混合云Hybrid Cloud至少包含一个企业自控的私有化环境自建机房、私有云平台、一体机等都算和一个公有云环境两者之间通过网络打通、身份打通、数据互通形成一个统一逻辑环境。多云Multi-Cloud同时使用多个公有云厂商的服务比如A云跑在线业务B云跑大数据分析C云做灾备。多云可以不含私有环境也可以叠加在混合云之上。多集群Multi-Cluster不属于云形态而是架构层的手段。即便你只在AWS一朵云上也可以部署多个Kubernetes集群配合联邦管理实现多集群调度。很多混合云项目的落地形态其实就是“私有集群公有集群”的多集群管理模式。所以严格来说多云与混合云是“部署形态”的描述多集群是“技术实现手段”。聊清楚这三层关系后面做方案才不会乱。1.2 驱动力拆解为什么企业宁可把架构做复杂也不绑定一家云任何一个架构决策背后都有痛点驱动多云和混合机房云的流行不是因为“技术时髦”而是因为真实业务提出了单云给不了的诉求。我从大量实际案例里总结出最常见的四类驱动力第一是容灾与业务连续性。单云一旦发生大规模故障业务就跟着停摆这在过去几年里已经被反复验证过。多活架构、跨云容灾成了很多公司的硬性考核项核心系统必须在另一个云或自有机房里有数据副本和可切换的算力。第二是数据合规与数据驻留。国内很多行业对数据存放位置、审计日志都有明确要求企业数据不能随便放到公有云上。于是敏感的放私有环境非敏感的放公有云中间通过数据同步和分级存储打通就成了很自然的选择。第三是避免供应商锁定。公有云产品越来越丰富但也越来越重从计算、网络、存储到数据库、AI平台一旦你深度使用某个云厂商的托管产品迁走的成本高得吓人。很多团队意识到这一点后开始故意把底座做薄核心业务全部跑在Kubernetes之上把上层的数据库、消息队列也尽量选开源方案给自己留后路。第四是压低采购成本。国内云厂商的价格战从来就没停过不同云在不同规格的机型、带宽、存储上各有各的优惠。有的公司会故意把无状态的Web层放在价格便宜的云把大数据计算放在另一家的高性能机型上。这种“用脚投票”的选择天然推动了多云出现。1.3 共同目标架构的根本出发点是“边界可控数据可控”很多技术方案讨论到最后容易迷失在Kubernetes版本、网络插件、自动化脚本这些细节里忘了最根本的问题我们做多云和混合云到底是为了什么我的理解是所有努力都指向两个词边界可控、数据可控。边界可控意思是哪些系统放在哪朵云、哪个区域流量怎么进出安全策略怎么统一执行这些都必须由架构团队说了算而不是被厂商的产品能力推着走。数据可控意思是无论数据在私有环境还是公有云团队都要清楚它存放在哪里、怎么流转、谁有权限访问、如何备份、如何恢复。如果这两个目标没想清楚只是把资源铺到多个云上那只是把单云的单点故障换成了多云的双倍复杂度故障率不降反升。我见过最典型的情况是一家公司同时开了两个云的账号业务也部署上去了但网络没打通两边的运维团队各管各的出了事互相甩锅——这种“多云”比原来还糟糕。2. 跨边界的三座大山网络、身份与数据跨云也好混合云也好所有复杂度归根结底就是三件事网络怎么通、身份怎么认、数据怎么同步。这三座大山翻不过去后面的应用改造、容灾切换、成本管理全都是空中楼阁。2.1 网络连通性专线、加密隧道与Overlay的选择逻辑混合云第一个绕不开的话题就是网络。私有机房和公有云之间的互通大体上有三种方案直接对比着看方案延迟/稳定性成本适用场景云专线/直接连接低延迟、稳定较高有月租和端口费核心业务、数据库同步、高频读写加密隧道公网传输取决于公网链路有波动低几乎免费测试环境、管理面通信、低频数据SD-WAN/第三方组网中具备链路优化能力中等按带宽和节点计费多分支机构、多地域互联我个人的建议是控制面和管理面可以走加密隧道降低成本数据面关键流量尽量走专线。比如Kubernetes的API Server通信、监控数据采集这种管理流量偶尔断个几十秒问题不大没必要花专线钱但数据库主从同步、对象存储的双写复制这种高频数据流如果跑在公网上随时可能因为网络抖动导致同步延迟飙升最后损坏的是数据一致性。还有一个很容易被忽略的点底层网络再通上层业务也不能直接互访。不同云环境虽然有IP地址规划但安全组、防火墙规则、路由表都是各自为政的。做网络规划时域名往往是比IP更稳定的契约。我在做混合云项目的第一个动作就是跟业务团队敲定内部域名规范比如数据库用mysql.internal.xxx缓存用redis.internal.xxx这样就算哪天把整套系统从A云迁到B云域名都不用变只需要改DNS解析。2.2 身份与权限联邦认证如何避免“一套环境一套账号”网络通了之后紧接着就是身份认证。很多公司的混合云翻车现场不是网络断了而是协作文档里记了十几个控制台地址每个环境一套账号密码有的还要手机验证码运维同事每天光登录控制台就要花20分钟安全审计更是无从谈起。正确做法是搭建一套统一的身份认证中心用SAML或OIDC协议对接各个云厂商的IdP身份提供商让员工通过企业统一账号登录任意一朵云的控制台。这样员工不用记多套密码离职时也只需在主身份系统里禁用账号所有环境的访问权限自动失效。这里有一个我强烈建议的操作所有云环境都在身份体系里按“项目环境角色”划分权限。比如一个Java开发工程师的权限就是“订单项目-测试环境-只读”不要图省事直接给“管理员”。云平台的权限系统非常强大但它只认策略不认你的组织结构你必须自己先把人员、职责、环境之间的关系抽象出来然后映射到云平台的角色上。2.3 数据同步与双活不要迷信强一致先想清楚最终一致数据是混合云里最棘手的一座山。因为网络延迟再低也有极限跨机房的两份数据很难做到真正意义上的强一致尤其是需要同步复制的时候。这里绕不开分布式系统最基础的CAP理论分区容错性P在跨云场景下是一定存在的那你在可用性A和一致性C之间必须做个取舍。绝大部分业务系统的数据同步最终选择的都是最终一致。具体实现上有几条常见路径对象存储用厂商的跨区域复制或者自己在业务层做双写异步同步到对端。关系型数据库用CDCChange Data Capture工具比如Debezium或Flink CDC把主库的BinLog变更实时抓到消息队列再异步回放到另一个环境的从库或异构数据库。缓存与消息队列这类无状态或短状态组件通常不做跨云同步而是各自部署一套通过业务侧的幂等设计来容忍短暂的不一致。在做同步方案之前我建议你先跟业务方对齐一个关键问题你要求的最长容忍不一致时间是多少如果业务能接受1分钟延迟那方案可以做得非常简单如果要求5秒内必须看到最新数据那网络链路和中间件都得升级成本直接翻几倍。大多数情况下业务方给出的答案都是“其实几十秒也能接受”这时候你的方案就从容很多。3. 落地一条可复用的混合云架构聊完概念和难点接下来进入实操章节。我以一家典型的在线教育公司为例完整走一遍混合云架构从需求到落地的全过程。这个案例我在画架构图时打磨过很多遍基本可以套用到大多数互联网业务场景。3.1 一个贴近真实的场景在线教育的跨云改造需求假设公司原本的架构是所有业务跑在自建机房用Kubernetes管理数据库是自建的MySQL一主两从对象存储用私有化部署的MinIO。最近业务增长快机房扩容周期太长而且每年电商大促和寒暑假流量高峰时机房资源扛不住突发流量。管理层决定引入公有云。经过评估最终架构形态定为自建机房保留承载核心交易数据、财务数据、用户敏感信息。公有云A承载无状态的前端服务、课程视频转码、弹性扩缩容的计算节点。公有云B作为冷备和灾备环境定期接收数据备份。机房与两朵公有云之间分别用专线打通专线故障时自动降级到加密隧道。这个设计的核心思路是“私有环境不轻易动公有云只管弹性”。核心数据不动合规风险就可控无状态服务上云弹性问题就解决。3.2 网络层落地Underlay和Overlay的分工与配置要点网络层的设计是整个混合云的地基。这里要先分清underlay和overlay两个概念。Underlay是物理层真实存在的网络路径比如机房到云端的专线或者云厂商内部的数据中心网络Overlay是在underlay之上通过隧道技术构建的逻辑网络比如VXLAN、网络插件创建的Pod网络。在混合云场景下我推荐把底层网络规划成两段第一段是underlay解决机房与各云之间的物理连通。专线的IP地址规划建议拿独立的IP段跟机房的业务网段、云上的VPC网段分开。比如机房业务段用10.1.0.0/16云端VPC用10.11.0.0/16和10.12.0.0/16机房到云端的互联段用192.168.200.0/24。这样的规划可以避免以后业务网段膨胀导致IP冲突这是混合云架构里最容易踩的隐形大坑。如果两边网段有重叠路由就彻底乱套那就不只是网络不通而是会出现数据送到错误主机的级别灾难。第二段是overlay解决业务之间的互访和隔离。Kubernetes跨集群的Pod网络建议用业界主流的网络插件底层走BGP和VXLAN多集群统一分配网段。需要注意overlay网络要正常工作依赖underlay的路由可达性所以我在设计时都会预留专门的网络运维窗口用来查看underlay的路由状态和带宽利用率。还有一个细节不要所有流量都塞进overlay。比如时序数据库的远程写入、日志的集中采集这些高带宽流量直接在underlay走专线反而更高效绕一圈overlay只是白白增加UDP封装开销浪费CPU。3.3 计算层落地K8s多集群与统一资源调度计算层是混合云架构里最能体现现代架构风格的部分。整个公司已经有Kubernetes基础所以升级到多集群管理并不需要推倒重来。我的建议是搭建一个多集群管理平台来统一管理机房集群和云上集群而不是手工分别操作。当前可选的方案不少有开源社区活跃的Karmada、OCM也有商业产品。它们的共同点是让你在一个控制面上看多个集群能够统一分发工作负载、配置策略、查看运行状态。但这里我强调一个经验联邦控制面只负责“下发”和“策略”不要让它变成所有请求的流量代理。如果你把所有应用的访问都经控制面转发那它就成了一个巨大的单点瓶颈故障半径比原来还大。正确姿势是控制面只做配置同步和状态收集真正的业务流量仍然在各自的集群内闭环。另一个典型场景是弹性伸缩和突发流量分担。我们当时监控机房集群的CPU和Pod数量一旦接近阈值就把新扩容的Pod调度到公有云的节点上。这里面有几个关键前提镜像要能从私有仓库拉到云上一般用各云厂商提供的镜像仓库同步功能配置中心要能跨网络访问日志要能汇聚到统一平台。任何一个环节不通跨云扩容就是空话。3.4 数据层落地对象存储与数据库的同步策略数据是我不敢随便折腾的部分所以落了比较保守的方案。对象存储层面私有机的MinIO作为主存储公有云的对象存储作为热备份和缓存。MinIO支持跨站点复制可以直接同步到云上的兼容S3协议的存储。这个同步的延迟一般能做到分钟级对在线教育场景下的视频文件、课件资源完全够用。数据库层面核心交易库仍然留在机房做主库公有云上部署一个只读从库。通过CDC工具订阅主库的BinLog变更实时回放到云端从库。这样的话云端服务读取数据时直接查云上从库对机房主库的访问频率大幅降低。如果机房发生重大故障云端从库可以紧急提升为主库业务至少在云端能保持“可读”状态通过运维和业务协同再恢复写能力。这里一定不要忘了重新设计写入链路。很多团队在设计混合云时只想着同步数据却忽略了业务写入还是得到机房主库一旦专线抖动云端业务的首次写入就卡住了。所以如果业务对写延迟很敏感建议在云端做主库分片或部署独立的写入集群通过MQ异步同步回机房进行数据汇总而不是让云端所有写请求都依赖专线。3.5 统一运维监控、日志与告警的集中化方案混合云环境多了运维的复杂度是成倍增加的。如果没有统一的可观测性系统故障排查几乎是噩梦等级到A云看看CPU再到B云翻日志又回机房查数据库慢查询最后发现是A云的负载均衡策略出了问题。我的做法是在机房部署一套统一监控体系所有云环境的数据统一汇聚进来指标用Prometheus做采集Thanos做长期存储和全局查询日志用Elasticsearch或Loki链路追踪用OpenTelemetry。各集群的Agent采集到的数据通过各自的网络链路统一送到监控中心。这里有个建议供参考监控链路和业务链路要分开规划。监控链路要求“及时”不要求“绝对稳定”可以走成本更低的加密隧道业务链路要求“稳定低延迟”值得走专线。把这两个链路混在一起不仅会在故障时互相干扰账务还很难分清楚。4. 运维与成本多云架构最容易失控的两个环节混合云的网络、身份、数据都搞定了业务也能在多朵云之间灵活调度了这时候你以为就结束了吗远远没有。真正让架构团队头大的其实是长期的运维复杂度和成本管理。这两个环节失控的案例我见过太多值得单独拿出来聊透。4.1 配置漂移为什么说基础设施即代码是“安全带”在一个跨多个环境中最隐蔽的风险不是突发故障而是配置漂移。什么叫配置漂移就是每朵云、每个集群的配置不是在同一时间点创建的而是分散在各个不同阶段人工调整出来的。时间一长A云和B云的安全规则、负载均衡参数、监控阈值就会慢慢不一样表面上系统没问题但这些“小差异”会在某次故障时被无限放大。解决配置漂移最有效的手段就是基础设施即代码IaC。我一般用Terraform管理公有云的资源用Git来版本化所有基础设施配置集群里的应用配置则全部存放在Git仓库不允许任何人直接登录服务器手工修改。每次变更都是代码提交、评审、执行、验证的流程。这样任意环境被改坏了都可以把配置再“重新放一遍”恢复到期望状态。但这里有个容易被忽略的细节IaC不是写一次就完了你得定期做配置校验。有些云平台的terraform provider更新后会改变某些资源的默认参数可能导致原本可以正常apply的代码突然报错。所以我会尽量固定terraform和provider的版本并且建立每周一次的“空跑”检查确保配置代码本身没有问题。4.2 成本失控云账单里的“隐藏扣费项目”多云架构的钱坑可能比你想象的深。每家云的计费模式差异很大尤其这几个最常见的隐藏消费点值得你特别留意跨可用区或跨地域流量费专线带宽费和公网流量费是两笔钱专线是按带宽月租而云端到机房的数据旋转如果走公网流量单价很贵。存储快照与备份费用你以为只存了一份数据实际上快照占用的空间比你想象的大得多而且跨环境复制备份的双重费用经常被忽略。弹性IP与负载均衡空置费很多团队测试完环境忘了释放公网IP按月计费积累下来几百几千的成本就这么悄悄流失了。隐形的最小计费单位某些云厂商对一个Pod、一个Log日志都按GB计费看起来单价很低一旦量上来账单立刻裸奔。我的建议是尽快引入FinOps的意识至少做到三件事一是所有云资源强制打标签区分项目、环境和owner二是每个月用成本分析工具做一次账单Review找出排名前几的资源三是给每个环境设定预算阈值超支自动告警。这些基础动作不花什么钱但对成本控制的效果立竿见影。4.3 团队协作平台工程思维下的分工建议系统架构复杂到一定程度光靠几个架构师是撑不住的。混合云环境的日常维护必须交到平台团队手上所以我一般建议用“平台工程”的思路去组建team。简单说就是专门有一个平台团队负责“抽象基础设施的细节”让业务研发不需要理解A云和B云的控制台差异。平台团队提供一套统一界面或API入口业务团队只需说自己要什么资源平台自动在对应的云上分配。这样业务团队不用学云厂商的复杂控制台而平台团队可以集中精力做多云的编排、监控、成本优化和故障响应。有一句话我特别想分享给基础架构的兄弟们架构的复杂度和团队的能力要匹配。如果现在团队连单云环境的故障定位都还吃力就别急着上多云先把单云的基础打牢。云的边界跨越是给已有成熟体系的锦上添花不是救命稻草。5. 常见问题与排查技巧实录最后分享一些我在实际运维和故障排查中积累下来的经验。这些几乎都是文档里不会写清楚的但遇到问题时它们往往就是救命稻草。5.1 网络间歇性抖动root cause是MTU跨云网络的间歇性ping通、时延飘忽不定十有八九是MTU的问题。云端VPC的MTU默认值常常比机房的偏大当数据包超过专线设备的支持范围时就会触发分片而分片在高频业务下会导致部分报文被丢弃。排查方法是在两端分别ping一个带指定大小的大包逐步减小找到临界值然后统一调整隧道接口或网络插件的MTU设置。注意调整MTU后要同时检查防火墙和负载均衡设备因为它们也可能对大于特定值的包做丢包处理。5.2 联邦认证突然失效多半是证书或端点配置这种问题看似神秘其实根因就那么几个。最常见的是身份认证证书过期尤其是在自建IdP和云上IdP之间配置的签名证书有效期一年过期时间到了直接失效。另一个是后端端点地址变了比如云厂商的IdP域名IP变更或者内部DNS缓存了旧地址。我一般会在运维日历里设一个“证书到期前30天”的循环提醒同时在身份系统接入前置机专门做证书存活和端点可达性监控。5.3 跨云DNS解析混乱Split DNS要做好跨环境的服务互访最忌讳的就是在DNS配置里出现“同一域名不同结果”。比如在机房内网访问order.internal返回私有地址在云上VPC访问同一个域名却是另一个IP。如果你不做特殊设计流量就可能错误地跨网绕行时延和费用一起涨。标准做法是搭建split DNS按不同的网络位置返回对应的解析结果并且定期抽查核心服务的解析记录是否一致。5.4 数据同步延迟飙升从CDC日志和带宽两个方向查数据同步延迟从分钟级飙升到小时级我建议两头同时查一是CDC工具的消费日志看看是不是BinLog消费位点卡住了比如源库长时间大事务、订阅端处理异常二是专线的带宽利用率如果专线已经被别的业务流量占满即便你的同步程序正常数据排队也会造成延迟。这两种情况表象一样处理方式完全不同排查时不要只看一端。5.5 集群联邦“调度不心疼”即亲和性与优先级要提前规划多集群调度器确实好用但如果一开始不配置调度约束它会做出很多“合理但不可用”的决定。比如把需要访问机房内部数据的Pod调度到公有云节点结果Pod启动成功后无法连接数据库业务直接失败。给workload设置好区域亲和性和拓扑分布约束在集群联邦里是必须做的事而不是可选优化项。最有效的做法是在部署模板里明确标注每个工作负载的“必须本集群”“优先本集群”“任意集群”三种调度级别从源头杜绝这类问题。最后再聊一点个人体会。混合云架构看上去是在解决技术问题但本质上是在帮企业建立一种“选择权”今天可以用A云明天可以用B云核心业务可以留在私有环境弹性部分随时借助公有云扩展。这个选择权需要付出不小的复杂度代价它不会让架构变简单但会让架构变得更稳、更灵活。搞这一块没有捷径扎实的网络底子、明确的数据边界、统一的管理平台缺一不可。希望这篇内容能帮你少走一些弯路。
多云与混合云架构设计：跨边界、数据与运维实战
最近在处理一套跨地域多中心的架构方案顺手把多云与混合云这部分内容重新梳理了一遍。这篇文章对应的就是我自己的架构体系笔记里“10.1 跨越边界”这个小节不过写的时候没收着基本把这几年在真实环境里踩过的坑、设计过的方案、复盘过的故障都揉进来了。无论你是在做架构设计、搞基础架构运维还是公司正在考虑从单云转向多云/混合云布局这篇内容应该都能给你一些可以直接抄作业的经验。先说清楚一件事多云和混合云不是同一个东西但它们经常被混着叫。混合云的典型形态是“私有环境一个或多个公有云”组成一个整体私有部分承载敏感数据或核心系统公有部分承载弹性业务和对外服务。多云则是同时使用两个以上公有云目的是避免单一供应商绑定、做地域容灾、或者不同云上各有各的优势产品。实际企业落地时这两者往往叠加出现我就见过不少团队一边用着两家公有云一边还保留自建机房三股力量拧在一起。1. 只上一朵云不够用了到底什么在驱动多云与混合云1.1 先从定义说起混合云是私有公有多云是“多家公有云并存”架构设计里最忌讳的就是概念不清还硬要谈方案。我在跟团队评审时第一步永远是让所有人把术语对齐尤其是混合云、多云、多集群这三个词。很多人把“我在阿里云开了一个Kubernetes集群同时在腾讯云又开了一个”叫混合云其实这严格来说是“多云多集群”根本不涉及私有环境。如果必须给一个容易理解的分法我是这么划分的混合云Hybrid Cloud至少包含一个企业自控的私有化环境自建机房、私有云平台、一体机等都算和一个公有云环境两者之间通过网络打通、身份打通、数据互通形成一个统一逻辑环境。多云Multi-Cloud同时使用多个公有云厂商的服务比如A云跑在线业务B云跑大数据分析C云做灾备。多云可以不含私有环境也可以叠加在混合云之上。多集群Multi-Cluster不属于云形态而是架构层的手段。即便你只在AWS一朵云上也可以部署多个Kubernetes集群配合联邦管理实现多集群调度。很多混合云项目的落地形态其实就是“私有集群公有集群”的多集群管理模式。所以严格来说多云与混合云是“部署形态”的描述多集群是“技术实现手段”。聊清楚这三层关系后面做方案才不会乱。1.2 驱动力拆解为什么企业宁可把架构做复杂也不绑定一家云任何一个架构决策背后都有痛点驱动多云和混合机房云的流行不是因为“技术时髦”而是因为真实业务提出了单云给不了的诉求。我从大量实际案例里总结出最常见的四类驱动力第一是容灾与业务连续性。单云一旦发生大规模故障业务就跟着停摆这在过去几年里已经被反复验证过。多活架构、跨云容灾成了很多公司的硬性考核项核心系统必须在另一个云或自有机房里有数据副本和可切换的算力。第二是数据合规与数据驻留。国内很多行业对数据存放位置、审计日志都有明确要求企业数据不能随便放到公有云上。于是敏感的放私有环境非敏感的放公有云中间通过数据同步和分级存储打通就成了很自然的选择。第三是避免供应商锁定。公有云产品越来越丰富但也越来越重从计算、网络、存储到数据库、AI平台一旦你深度使用某个云厂商的托管产品迁走的成本高得吓人。很多团队意识到这一点后开始故意把底座做薄核心业务全部跑在Kubernetes之上把上层的数据库、消息队列也尽量选开源方案给自己留后路。第四是压低采购成本。国内云厂商的价格战从来就没停过不同云在不同规格的机型、带宽、存储上各有各的优惠。有的公司会故意把无状态的Web层放在价格便宜的云把大数据计算放在另一家的高性能机型上。这种“用脚投票”的选择天然推动了多云出现。1.3 共同目标架构的根本出发点是“边界可控数据可控”很多技术方案讨论到最后容易迷失在Kubernetes版本、网络插件、自动化脚本这些细节里忘了最根本的问题我们做多云和混合云到底是为了什么我的理解是所有努力都指向两个词边界可控、数据可控。边界可控意思是哪些系统放在哪朵云、哪个区域流量怎么进出安全策略怎么统一执行这些都必须由架构团队说了算而不是被厂商的产品能力推着走。数据可控意思是无论数据在私有环境还是公有云团队都要清楚它存放在哪里、怎么流转、谁有权限访问、如何备份、如何恢复。如果这两个目标没想清楚只是把资源铺到多个云上那只是把单云的单点故障换成了多云的双倍复杂度故障率不降反升。我见过最典型的情况是一家公司同时开了两个云的账号业务也部署上去了但网络没打通两边的运维团队各管各的出了事互相甩锅——这种“多云”比原来还糟糕。2. 跨边界的三座大山网络、身份与数据跨云也好混合云也好所有复杂度归根结底就是三件事网络怎么通、身份怎么认、数据怎么同步。这三座大山翻不过去后面的应用改造、容灾切换、成本管理全都是空中楼阁。2.1 网络连通性专线、加密隧道与Overlay的选择逻辑混合云第一个绕不开的话题就是网络。私有机房和公有云之间的互通大体上有三种方案直接对比着看方案延迟/稳定性成本适用场景云专线/直接连接低延迟、稳定较高有月租和端口费核心业务、数据库同步、高频读写加密隧道公网传输取决于公网链路有波动低几乎免费测试环境、管理面通信、低频数据SD-WAN/第三方组网中具备链路优化能力中等按带宽和节点计费多分支机构、多地域互联我个人的建议是控制面和管理面可以走加密隧道降低成本数据面关键流量尽量走专线。比如Kubernetes的API Server通信、监控数据采集这种管理流量偶尔断个几十秒问题不大没必要花专线钱但数据库主从同步、对象存储的双写复制这种高频数据流如果跑在公网上随时可能因为网络抖动导致同步延迟飙升最后损坏的是数据一致性。还有一个很容易被忽略的点底层网络再通上层业务也不能直接互访。不同云环境虽然有IP地址规划但安全组、防火墙规则、路由表都是各自为政的。做网络规划时域名往往是比IP更稳定的契约。我在做混合云项目的第一个动作就是跟业务团队敲定内部域名规范比如数据库用mysql.internal.xxx缓存用redis.internal.xxx这样就算哪天把整套系统从A云迁到B云域名都不用变只需要改DNS解析。2.2 身份与权限联邦认证如何避免“一套环境一套账号”网络通了之后紧接着就是身份认证。很多公司的混合云翻车现场不是网络断了而是协作文档里记了十几个控制台地址每个环境一套账号密码有的还要手机验证码运维同事每天光登录控制台就要花20分钟安全审计更是无从谈起。正确做法是搭建一套统一的身份认证中心用SAML或OIDC协议对接各个云厂商的IdP身份提供商让员工通过企业统一账号登录任意一朵云的控制台。这样员工不用记多套密码离职时也只需在主身份系统里禁用账号所有环境的访问权限自动失效。这里有一个我强烈建议的操作所有云环境都在身份体系里按“项目环境角色”划分权限。比如一个Java开发工程师的权限就是“订单项目-测试环境-只读”不要图省事直接给“管理员”。云平台的权限系统非常强大但它只认策略不认你的组织结构你必须自己先把人员、职责、环境之间的关系抽象出来然后映射到云平台的角色上。2.3 数据同步与双活不要迷信强一致先想清楚最终一致数据是混合云里最棘手的一座山。因为网络延迟再低也有极限跨机房的两份数据很难做到真正意义上的强一致尤其是需要同步复制的时候。这里绕不开分布式系统最基础的CAP理论分区容错性P在跨云场景下是一定存在的那你在可用性A和一致性C之间必须做个取舍。绝大部分业务系统的数据同步最终选择的都是最终一致。具体实现上有几条常见路径对象存储用厂商的跨区域复制或者自己在业务层做双写异步同步到对端。关系型数据库用CDCChange Data Capture工具比如Debezium或Flink CDC把主库的BinLog变更实时抓到消息队列再异步回放到另一个环境的从库或异构数据库。缓存与消息队列这类无状态或短状态组件通常不做跨云同步而是各自部署一套通过业务侧的幂等设计来容忍短暂的不一致。在做同步方案之前我建议你先跟业务方对齐一个关键问题你要求的最长容忍不一致时间是多少如果业务能接受1分钟延迟那方案可以做得非常简单如果要求5秒内必须看到最新数据那网络链路和中间件都得升级成本直接翻几倍。大多数情况下业务方给出的答案都是“其实几十秒也能接受”这时候你的方案就从容很多。3. 落地一条可复用的混合云架构聊完概念和难点接下来进入实操章节。我以一家典型的在线教育公司为例完整走一遍混合云架构从需求到落地的全过程。这个案例我在画架构图时打磨过很多遍基本可以套用到大多数互联网业务场景。3.1 一个贴近真实的场景在线教育的跨云改造需求假设公司原本的架构是所有业务跑在自建机房用Kubernetes管理数据库是自建的MySQL一主两从对象存储用私有化部署的MinIO。最近业务增长快机房扩容周期太长而且每年电商大促和寒暑假流量高峰时机房资源扛不住突发流量。管理层决定引入公有云。经过评估最终架构形态定为自建机房保留承载核心交易数据、财务数据、用户敏感信息。公有云A承载无状态的前端服务、课程视频转码、弹性扩缩容的计算节点。公有云B作为冷备和灾备环境定期接收数据备份。机房与两朵公有云之间分别用专线打通专线故障时自动降级到加密隧道。这个设计的核心思路是“私有环境不轻易动公有云只管弹性”。核心数据不动合规风险就可控无状态服务上云弹性问题就解决。3.2 网络层落地Underlay和Overlay的分工与配置要点网络层的设计是整个混合云的地基。这里要先分清underlay和overlay两个概念。Underlay是物理层真实存在的网络路径比如机房到云端的专线或者云厂商内部的数据中心网络Overlay是在underlay之上通过隧道技术构建的逻辑网络比如VXLAN、网络插件创建的Pod网络。在混合云场景下我推荐把底层网络规划成两段第一段是underlay解决机房与各云之间的物理连通。专线的IP地址规划建议拿独立的IP段跟机房的业务网段、云上的VPC网段分开。比如机房业务段用10.1.0.0/16云端VPC用10.11.0.0/16和10.12.0.0/16机房到云端的互联段用192.168.200.0/24。这样的规划可以避免以后业务网段膨胀导致IP冲突这是混合云架构里最容易踩的隐形大坑。如果两边网段有重叠路由就彻底乱套那就不只是网络不通而是会出现数据送到错误主机的级别灾难。第二段是overlay解决业务之间的互访和隔离。Kubernetes跨集群的Pod网络建议用业界主流的网络插件底层走BGP和VXLAN多集群统一分配网段。需要注意overlay网络要正常工作依赖underlay的路由可达性所以我在设计时都会预留专门的网络运维窗口用来查看underlay的路由状态和带宽利用率。还有一个细节不要所有流量都塞进overlay。比如时序数据库的远程写入、日志的集中采集这些高带宽流量直接在underlay走专线反而更高效绕一圈overlay只是白白增加UDP封装开销浪费CPU。3.3 计算层落地K8s多集群与统一资源调度计算层是混合云架构里最能体现现代架构风格的部分。整个公司已经有Kubernetes基础所以升级到多集群管理并不需要推倒重来。我的建议是搭建一个多集群管理平台来统一管理机房集群和云上集群而不是手工分别操作。当前可选的方案不少有开源社区活跃的Karmada、OCM也有商业产品。它们的共同点是让你在一个控制面上看多个集群能够统一分发工作负载、配置策略、查看运行状态。但这里我强调一个经验联邦控制面只负责“下发”和“策略”不要让它变成所有请求的流量代理。如果你把所有应用的访问都经控制面转发那它就成了一个巨大的单点瓶颈故障半径比原来还大。正确姿势是控制面只做配置同步和状态收集真正的业务流量仍然在各自的集群内闭环。另一个典型场景是弹性伸缩和突发流量分担。我们当时监控机房集群的CPU和Pod数量一旦接近阈值就把新扩容的Pod调度到公有云的节点上。这里面有几个关键前提镜像要能从私有仓库拉到云上一般用各云厂商提供的镜像仓库同步功能配置中心要能跨网络访问日志要能汇聚到统一平台。任何一个环节不通跨云扩容就是空话。3.4 数据层落地对象存储与数据库的同步策略数据是我不敢随便折腾的部分所以落了比较保守的方案。对象存储层面私有机的MinIO作为主存储公有云的对象存储作为热备份和缓存。MinIO支持跨站点复制可以直接同步到云上的兼容S3协议的存储。这个同步的延迟一般能做到分钟级对在线教育场景下的视频文件、课件资源完全够用。数据库层面核心交易库仍然留在机房做主库公有云上部署一个只读从库。通过CDC工具订阅主库的BinLog变更实时回放到云端从库。这样的话云端服务读取数据时直接查云上从库对机房主库的访问频率大幅降低。如果机房发生重大故障云端从库可以紧急提升为主库业务至少在云端能保持“可读”状态通过运维和业务协同再恢复写能力。这里一定不要忘了重新设计写入链路。很多团队在设计混合云时只想着同步数据却忽略了业务写入还是得到机房主库一旦专线抖动云端业务的首次写入就卡住了。所以如果业务对写延迟很敏感建议在云端做主库分片或部署独立的写入集群通过MQ异步同步回机房进行数据汇总而不是让云端所有写请求都依赖专线。3.5 统一运维监控、日志与告警的集中化方案混合云环境多了运维的复杂度是成倍增加的。如果没有统一的可观测性系统故障排查几乎是噩梦等级到A云看看CPU再到B云翻日志又回机房查数据库慢查询最后发现是A云的负载均衡策略出了问题。我的做法是在机房部署一套统一监控体系所有云环境的数据统一汇聚进来指标用Prometheus做采集Thanos做长期存储和全局查询日志用Elasticsearch或Loki链路追踪用OpenTelemetry。各集群的Agent采集到的数据通过各自的网络链路统一送到监控中心。这里有个建议供参考监控链路和业务链路要分开规划。监控链路要求“及时”不要求“绝对稳定”可以走成本更低的加密隧道业务链路要求“稳定低延迟”值得走专线。把这两个链路混在一起不仅会在故障时互相干扰账务还很难分清楚。4. 运维与成本多云架构最容易失控的两个环节混合云的网络、身份、数据都搞定了业务也能在多朵云之间灵活调度了这时候你以为就结束了吗远远没有。真正让架构团队头大的其实是长期的运维复杂度和成本管理。这两个环节失控的案例我见过太多值得单独拿出来聊透。4.1 配置漂移为什么说基础设施即代码是“安全带”在一个跨多个环境中最隐蔽的风险不是突发故障而是配置漂移。什么叫配置漂移就是每朵云、每个集群的配置不是在同一时间点创建的而是分散在各个不同阶段人工调整出来的。时间一长A云和B云的安全规则、负载均衡参数、监控阈值就会慢慢不一样表面上系统没问题但这些“小差异”会在某次故障时被无限放大。解决配置漂移最有效的手段就是基础设施即代码IaC。我一般用Terraform管理公有云的资源用Git来版本化所有基础设施配置集群里的应用配置则全部存放在Git仓库不允许任何人直接登录服务器手工修改。每次变更都是代码提交、评审、执行、验证的流程。这样任意环境被改坏了都可以把配置再“重新放一遍”恢复到期望状态。但这里有个容易被忽略的细节IaC不是写一次就完了你得定期做配置校验。有些云平台的terraform provider更新后会改变某些资源的默认参数可能导致原本可以正常apply的代码突然报错。所以我会尽量固定terraform和provider的版本并且建立每周一次的“空跑”检查确保配置代码本身没有问题。4.2 成本失控云账单里的“隐藏扣费项目”多云架构的钱坑可能比你想象的深。每家云的计费模式差异很大尤其这几个最常见的隐藏消费点值得你特别留意跨可用区或跨地域流量费专线带宽费和公网流量费是两笔钱专线是按带宽月租而云端到机房的数据旋转如果走公网流量单价很贵。存储快照与备份费用你以为只存了一份数据实际上快照占用的空间比你想象的大得多而且跨环境复制备份的双重费用经常被忽略。弹性IP与负载均衡空置费很多团队测试完环境忘了释放公网IP按月计费积累下来几百几千的成本就这么悄悄流失了。隐形的最小计费单位某些云厂商对一个Pod、一个Log日志都按GB计费看起来单价很低一旦量上来账单立刻裸奔。我的建议是尽快引入FinOps的意识至少做到三件事一是所有云资源强制打标签区分项目、环境和owner二是每个月用成本分析工具做一次账单Review找出排名前几的资源三是给每个环境设定预算阈值超支自动告警。这些基础动作不花什么钱但对成本控制的效果立竿见影。4.3 团队协作平台工程思维下的分工建议系统架构复杂到一定程度光靠几个架构师是撑不住的。混合云环境的日常维护必须交到平台团队手上所以我一般建议用“平台工程”的思路去组建team。简单说就是专门有一个平台团队负责“抽象基础设施的细节”让业务研发不需要理解A云和B云的控制台差异。平台团队提供一套统一界面或API入口业务团队只需说自己要什么资源平台自动在对应的云上分配。这样业务团队不用学云厂商的复杂控制台而平台团队可以集中精力做多云的编排、监控、成本优化和故障响应。有一句话我特别想分享给基础架构的兄弟们架构的复杂度和团队的能力要匹配。如果现在团队连单云环境的故障定位都还吃力就别急着上多云先把单云的基础打牢。云的边界跨越是给已有成熟体系的锦上添花不是救命稻草。5. 常见问题与排查技巧实录最后分享一些我在实际运维和故障排查中积累下来的经验。这些几乎都是文档里不会写清楚的但遇到问题时它们往往就是救命稻草。5.1 网络间歇性抖动root cause是MTU跨云网络的间歇性ping通、时延飘忽不定十有八九是MTU的问题。云端VPC的MTU默认值常常比机房的偏大当数据包超过专线设备的支持范围时就会触发分片而分片在高频业务下会导致部分报文被丢弃。排查方法是在两端分别ping一个带指定大小的大包逐步减小找到临界值然后统一调整隧道接口或网络插件的MTU设置。注意调整MTU后要同时检查防火墙和负载均衡设备因为它们也可能对大于特定值的包做丢包处理。5.2 联邦认证突然失效多半是证书或端点配置这种问题看似神秘其实根因就那么几个。最常见的是身份认证证书过期尤其是在自建IdP和云上IdP之间配置的签名证书有效期一年过期时间到了直接失效。另一个是后端端点地址变了比如云厂商的IdP域名IP变更或者内部DNS缓存了旧地址。我一般会在运维日历里设一个“证书到期前30天”的循环提醒同时在身份系统接入前置机专门做证书存活和端点可达性监控。5.3 跨云DNS解析混乱Split DNS要做好跨环境的服务互访最忌讳的就是在DNS配置里出现“同一域名不同结果”。比如在机房内网访问order.internal返回私有地址在云上VPC访问同一个域名却是另一个IP。如果你不做特殊设计流量就可能错误地跨网绕行时延和费用一起涨。标准做法是搭建split DNS按不同的网络位置返回对应的解析结果并且定期抽查核心服务的解析记录是否一致。5.4 数据同步延迟飙升从CDC日志和带宽两个方向查数据同步延迟从分钟级飙升到小时级我建议两头同时查一是CDC工具的消费日志看看是不是BinLog消费位点卡住了比如源库长时间大事务、订阅端处理异常二是专线的带宽利用率如果专线已经被别的业务流量占满即便你的同步程序正常数据排队也会造成延迟。这两种情况表象一样处理方式完全不同排查时不要只看一端。5.5 集群联邦“调度不心疼”即亲和性与优先级要提前规划多集群调度器确实好用但如果一开始不配置调度约束它会做出很多“合理但不可用”的决定。比如把需要访问机房内部数据的Pod调度到公有云节点结果Pod启动成功后无法连接数据库业务直接失败。给workload设置好区域亲和性和拓扑分布约束在集群联邦里是必须做的事而不是可选优化项。最有效的做法是在部署模板里明确标注每个工作负载的“必须本集群”“优先本集群”“任意集群”三种调度级别从源头杜绝这类问题。最后再聊一点个人体会。混合云架构看上去是在解决技术问题但本质上是在帮企业建立一种“选择权”今天可以用A云明天可以用B云核心业务可以留在私有环境弹性部分随时借助公有云扩展。这个选择权需要付出不小的复杂度代价它不会让架构变简单但会让架构变得更稳、更灵活。搞这一块没有捷径扎实的网络底子、明确的数据边界、统一的管理平台缺一不可。希望这篇内容能帮你少走一些弯路。
