数字化转型的云迁移之路，永辉超市历时2年的经验总结 | ArchSummit

作者 |  李忠良

数字化转型并非一蹴而就的事情，对于企业来说，它是一场马拉松，而在这场竞赛中，很多前行者的经验值得借鉴。为了让大家对数字化转型有更多的了解，我们邀请了永辉超市高级架构师张明来为大家分享永辉超市的混合云建设与运维，在正式分享前，我们采访了张明，本文为其采访整理，期待对你有所启发。  

InfoQ：我们先从您目前正在做的事聊起， 您目前主要负责什么呢？

张明：我近期主要负责参与混合云建设的方案制定与落地推动。

比如，升级私有云机房基础设施架构。为了使私有云上的资源容量可满足增量需求、且持续稳定地提供优质服务，需要持续不断地利用科学的技术能力进行提效降本。

同时打通与公有云的通讯、接入弹性计算能力、相关云组件 / 云能力、自建 DevOps 的多云支撑等也是目前很重要的一部分工作。

当然在升级过程中也是需要结合业务实际部署与用量情况，选择高性价比、技术成熟、且适应自身系统生态的组件进行升级接入。

当然，还有一件很重要的事——推进多数据中心间的应用多活。

我们的系统要做到 7x24 不间断的提供服务，在私有云与公有云的交互、网络组件安全、业务流量出入口、应用计算节点、中间件、数据库、基础设施等方面都有需要针对性地改造，改造升级后通过故障的演练来验证多活的有效性，保障在 Iaas 出现不可控故障中，服务仍能正常为线上 App 与线下门店系统提供服务。

InfoQ：在您看来，是什么样的考量让永辉决定进行云迁移？

张明：从 2020 年下半年开始，永辉云创新零售的系统与永辉超市集团的供应链系统不断融合，高速推进永辉集团的数字化转型。在业务系统全链路融合打通的过程中，系统间交互逐渐频繁起来，同时系统对于基础设施架构的要求越来越高。

永辉云创的新零售系统，从 2015 年在北京的 UCLOUD 公有云机房，而永辉超市集团的核心机房分布在上海的腾讯 TCE 机房与福州自建 IDC。

所以在永辉集团这样复杂的多云多地，且流量跨华北、华东、华南多地域的 IT 架构下，C 端的交易链路、履约链路、B 端的供应链链路等核心链路在融合过程中产生大量跨地域请求，当存在循环调用时，链路延迟要求我们不得不进行技术改造。

而且由于是多云架构，跨地域机房 VPC 划分最早也是没有合理规划，存在内网 IP 冲突需 NAT 转换才可互通，通讯层面难度加大，同时业务系统在使用远距离对等连接专线中质量稳定性问题不断浮现、运维需要基于多套云接口完善自身 DevOps 系统，兼容多云环境，在这样跨地域架构恶劣的情况下，很多底层运维的工作量是双倍甚至三倍更多，难以高效完成数字化转型过程中的业务融合改造。

2021 年初，永辉高层为了提升数字化转型的效率与速度、为了提升系统链路响应质量、缩减多云架构下的基建成本开销，让业务链路可在同城闭环的混合云架构升级提上了议程，同时年初将 UCLOUD 上所有资源全量迁移至腾讯 TCE 上海机房的云迁移项目也立项了。

InfoQ：云迁移过程肯定不是一蹴而就的，可否按阶段来分享一下？

张明：我完整地负责与经历了整个云迁移的过程，最关键的阶段其实也就是半年左右，大致可以拆解为下面七个部分：

