目标要求

一个机房断网、断电的情况下能够在5-30分钟完成A机房到B机房切换。

架构——所有的流量放到机房机入口上，页面的流量、OPENAPI的流量、Web类的流量统一接入，其实是一个Proxy。
把没有办法进入前端的域名通过TTL，全网的更新时间不能超过5分钟。

中间件—— 三机房部署，或者双机房部署。 HFS开启本机房优先。 双机房双集群或者双机房单集群。

数据层(数据库) —— RDS多AZ，三AZ，一个机房有2-3个AZ的副本。 双机房主备模式。

设计的为双活的概念

双机房流量水位控制在50%就可以了。

架构设计

用户的流量要上提一层，统一通过vipserver分流。

统一接入之后，统一接入画了一层，但是同样还是在两个机房有两套。

所有的流量通过统一接入层，再转发到其他机器上。VIPServer是一个统一发现的东西，流量接入根据设计的规则去A机房或者B机房。

流量由统一接入层向两个机房来分配，可以根据每个机房服务器或者可承载的量来进行流量分配的比例。

RPC调用，注册发现模式，是注册到注册中心，由注册中心告诉服务消费者服务在哪里。所以RPC不适合放在统一接入，单独为RPC做了两个vip ，分在不同的机房。服务发现的时候是直接读域名。通过ADNS智能解析，在DNS层自动把死掉的IP给摘掉。

web 层、中间件层、数据库层。 三层

双机房双集群，如果对于业务的一致性比较高的，需要自己设计数据的一致性情况。

选择双机房单集群需要忍受数据的丢失。 因为挂掉之后数据会丢失一半。

队列服务是不允许数据丢失的——都使用双master架构，保证消息队列能够平稳正常的运行。

任务分解

系统梳理——到底有哪些系统需要做双机容灾
资源申请——服务器申请、域名申请、人的申请（到底要多少团队对少人投入）
风险评估——风险在哪里
工具支撑——
容灾演练——通过容灾演练来判断容灾是否完成。如果没有完成需要评估中间有哪些需要改进的。

分不同的级别，先找出必须要做的。

演练

是一个长期的过程，随着某些业务的变化，演练结果也有可能变化。

做完了只是一个开始，容灾的架构要跟随这个业务系统的变化而变化。