← 返回概念辨析

Concept Contrast Fable

本地化部署和云原生

一个把系统搬进了客户的机房,一个把系统从底层就设计成只在云上活得最好。选本地化部署不等于跟云原生对着干,但把本地化部署的系统硬当成云原生的来运维,账单和故障率会一起往上走。

寓言

搬进院子里的机器和长在院子里的大树

青云车行原本在大驿道旁开总铺。车马、修轮匠、草料仓和调度牌都在一处,哪辆车空了,掌柜一翻牌就能派去下一站。遇到雨天,邻县的棚子也能临时借用,整条驿道像一张会调度的网。

后来有个矿场说,货物贵重,路线保密,希望车行把一套车马和修理棚搬进矿场院子。掌柜觉得只是换个地方摆放,便照总铺样子搬了一份进去。

头几个月很顺。矿场安心,外人进不来,账也在院里查。可旺季来了,院内马不够,不能随便借总铺空车;修轮匠病了,也不能马上调邻县师傅。院子安全,却少了大驿道的弹性。

掌柜先往院里再塞更多马、更多草料、更多备件。成本很快上升,闲时又浪费。矿场管事才意识到,搬进院子不是把总铺缩小复制,而是选择把控制权、隔离性和运维责任留在本地。

总铺那边也不是简单省心。它依赖统一调度、持续改造、按需扩张和跨站复用;一处升级能惠及多地,一处故障也可能影响更广。两种方式各有代价。

后来车行签约前先问:客户要的是院内可控、数据不出门、独立维护,还是要快速扩张、统一更新和弹性调度。一个像把机器搬进院子,一个像把业务长在大驿道上,选错了就会把安全、成本和速度全算错。

矿场后来接受了院内车队,但合同写得更清楚:哪些维护由车行派人,哪些备件留在本地,何时能向总铺求援,升级要不要先经过矿场许可。独立带来自主,也带来更多本地责任。

总铺客户则选择另一种承诺:他们愿意让车行统一管理车马和路线,换取更快扩张、更低闲置和持续更新。掌柜从此不再把两种方案包装成地点差异,而是把控制、弹性、成本和责任摊开给客户选。后来车行报价时不再只写“放在你院里”或“放在总铺”。它把隔离、升级、调度、备援、维护人手逐项列出。客户看懂这些,才知道自己买的是哪种运行方式。

本地化部署

将软件系统安装和运行在客户自己的物理服务器、私有数据中心或指定基础设施上,数据不出客户控制范围。运维责任(硬件、网络、备份、灾备)由客户自行承担或与服务商协商分担。

云原生

一种从设计阶段就假定运行环境为云平台的应用架构范式,核心特征包括容器化、微服务、声明式 API、弹性伸缩和依赖云托管服务。它在云上运行效率最高,迁移到非云环境需要大量的架构适配。

故事对应

  • 云上统一的节点规格在客户机房不存在:云原生的调度策略依赖云环境的基础设施假设。
  • 健康检查超时从五秒调到二十秒:本地化部署需要重新适配所有云原生预设参数。
  • 自动伸缩关掉改成固定实例数:云原生依赖的弹性基础设施在本地化环境中不存在。
  • 运维成本对比表:云环境替你做的事在本地化部署中全部变成了人工运维成本。
  • 移栽大树需重新配土、调整浇水:云原生产品搬到本地化部署并非搬家,关键在于移栽。

落到项目里

售前阶段把「部署方式」和「运维模式」分成两个独立评估维度。部署方式决定数据在哪、谁管硬件;运维模式决定日常巡检、扩容、故障恢复由谁执行、按什么 SLA 运行。云原生产品做本地化部署时,合同里附一份「云环境替代方案清单」,逐条列出云原来自动做的事情在本地化部署中如何实现、谁负责。这张清单比单纯标注「支持本地部署」有效得多。