1. 评估迁移必要性。很多事情可能是真的是要做了才知道会遇到什么问题。 永辉系统集成过程中浮现出大量的框架不同、SDK 组件用法不同等技术栈不一致的情况，导致研发效率低下。 同时微服务 RPC 请求跨机房、MQ 消息订阅跨地域、异地部署多套 CICD 系统、基建监控系统有多套，这些各类系统层面阻塞数字化进程的问题逐渐暴露。而遇到的问题是不是可以通过云迁移才能解决，还需要带动大家一起通过评审来得到答案。
2. 方案成本预估。服务容器、中间件、数据库、大数据、基础设施等各关键团队都是要给出预估的资源需求的，当然我们是需要多估一点的，要把业务的增量考虑进去。最后将这些估出的资源列表与估算的机房内单核成本联动，计算产出一份迁移成本预估报告。
3. 高层决策迁移。当然收集必要信息，把数据都透明化，能有条理的解释数据的能力是相当重要的。比如迁移前 / 迁移后的成本，云平台的能力比较，业务稳定性指标预估、技术改造后的预期效果等都需要展示出来。最后还是让高层在足够清晰数据的情况下进行最后决策拍板。
4. 招标采购上架。基于成本预估，匹配机种，与相关人员确定完硬件规格后，迎来的就是数月漫长的采购与上架流程。与此同时，我们利用这个空档将腾讯 TCE、腾讯公有云、永辉内部的团队的合作方式与工作目标都明确下来了，在这个档期内扫除所有已知技术问题。
5. 输出整体方案。多云的基础设施、数据库、中间件、容器平台、DevOps 平台、APM 系统、大数据系统等等各个领域都有各自分工产出迁移方案。作为迁移负责人，协助大家在有限时间攻克疑难问题，将零碎的技术点整合成完整的迁移方案。基于完整方案，排出相关里程碑与迁移时间轴，获得团队的统一认可，最后将方案清晰地公示到整个研发团队。
6. 迁移部署割接。我们的目的是希望系统在不宕机的前提下进行无感迁移。永辉在迁移过程中的目标云的部署持续了有 5～6 周左右，通过灰度框架的铺开实施，部署期间不断通过测试验证部署的可靠性，不会对生产环境造成影响。由于 C 端流量需要在同一机房闭环，流量割接时间点是选择在一周的最低峰期的 1:00 后日业务相对低峰的点进行的，几百名同事参与并看紧自己的负责模块，齐心协力进行问题排查，完成流量割接。
7. 系统磨合。当然要想迁移后的系统稳定运行，测试必不可少，通过各类测试可以更好地找到业务系统与基础设施的最优配置。第一：迁移前灰度测试 / 压力测试，通过数据保证整个团队有信心进行线上流量的割接；第二：割接后低峰期的冒烟功能测试全绿，保证迁移的成功且测试反馈割接无需回滚；第三：大促前的压力测试，数据证明新环境与升级后的架构是可以支撑线上流量的，将系统扩容到位；

永辉的云迁移是在 5 月底完成的，预留了 2 周左右时间为 618 大促磨合做了充分准备，通过团队不断优化相关系统用法与配置，永辉在 618 大促期间实现了系统 0 故障。

InfoQ：云平台选型是怎么考虑的？中间件团队、容器团队、基础架构团队在这个过程中做了哪些配合上的事情？

张明：永辉是自建与腾讯深度合作的 TCE 私有云机房，是一套同城两中心的高可用机房，而且具有非常好的 BGP 多线网络接入条件，根据评估，将核心业务部署在私有云上是完全可以胜任目前云原生系统的生态需求与未来发展的。

当然要完成迁移，各个团队针对云平台的选型也是做了相关的妥协改造与变更。

基础架构团队：在专线建设、内网段规划、线下门店网络路由配置等方面要根据新的基础架构进行网络层面调整，对于机房内部的基础架构组件比如网关、负载、存储池、虚拟计算池都要进行对应的高可用建设。且上层平台团队在部署过程中遇到任何与云平台兼容性相关的问题，都需要积极主动跟踪处理。

容器团队：基于混合云的架构完成了 DevOps 系统的统一收口，集成混合云平台多 Kubernetes 容器接口的集成，使同一套编译的 CI 镜像可秒级部署至任意机房，将混合云的运维操作平台标准化了。基于混合云平台，可共用一套 HPA/VPA 的弹性体系，也是需要在自研系统上进行功能改造的。

当然微服务基础镜像也有针对云平台的系统进行吞吐量与网络相关优化，通过不断测试优化来提升底层框架的稳定性。将容器、服务框架两部分改动联动，可以很好地进行流量在混合云机房内的流转控制。

