所谓双活数据中心的架构
我认为有数据中心级别的双活、应用级别的双活、业务级别的双活之分。
1）数据中心级别的双活，相对容易实现，只要不同的业务跑在不同的数据中心就可以了。
2）应用级别的双活，只要业务能读写分离，同样的业务系统，写操作单中心做，读操作双数据中心做，需要应用系统的高度逻辑隔离。
3）业务级别的双活，就是指同一笔业务既可以在A中心写入，也可以在B中心写入。这种双活就相对困难了。
对于业务级别的双活来讲，他的关键制约条件是什么呢？我们从上到下来看：
网络层面，双数据中心2层打通，GTM+LTM很容易做到分流控制。
应用层面，只要是短连接应用，挂载负载均衡设备上，无论是虚拟化还是实体机，也非常容易做到。
数据层面，要完成三个功能：一是两边都能写入，而是两边都要保留数据的副本，三是两边的数据库节点能快速接管彼此的业务。那就是数据库AA集群+数据复制技术。首先来看AA集群技术，典型的ORACLE RAC，可是有一个致命的问题是关系型数据库的AA集群会有数据热点问题，在双中心之间的链路延时和不稳定情况下，这么做是非常危险的，不出问题是侥幸，出问题是时间的问题。再说数据复制技术，存储层面的复制技术有很多，但是没有一个能解决逻辑校验的，也就是说存储的块数据同步过去了，但是有可能在危急时刻，数据库还是拉不起来。而且还有一个关键问题就是数据库的仲裁和存储的仲裁再加上光纤链路的远距离不可控，危急时刻做出正确的仲裁，很难。不要简单听信仲裁时间的先后以及第三点仲裁中心的说法，那是理论上不是实践。血淋淋的案例摆在面前。再看数据库层面的复制技术，典型的就是ADG，现在做的也是越来越好了，只要日志复制过去，那就不会有数据丢失的危险，但是这个ADG切换就不是1分两分钟能搞定的事情了。
因此我认为，在既有关系型数据库的前提下，双活最稳妥的做法就是：
网络层： 大二层、GTM
应用层：虚拟化 + LTM
数据层：单中心集群数据库 + 数据库复制技术
管理层：开发脚本减少切换浪费掉不必要的时间
收起