前端系统服务迁移方案
背景
由于公司内部架构调整，原来负责的业务由横向支撑，闭环到了业务部门。人员也跟着到了业务部门下，所以需要对原项目进行跨部门迁移。
主要从以下几点考量迁移的必要性：(涉及到具体业务用A、B指代，A业务代表我负责的业务，B业务为其他业务)
-
影响范围&稳定性：项目原架构为monorepo，其他包的改动会影响到我们业务子包的部署上线，可能会带来潜在的第三方线上问题。且B业务回滚可能会影响到A业务。
- 其他业务耦合：B业务代码和我们业务代码走同一条流水线打包部署，耦合性较高，且B业务代码目前全部是外包维护，质量较差，会影响到我们业务前端的稳定性
-
流程&人力&效率：由于组件架构调整，目前上线还要依赖原团队oncall审批，原团队无法随时抽调人力对商业化项目进行CR/发版/上线，效率低且可控性差。
-
无代码合并权限：原上线部署流程是oncall人员轮班制度，oncall需要申请权限，负责原仓库的所有业务的代码合并发版上线回滚操作，合并需要在oncall群统一艾特相关人员留存记录，合并权限一周后回收。目前脱离原组织架构，无法继续走oncall轮班，只能依赖原部门前端。
image-20231121152010564.png- oncall人力无法随时抽调：日常发版走定时班车制，无法随时match商业化后端部署节奏。紧急上线回滚时，无法随时抽调原团队人力支持A业务项目的发版/上线/回滚。
-
框架基建：修改框架基建会影响到其他不属于A业务的子包，需要推动原团队前端进行修改和review
-
机器资源：机器资源归属于原团队，目前和B业务共用同一台机器发版，资源不可控
- 原流水线和容器中，包含了其他业务线的业务，需要拆包部署隔离
一、调研
迁移内容：项目中原架构为monorepo架构，本次迁移涉及到A1业务子包、A2业务子包。（A1、A2均为我负责的业务）
时间deadline：最多一个月时间，排期紧张。
1、可行性
由于本次迁移涉及范围是两个部门之间，涉及到跨部门，所以需要和原部门确认该业务子包是否可迁出，流水线是否可迁出，可以迁出那机器的配置和容灾情况要怎么配，迁出以后是否会有风险。
流程是否可迁移：复制流水线
容器是否可迁移：生产环境容器需要1C2G，测试环境需要0.5C1G
代码是否可迁移：可以，克隆原仓库
2、难点
本次迁移时间紧急，到deadline只有一个月，期间需要保障业务研发稳定推进，还要保障迁移有序进行。实操时间可能不到一周，需要对整体节奏规划清楚，面临的挑战主要有：
项目代码复杂：相互依赖较多，其他业务的包也耦合其中，需要剔除。
功能验证复杂：涉及海量页面，测试无法覆盖到所有页面。
稳定性保障：新旧项目需要完全隔离，互不影响。
机器资源：之前没有做过机器相关的工作；机器资源需要申请，配置也需要同步。
域名流量切换：切换流量需要做到用户无感，且不出故障。
代码迁移同步：代码迁移需要做到和源仓库完全同步，保障正在开发中的需求不受影响。
3、如何度量迁移成果
迁移过程中上线0故障
影响范围缩小到0：原团队和A业务发版上线隔离，不会出现公共包部署带来的潜在第三方问题
流程闭环效率提升：A业务项目发版上线，不依赖其他团队，可以内部独立上线&回滚，效率提升，可随时match我们部门前后端节奏发版，遇到问题回滚更迅速，更加可控
机器资源闭环：前端部署的容器资源迁移到A业务团队下，不受原团队缩减机器成本影响
二、实施
盘点机器资源，申请迁移所需的机器资源
新建流水线，将原代码仓库部署到新staging容器上，并将staging流量打到新staging容器，稳定运行一段时间
将原代码仓库部署到新prod容器上，通过测试路由将流量打到新prod容器上，稳定运行一段时间
新建代码仓库，迁移原代码，并接入新流水线，打通新staging和新prod容器的流量，通过测试路由进行放量测试
将线上路由打通到新prod容器，进行灰度测试，稳定运行后切掉旧机器流量，全部迁移到新容器
1、迁移功能盘点
域名流量迁移
保持原path不变，公司内部网关代理流量迁移（提供反向代理、访问控制、HTTPS 等功能，为接入的 Web 应用提供安全防护，所有 Web 服务部署在改服务的后方。）。
-
机器迁移
盘点机器资源
配置复制原有配置
将打包内容部署到新机器上
流量切换
容灾策略
稳定性保障
-
流程迁移
流水线复制
代码合并权限
上线通知机器人迁移
-
代码迁移
仓库代码迁移
代码同步源仓库
2、设定里程碑
时间点进行脱敏处理，大概看下就行。
2023/0x/xx 盘点机器资源
2023/0x/xx 方案实施调研
2023/0x/xx 方案细化设计
2023/0x/xx 创建流水线
2023/0x/xx 部署到公司的静态容器
2023/0x/xx 部署到测试环境，staging上可访问到新容器
2023/0x/xx 功能验证
（x月）容灾策略制定
（x月）灰度流量切换
（x月）稳定性保障
（x月）持续观测无问题
（x月底）完成
3、迁移
创建静态容器部署服务
流水线创建
关联静态部署服务和流水线
创建路由path
-
使用代理服务器的路由测试是否可以正常访问，正常会跨域，服务跑不通，只要check静态资源加载正常就好。
- 例如代理路由为 xiaoqingwa.proxy.com/frontend/index.html
-
通过代理工具（例如whistle）配置本地代理，将线上真实staging环境代理到测试的域名上，使用真实staging路由访问，可以正常访问。并且加载的资源也是静态部署容器的
- 举例：线上staging环境域名为 staging.kuaishou.com/frontend/index.html，我们部署的服务为xiaoqingwa.proxy.com/frontend/index.html，通过whistle配置
staging.kuaishou.com/frontend/index.html xiaoqingwa.proxy.com/frontend/index.html这样就可以通过正式staging域名访问到我们部署的服务进行测试了，可以通过静态资源返回Header判断是否是新容器。image-20231121154048590.png
image-20231121154116806.png
- 举例：线上staging环境域名为 staging.kuaishou.com/frontend/index.html，我们部署的服务为xiaoqingwa.proxy.com/frontend/index.html，通过whistle配置
-
到目前为止，测试代理路由是成功的，我们就可以着手切线上流量了。
- 到公司内网网关根据不同的路径匹配规则配置对应接口流量转发到新的容器即可。
image-20231121154405377.png
image-20231121154428538.png
进行功能验证、权限验证没问题
beta环境迁移同上，不赘述了
生产环境迁移
生产环境目前有五条线路，我们就叫p1,p2,p3,p4,p5。只有p5是走网关代理配置，p1-p4走的是Nginx配置
列迁移计划
可以现在p5切流测试，生产环境灰度发布，渐进式迁移
升级回滚方案需要制定，保障业务不出问题
上线Nginx方案待学习
迁移admin.p5 （这里不赘述了，和staging，beta环境一模一样）
迁移p1-p4
**TODO**
4、功能验证
staging 验证完成
beta 验证完成
prod 待验证 p5验证完成，p1-p4待验证
5、稳定性保障
需要制定容灾回滚策略，才可以部署生产环境，流程如下：
具体细节：
流量切回旧容器：生产环境除了p5走ap以外，p1-p4域名都是走的Nginx，需要Nginx配置回滚。上线前要明确回滚操作，找到对应接口人辅助，切忌盲目上线无法回滚。
三、总结
迁移之前想清楚为什么要迁移，迁移的计划要列出来，制定里程碑
迁移中每一步都要做好planB，避免系统损失。尽可能在每一步操作前都可以通过一些特定的方法进行线下验证再切换到线上，把控风险。
迁移后要oncall进行观察功能
做好这三点，系统迁移基本上可以稳定进行。
