可以尝试考虑做云平台的双活，也就是做多个云平台，互备。

建议采用新旧系统并存方式，新系统为容器化，逐步将相关业务的消息发到新的系统，实现新旧系统替换。

在做这件整合这件事情之前，要清楚主要是为了什么，再此基础上做平衡，就会找到突破点。有的公司实例太多，服务器太多，维护人员少，运维工作繁杂效率低，  这时管理成本、硬件成本或者机房基础环境就是是公司运维工作的主要问题，那么这时整合就是一个好的途径，来解决这类主要问题；但是...

这个问题信息量比较大，同城双活或同城、异地多活甚至目前跨云的多活都是大家所关注的话题。微服务的定义就是服务独立化、动态扩容等一些优点,所以从微服务角度看并不关注多活，双活，只要服务能正常允许即可。但是从架构角度来看，如需要支持多活，双活，那么一些基础设施是否具备...

存储双活只是双活业务的一个必要条件，还需要实现应用集群双活，网络双活，数据库双活等才能真正去做到业务的连续性

在目前的灾备架构中，主要实现的是应用双活、存储双活，数据库双活还处于探索阶段。所以灾备的业务连续性是需要通过数据库的切换来实现的。在灾备管理方面，主要需要保证应用双活与存储双活，本身不需要做相关的切换动作。灾备切换过程主要在数据库主机层面，需要停止生产数据库，卸...

传统存储数据迁移至闪存有如下四种方案：（1）操作系统层数据镜像方案如 AIX LVM，步骤如下：•映射闪存阵列的 LUN 至 AIX OS，并加入 VG。•将原传统阵列 LUN 和闪存阵列 LUN 做 LVM。•同步完成后，找停机窗口，从 VG 中拆除镜像，剔除原传统阵列 LUN。•重新激活 VG，并挂载数据文件系统，...

如果是power架构，可以使用mksysb备份恢复的方案。

我理解你指的大并发是业务层面的大并发。可以通过前端软件或硬件的负载均衡算法将业务分发到后端集群中的不同的服务器中，首先保障分发层面的自动均衡。后端数据库服务器可以集群部署，无论是商业数据库ORACLE RAC、DB2 Purescale 或者开源分布式数据库，都有多个节点保障数据...

理论上可以支持，通过服务化技术，新的服务上线替代老的服务，滚动升级.这就要求控制器支持服务化的架构。