某客户云上迁移实践

编程架构

字数统计: 2.4k阅读时长: 8 min

 2025/03/02   Share

前言

本文详细阐述某企业遗留系统云端迁移的技术实现过程，文中不涉及敏感信息与可视化资料，仅作技术方案参考。

背景

某企业客户部署的n台经典网络实例需实施跨可用区迁移，客户技术团队在2024年度三次自主迁移尝试均告失败。该业务系统自201x年上线以来累计服务千万级活跃用户，每周三至周日高峰时段并发用户达数十万量级。系统架构包含18台ECS+x个RDS-MySQL+x个Redis+x个MongoDB+x个RabbitMQ的复杂组合。

由于系统历经多次技术团队更迭，现存系统存在三大核心痛点：

源代码及部署文档遗失
服务调用关系不明晰
关键组件单点部署风险
日常运维仅能维持基础功能运行（曾出现服务器重启导致部分业务模块失效的情况）。客户原定2025年2月启动系统重构计划，但因业务连续性要求无法等待，故紧急启动迁移项目。在获得有限权限（控制台只读账号+OS级访问）后，技术团队通过逆向工程完成架构梳理并制定迁移方案。

网络拓扑现状

现网环境分析

客户现有两个VPC网络：

业务VPC：172.16.0.0/16
迁移专用VPC：10.0.0.0/8
三台经典网络实例（10.25.63.135、10.27.10.158、10.29.112.12）需保持与业务VPC互通。

技术障碍突破

检测发现存在Classlink配置冲突问题：若保留经典网络连接通道，将导致其他ECS无法通过迁移计划进行迁移，影响迁移前后服务的互通。通过为期7天的流量捕获分析：

2台实例无业务流量交互
1台实例仅存在TCP握手空连接
进一步端口扫描确认该流量源于业务VPC访问废弃Nginx端口，故所有Classlink均可安全拆除。

业务系统剖析

服务组成

Windows集群（4节点）：具备完整文档，独立迁移
Linux集群（14节点）：承载核心业务，无部署文档

技术栈特征

应用层：SpringBoot+SpringCloud单体架构，无CI/CD流程
中间件：自建ZK集群+单节点Memcache/MySQL/Nginx/Apollo
云服务：混合使用RDS/Redis等托管服务
历史债务：大量硬编码数据库连接（IP/域名）、公网IP监听等技术债

迁移实践

采用分批次渐进式迁移策略，每周一二低峰时段迁移2-3台实例，整体方案分为网络重构、数据库迁移、应用迁移三阶段实施。

网络架构改造

解除无效Classlink连接
创建跨VPC对等连接满足跳板机需求
在迁移VPC中规划与原有ECS网段不重叠的24位子网
将业务VPC与迁移VPC的路由配置完成。

数据库迁移

经典网络数据库迁移至VPC网络的实施流程主要包含两个核心环节，每个环节均需通过控制台可视化操作完成且业务无感。具体实施规范如下：

1.安全组变更。

执行安全组规则分离操作，实现经典网络与VPC网络的白名单隔离管理。系统会自动将原经典网络已授权的IP地址段同步至VPC白名单策略组。特别建议在VPC白名单中预置10.0.0.0/8全量地址段，该配置前瞻性解决后续网络架构中网络负载均衡（NLB）组件采用FULLNAT模式时，可能因源地址转换导致真实客户端IP被过滤的问题，确保业务流量无阻断风险。

2.开启临时混访。

网络类型切换时需勾选”保留经典网络地址”选项，该操作将生成专属于VPC网络的访问终端节点，形成经典网络与VPC网络双地址并存的混合访问模式。若未保留经典地址，将直接导致未迁移业务系统失联。

网络切换完成后，需选取任意业务ECS实例执行网络诊断：分别对经典网络连接地址和VPC连接地址执行dig命令解析，完整记录两个终端对应的实际IP地址。此操作获取的IP映射关系，为后续解决应用程序硬编码连接地址的改造工作提供基础数据支撑，确保业务平滑迁移过渡。