运维团队：在部署前需要进行流量网关的改造，保障部署实例可完成流量灰度隔离，与灰度测试的链路支撑。生产环境的迁移必须使用同等环境测试验证，然而生产环境上高峰期进行运维动作风险相当高，所以要保障有一个安全且不会影响真实用户的灰度环境相当重要。运维的任务相对比较重，除了高压力下的迁移部署外，对云上的资产盘点（包括各类系统、负载组件、安全组件、DevOps 系统等）都需要一一盘点进行文档梳理标记，明确方案，保障资源不掉队。

中间件与数据库团队：负责将主流中间件进行容器化改造并完成云原生化部署，包括 Redis、ES、MQ 等业务常用组件与 APM 系统相关组件的改造，保障相关中间件可高效在云环境内拉起集群，达到云原生化的运维状态。中间件与数据库的数据迁移是相当重要的部分，考虑迁移过程中的专线占用，迁移批次分布都要有数据支撑，而且要有严格的迁移方案评审与数据一致性校验来保障数据的安全。

InfoQ：永辉超市负责云迁移的团队有多少人？云迁移涉及哪些风险？

张明：云迁移可以说是一个研发团队全民参与的项目，在清晰战略的前提下，各个团队都有需要关注与配合里程碑产出的工作项目。在一个上百人虚拟团队规模性质、包括有多云公司三方人员协作、且割接时间节点要求苛刻的项目中，要保障系统可不宕机完成迁移，除了规避可预见、事后复盘得到可复用的技术风险外。将协作流程合理地公示给团队、清晰的设定里程碑等都可帮助项目降低风险。

要说到云迁移最大的风险可能就是割接时间点带来的，当要求在一个较短的时间内完成繁琐的准备工作与流量割接，步骤会更加复杂，仔细去看的话，会发现许多细分步骤下质量的风险都会凸显出来，所以迁移过程中的关键性决策还是需要是冒着风险进行实施的。

InfoQ：云迁移之后的运维保障是如何处理的？

张明：永辉的科技服务部门具备从客户端到 IT 系统、IT 系统到云基建，全链路的运维保障分工。在智能运维方面也自有主要链路上的相关运维系统，对混合云架构下的高效故障处理上是有一些自己的心得的。

在遵守故障定级、恢复时长的要求的前提下，运维团队可基于监控、实时流分析、DevOps 等效率工具高效拉动问题相关人员参与故障处理，在故障中将资损降至最低。

有无法快速定位问题的情况下，需要优先使用预定步骤止血，且第一时间引入云基础设施相关人员可大大缩短基础设施故障带来的故障恢复时间。

InfoQ：您认为传统企业进行数字化转型是否会面临同样的问题？有哪些问题可能是大家都要面对的？

张明：当传统业务具备一定规模，上云与迁云是传统企业避不开的一个高风险决策项，必须要熟悉业内最新发展，且结合自身特点，来完成云建设的决策。总的来说高层决策将决定高度，而团队人员的技术能力将决定达到这个高度需要的时间与投入。

嘉宾介绍：

张明：拥有 15 年以上从业经验，现任永辉超市科技服务部架构师，负责系统架构相关规划与实施，输出永辉数字化转型所需运维能力。曾就职于 TutorABC、微软等公司。在混合云架构、微服务 / 中间件、软件架构设计、APM 等领域具有丰富经验。

 活动推荐

在 12 月 26-27 日，ArchSummit 全球架构师峰会（北京站）即将落地北京，张明讲师将会分享永辉超市的混合云建设与运维，通过本次专题你将收获微服务、中间件、基础设施组件的大规模迁移方法，以及如何在混合云中建设高可用系统与运维应对方式，希望可以为正在进行云建设的你带来启发。

同时本次会议我们也配置了微服务治理之基础架构、微服务治理之业务架构、架构师成长、客户端架构设计、数据库与存储技术、云原生技术应用、质效度量体系和测试平台建设、低代码实践与应用、领域驱动设计方案落地、高并发架构设计等专题，届时欢迎你的参与。

点个在看少个 bug 👇