高可用浅谈

不同IDC或者数据中心，对每个系统一般都会进行灾备等级划分，除了考虑平台不一样（主机或者开放平台，不过dvops或者各种云设施把这种变成了'不同服务要求），也会考虑产品线的特点，如影响用户，影响的关键交易，是否基础或者骨干支撑平台等。根据灾备等级不同，从两地三中心（最早交行的这个方案，倒是把其他机构科技搞郁闷了，硬生生的出来这么麻烦的工作）的集群到同个IDC、同城的主备切换，会有各种不同的方案。

基础设施这块，主要解决周边环境如电力公网，内网相关设备的HA，这块最重要，可选方案也很多，但是却由于设备大量铺开，基数一大，再加涉及厂商较多，一般一年有个3次左右的区域设备故障，最可怕的那种像DNS服务的设备或者防火墙设备性能故障甚至宕机，导致各种涉及DNS的jdbc连接等应用场景连锁缓慢到宕机。（多个IDC之间不得不考虑距离带来的问题，光速终究有限）

操作系统到中间件，不得不提数据库，ORACLE的RAC+DADAGRAUD基本构成了标配，不过由于性能和改造量的缘故（特别是大量存储过程导致分库分表麻烦），基本不同的RAC节点都是根据交易分组，没有做负载。至于应用服务器，websphere的集群已经比较成熟，但是比较奇怪的是IHS+Was这么经典的方案，实施过程中IHS经常只是作为WAS的反向代理，负载特性倒是鲜见，一旦故障，则需要人工接入。可见不管是4层负载或者其他方案，应用程序跟不上也枉然（当然也有业务特性历史遗留吧）

对于应用系统，交易无状态的比较容易实施集群，但是对于交易系统等有状态的场景（很多交易所的系统鲜见集群服务，自动负载）却大部分采用或者大部分模块采用主备切换。关于主备切换，rto不同，成本和效果也不同。zookeeper的方案应用比较多，但是2N+1的部署特性以及其他过重的做法有时候也不是很适用。

最后，搞双活或者多活这种不能弹性伸缩的都是土豪。