dig classic-db.example.com +short
10.141.20.223
dig vpc-db.example.com +short
10.1.0.79

应用迁移攻坚

ECS迁移应用上发现有3个已知问题，分别为写死固定字符串连接、写死数据库固定IP、写死公网IP监听，针对这3个问题分别制定了3种应对策略，在ECS迁移启动后首先完成这3类问题处理，然后再进行后续程序启动

技术债务应对方案

问题类型	解决方案	技术实现
域名依赖	Hosts劫持	建立域名-专网IP映射表
IP直连	NLB代理	创建IP保留型网络负载均衡
公网绑定	双网卡路由	EIP+辅助网卡绑定

1.域名硬编码连接优化

问题特征：应用程序采用硬编码数据库域名连接方式，但实际存在不可变连接字符串约束

技术方案：

建立全网域名-IP映射表：系统化梳理所有RDS实例的经典网络域名与专有网络IP对应关系
实施本地DNS覆盖：通过修改ECS实例的/etc/hosts文件，建立”经典域名→专有IP”的静态解析规则，保持应用层代码零改造
设计过渡期运维机制：针对数据库跨可用区迁移导致的IP变更风险，建立人工巡检与hosts文件更新流程。同步规划系统重构计划，要求新建ECS必须采用动态域名解析标准方案

1 2	经典架构：应用代码-> 经典域名 -> 经典IP(10.172.X.X) 过渡架构：应用代码-> 经典域名 -> hosts解析 -> 专有IP(10.X.X.X)

2.IP直连架构改造

问题特征：应用程序直接硬编码数据库IP地址，无法通过常规DNS方案解决

创新方案：

构建NLB代理层：通过OpenAPI创建指定保留IP的NLB实例，严格保持原应用配置的IP地址不变
配置透明转发规则：建立NLB监听器与RDS专有网络IP的绑定关系，白名单放通NLB固定出口IP
实现流量无损切换：业务流量经NLB全量转发至新数据库节点，网络拓扑变更对应用完全透明

1 2	传统架构：ECS -> RDS(10.172.X.X) 迁移架构：ECS -> NLB(10.172.X.X) -> RDS(10.X.X.X)

3. 公网IP绑定重构

问题特征：应用代码写死监听公网IP地址，在ECS迁移到VPC网络后，eth1公网网卡将会被删除，原公网IP将映射到内网eth0网卡，不在直接在系统内显示。应用不能监听公网IP，需要修改为监听内网IP。目前应用已不具备能力修改，需要使用其他方案解决此问题。

改造方案：

公网IP弹性化改造：将原有固定公网IP转换为弹性公网IP(EIP)
辅助网卡部署：为ECS挂载第二块虚拟网卡，采用”EIP直通绑定”模式实现公网IP可视化
智能路由配置：精细化定义双网卡路由策略
- eth0(主网卡)：承载10.0.0.0/8及172.16.0.0/16内网流量
- eth1(辅助网卡)：配置默认路由，处理公网出入流量

4.应用启动

实施规范：

分级启动机制：
- 基础层：优先启动Nginx、Redis等开源中间件，完成健康状态校验
- 支撑层：依次启动基础服务、核心组件、API网关
- 业务层：最终启动控制台等前端服务
立体化排障体系：
- 有日志服务：实时监控error级别日志，结合代码反编译精准定位异常
- 无日志服务：采用tcpdump抓包分析+strace系统调用追踪的复合诊断模式
- 业务验证：完整执行核心功能测试用例，数据一致性校验通过率需达100%
观测期管理：
- 建立3小时黄金观察期，监控QPS、错误率、响应延时等12项核心指标
- 配置业务流量灰度放量机制，按10%、30%、50%、100%阶梯递增
- 达成零客户投诉且系统指标平稳运行后，方可启动下一节点迁移