曾几何时，由国有五大行为代表的两地三中心的容灾架构是业界的高配和主流容灾架构方案。国内有些证券或保险公司即使做不到生产中心和灾备中心的1:1配置，也会基本保有其核心业务应用容灾切换的能力，公司治理层面要求定期做灾备演练。按照银监会和保监会的治理要求，金融公司要确保一年做一次整体或局部系统的容灾切换，这是销售金融及衍生产品的公司持续持有金融牌照所必须要履行的责任和义务，这也是必要的国家对金融类公司的合规性要求。

      目前很多银行或券商正在尝试如阿里云等云平台的容灾方案。在云环境的容灾如何做，这将成为很多公司或组织的IT部门所需考虑的全新课题。我们都知道容灾一般可以分为同城容灾和异地（城市）容灾。传统容灾方案是在同城或异地各建立一个与生产中心同等规模的灾备中心，并且生产中中心至少有两套一模一样的IT系统架构，保证在生产中心的一套IT系统全瘫痪的情况下，在同一个生产中心还可以有另一套同样规模的IT系统架构可以支撑业务的持续运行。在生产中心乃至不同灾备中心之间都部署了相同的应用和IT基础设施支撑能力，并通过在不同数据中心的高端存储之间的同步或异步复制的能力来确保跨数据中心的相同业务应用的数据一致性。

  那么如果业务应用上云后，云上的容灾方案会有何种改变呢？我们且从如下两种典型的方案来分别论述：

     1、云一般可以支持同城多可用区(AZ)的容灾方案，这里的可用区是指物理上有独立网络接入、电源、空调和机架的数据中心。如果在同一朵云上的两个可用区分别承载着基于负载均衡(F5（硬负载）或SLB（软负载））访问的具备分布式架构的应用，并且数据库采取如OceanDB或RDS这样支持分布式架构的云数据库。云上应用的同城容灾将变得非常简单，只要依靠单个云本身的分布式存储能力以及存储、中间件和数据库级别的同步复制能力就可以轻松实现同城的容灾。云上容灾的架构图如下图所示：

   2、云上的异地容灾相对来说就比较复杂，一般分为同云多Region(城市）和不同云多Region的方案。在同云多Region的方案中，一般建议的是不同Region(城市）​的距离最好小于200公里，这更多的是对应用所需数据的一致性和应用自身访问性能考虑的。异地数据中心如果相距小于200公里，这对很多银行类客户来说是不可以接受的，因为银行的生产中心和灾备中心的距离要求一般要达到500公里以上并且不同数据中心应在不同的地震带上，以保证业务的连续性和用户访问流量的就近接入等实际业务诉求。例如，中国银行的生产中心在北京，异地的灾备中心在上海，北京和上海相距500公里以上。如果客户上云，可能在异地灾备中心部署的云与生产中心不是同一个厂家的云。例如，生产中心选取的是阿里云，灾备中心选取的是华为云。这样就需要考虑更多复杂的实际问题以及方案落地实现的可能性。

总之，云平台厂商都在致力于异地容灾的白屏化能力，比如可以通过容灾项目的实施步骤，利用云厂商提供白屏化的管理界面，选择指定业务应用级、可用区（独立的数据中心或机房）级和Region(城市）级的切换，使灾备演练和容灾切换变成一种可灰度、可监控和可回滚的低风险的操作。由于业务连续性的诉求，城市或数据中心级的容灾技术需要持续的改进和提到，大家都在持续努力的路上。