企业云平台的同城两中心迁移与并行，改如何考虑快速回退方案？

按照你的设计思路, 容器可多数据中心统一治理, 数据库使用云数据库, 没有区域概念
上层业务完全是 云化的, 中间件也是云化的, 数据库也是云化的, 没有 迁移的问题, 只有用户访问数量量分配的工作, 版本发布和回退都可进行部分或者全部回退,
但是这是不现实的, 如此复杂的技术在金融行业没哟先例 也没有成功经验, 即使阿里,京东也是数据中心基本的容灾, 业务处理大部分压力在银行系统,
以后金融监管进一步加强, 所有资金都必须经过银行或者银联,
完全容器化的业务模式, 需要时间进行考验,而且最大的竞争这 serverless技术也在发展,
有可能数据中心会直接过渡到serverless,
目前金融运维体系也不可能快速切换到以容器为基础的结构上,还是实际出发完成vm级别的运维,
容器可小规模进行测试.

迁移肯定是需要留迁移窗口时间的，并且需要做好回退方案，而且需要做沙盘推演，过程中如果失败怎么回退。这个是迁移的基本步骤和场景，如果是趁着迁移做一些升级或者改造，那就等于是说在新的环境下重新构建，只要关注数据迁移成功即可，这种情况多数可以提前做一些准备，只是等到数据就成功就进行切换即可。
迁移过程本身就要考虑这些意外情况，留足足够的窗口时间进行迁移，当然还有最坏情况就是迁移失败，终止本次迁移切换。
从个人经验来说，迁移最主要是考虑数据完整性，其它功能类的其实不迁移，重新搭建(尤其Docker)，从注册中心拉下来手工运行应都可以支撑业务 ～～～，所以不清楚您这边的迁移方案和过程中，是什么问题导致失败重来，能分享一下什么问题或出错现象等？而且一般这些不都是从注册中心进行迁移么？又不是从 node 点进行迁移吧。不知道我理解对不对？