| 知乎专栏 ｜ 多维度架构 |
本文从灾备角度出发，并不局限于灾备，而是从多维度让你看到完成灾备需要做哪些工作，解决哪些问题。
灾备不仅仅是运维的工作，一个完善的灾备系统需要多个部门的努力，网络拓扑需要做特别的调整，服务器需要特别的部署，软件方面需要配合灾备做特别的开发，才能满足灾备的需求，最终实现真正的7*24*365灾备，并且尽量做到无人值守故障转移。
随着各种金融交易的推出，金融市场必将非常活跃，交易量的快速增加对交易系统产生了更大的压力，如何使交易系统平稳运行，成为金融公司的头等大事。 随着客户风险意识的增强，保证关键核心业务系统持续成功运作的需要，将发生风险的损失降到最低，保证企业的核心竞争力，金融公司对交易系统的可靠性提出了更高的要求。 目前金融公司普遍安装了热备份系统，达到了一定程度上的备份，但无法应对整个机房或大楼的灾难事故，这就需要在异地建立一套金融交易系统，一旦主系统发生问题，且无法启动热备的情况下，马上切换到异地灾备系统进行交易。
与简单地将一部分数据从一台机器拷贝到另一台机器相比，企业内业务数据的复制要复杂的多。灾备系统必须满足以下所有业务需求：
传统的容灾方式
以上的容灾方案都显得过时，这些老旧的容灾方案依靠IOE(IBM，Oracle, EMC)提供的解决方案，IOE的方案通常是通用很强，你只能按照他们要求实施，IOE并不清楚我们的业务逻辑，所以方案不一定是最好的，另外一旦使用了IOE产品，就会被他们绑架，金钱投入无休止。
随着开源软件技术发展，IOE的产品优势越来越不明显，技术固步自封，影响到了用户甚至成为企业发展的瓶颈，IOE投资回报率没有性价比，不符合当下互联网时代。
系统灾难恢复有国际标准，我国也有自己的系统灾难恢复标准，一般分为六个等级，但我觉得都较为过时，不符合互联网时代 。
我国灾难恢复等级划分国信办文件 2005 “重要信息系统灾难恢复指南”
我认为等级划分应该为
灾难恢复等级划分
第一级：冷备份
第二级：双机热设备份（HA高可用, 通常为 Active Standby）
第三级：双活互备份（Active-Active 双机互备）
第四级：负载均衡（随时新增节点，移除节点，横向扩展）
第五级：异地灾备
第六级：全球负载均衡（分布式灾备）
从第二级开始就具备“零数据丢失”，远远高于国家标准与国际标准。一级可能需要人工介入，但从第二级开始都是无人值守，到第三级可以达到7*24*365不停机运转，实现智能故障转移。
双机设备已经推出历史舞台，基于主备的数据中心方案也显得过时，我只推荐双活的备份方案。
双活互备不分主次机房，两个机房同时对外提供服务，当一方出现故障时才会将用户自动切换到另一个机房。
双活互备方案的优点
双活互备方案的缺点
![[提示]](/graphics/tip.png) | 提示 |
|---|---|
| 另外需要注意的是当双活启动时，平均分配用户到两套交易系统上，如果一个交易系统出现故障，可能会增加另一个交易系统访问压力，所以要注意监控两个交易系统服务器的使用情况。 |
满足灾备前提是网络畅通无阻，同时网络拓扑设计能够支持灾备。
数据中心要求
供电要求：双路供电，电力来自不同的发电厂，UPS 后备电源，柴油发电机组
空调要求：通常从地面送风的机房比较好
室内气体监控：数据中心应该具备气体监控，室内粉尘，湿度监控
消防：二氧化碳灭火器
机柜：机柜有很多规格，虽然都能放入机架服务器，但有些比较小，没有提供电源线与网路槽。220V电源与网线混在一起可能造成一定的数据丢包。
网络设备：我常常考察一个机房会看他们的核心出口设备（是否有顶级的Cisio设备）
单机房最大的优势是网络连接比较方便，很多公司购买的机柜相邻，可能从机柜上方走线。
双机热备这种我认为是过时的技术，常常主系统出现故障时，你会发现备用系统无法工作。所以我设计的系统都是AA(Active-Active)所有节点都对外提供服务，能够更早的发现问题。
异地灾备通常将两个机房打通，但是由于线路带宽有限(通常是1G双绞线或光纤 )我能做太复杂连接。通常我们将这条线主要用户数据复制，状态同步，其他服务器独立工作。
一旦数据中心网络部分完成，下一步就是部署各种服务器，同时服务器的部署必须满足灾备的要求，否则无法实现灾备切换与故障转移。
服务器与交换机连接，按照服务器重要程度或者是否具备故障转移，有两种方案，如具备分布式部署的服务器可能只连接一条网线，有些服务器无法分布式部署，我们是两个网卡分别连接两条网线到两台交换机，同时网卡绑定为一个适配器。
网站提供新闻，资讯，开户，转帐，活动，报表，在线客服等等功能
上面是动态页面方案，分为SSL服务器，WEB服务器，API接口服务器，Admin服务器。全部具备水平扩展与动态伸缩。下面分别详细说明他们的功能，为什么这样部署。
动态页面服务器
SSL：负责处理用户请求的加密与解密，我们将它与WEB分离，这样能够更好的伸缩扩展，同时提供故障转移功能，我们可以部署很多台这样的服务器。在不同城市，然后通过智能DNS将用户解析到距离用户最近的节点上。
WEB：动态页面服务器
API： Service 服务器，可以通过SOAP, JSON, MQ等等方式访问，WEB任何操作都要请求API服务器完成，WEB服务器不允许直接操作数据库，全交由API处理。API具有运用层防火墙的功能与ACL访问控制列表。
Admin：网站后台
HA：负载均衡软件或设备
与门户网站不同，我们的网站访问量并不大，性能瓶颈基本不存在，更多是考虑高可用。
静态页面以及CDN部门这里就不谈了，非常简单，有兴趣可能到 http://netkiller.github.io/ 找相关资料。
在交易过程中出现报盘中断是大忌，我们必须尽一切努力，让交易系统能源源不断的接收价格数据。为此我需要重点考虑数据源的灾备。
我们设计了一个DataFeed程序，能够多方接收数据，因为每个数据源提供的产品不同。我们在这里可以合并，筛选，过滤等等。这个应用可以实现水平扩展，我们可以放在2个以上的机房当中。
接下来在交易服务器中，设置多个数据源分别指向Data Feed 1,2~n。与Trader相同机房的DataFeed的优先级总是最高。
数据的部署要考虑几个问题，我一直不建议主备方案，而是采用双活方案。所以我们要考虑两个机房或者三个机房他们数据复制问题，性能瓶颈问题，数据安全问题等等
上图我的方案中采用了Master-Master双活方案，同时每个Master都会有一个Slave。Master 主要用于主要的业务，Slave主要用户数据分析，报表查询等等非实时，且长时间允许等等查询服务
数据库访问需要经过SLB服务器，为数据库提供负载均衡，故障转移，水平扩展等等功能。
所有的数据操作只能通过API完成，不能直接连接数据库并通过SQL存取，上面已经提到过，这里不再多讲。
| 提示 |
|---|---|
| 如果是三个以上机房，将采用环形复制，大致原理Master A向Master B复制，Master B向 Master C复制，Master C在向Master A 复制，形成一个环路。 |
如果数据库查询如果出现瓶颈，增加Slave即可。
软件的设计都要围绕着灾备进行，不能分布式运行，就不合格。
交易软件通常使用TCP私有协议，与我们常见的HTTP协议不同，HTTP是无状态，即用户请求-处理数据-渲染HTML页面-销毁并释放内存，我们很容易开发基于负载均衡的横向水平扩展的应用程序。 而交易软件采用的是持久TCP连接，实时传输用户请求，并将结果会送给用户，中间过程不允许中款，且用户状态数据存储在该交易服务器的内存中，如果我们采用常规手段做负载均衡，就会出现用户被分配到另一台服务器上，而无法继续交易。
我们首先要做的就是将用户状态持久化，有点类似我们在HTTP应用中将Session持久化方法，将这些数据存储到公共的共享服务器上。同时该服务器也需要做高可用等等，保证无单点故障。
第二步，我们解决分布式交易，分布式交易是指可以在交易服务器上任意一个节点上均可交易。方法有很多，复杂程度也不同。
通常解决分布式运行的方法，无非是同步|互斥排他锁|共享存储等等，其实就是两多线程的很多技术扩展到了互联网上。使用节点同步解决共享内存访问问题，使用远程锁解决解决多节点访问问题等等。
解决挂单问题，通常交易是即时完成的，较难处理的就是挂单。
下面的方案是最简单的，开发难度最低。
数据库表中增加一个字段例如
----------------------------------------- Id | node | status | xxxxx ----------------------------------------- 1 | trader1 | N | xxxxx 2 | trader2 | Y | xxxxx -----------------------------------------
trader1 表示该记录产生在trader1 必须在Trader 1上完成成交
trader2 表示该记录产生在trader2 必须在Trader 2上完成成交
测试用例
| 提示 |
|---|---|
| 更新记录状态必须增加node条件 |
Update tab set status=Y where id=1 and node =<my node> …
双向通知的含义是Trader 1状态发生改变会通知Trader 2， 反之Trader 2状态发生改变会通知 Trader 1。
上图可以看出通知与数据库持久关系图，在交易周期内实时接收通知，一旦收到通知，便根据通知中的指令做出反应，改变当前交易服务器的状态。
这种设计可以采用日志复制，然后重做日志的方式，非常累西数据库同步技术，缺点是可能有延迟。设计需要考虑进去。如果超过三个节点就要采用环形复制
我曾经想过通过IP组播，广播技术实现通知发布，这样就可以不设置目的地地址，同时增加了部署的灵活性，而且对于广播节点数量没有限制。比较适合三个以上的机房部署。
用户分流是指，不同用户登录到不同的服务器上进行交易。因为我们的交易系统是可以水平扩展的，可以有很多台交易服务器并且都是Active状态，任意一台服务器都能登陆交易，我们可以使用哈希算法基于用户ID，将用户分流到指定服务器。
用户分流还可以使用智能DNS技术，将用户分流到距离自己最近的交易服务器上。
还可以根据路由TTL值与Ping值进行优先级分配。
我们这个行业不是门户网站，所以数据量不会非常大，但我们要未雨绸缪，我们在设计阶段就将这些问题考虑进去，使将来不会困扰我们。
数据量最大的当属交易数据，有些金融产品双向交易，交易时间长，所以交易数据的累积相当可观。
虽然你可以定时删除，但我不建议。我认为交易数据需要永久保留，为什么？ 当交易数据积累到一定数量级，我们就可以从多角度数据挖掘，为决策提供数据支持。
当数据庞大到无论怎么优化都无法提高查询性能是，这时你就要考虑数据库拆分了。
数据库拆分需要遵循几个原则，不仅仅是按照年份或月份分库分表。
数据库拆分
传统方法，将数据日期切分，这回带来索引的不连续问题，且查询时必须加带日期，以便定位到指定的表中。如果需要做数据挖掘，需要统计四年的数据，必须查询四次，效率大打折扣。
新的拆分方案，通过哈西算法均匀的将用户分配到指定数据库中或表中。这样所有针对该用户的操作都能在同一个数据库中完成。
根据不同的功能拆分数据库或表，也是一种非常不错选择。
自动化运维保障服务器快速部署，改善灾备的响应速度。尤其是需要重建某些服务器的时候。
自动化运维应具备
自动化运维可以降低人为因素产生的故障，如误删除。
演练的主要目的是，验证两个交易系统能够互备，相互做对方的备份，我们将当前登录的系统称为主系统，另一次叫做灾备系统（仅仅是观看的角度）。
另一个目的是，双活系统能够自动规避很多小灾难，灾难没有扩大前系统已经自动修复了，长此以往系统管理员就会麻木，懒惰，侥幸。当更大的故障发生或双活不能正常工作时，由于管理员长期不再状态，就会产生难以预期的后果。
灾备原理
灾备中心系统结构（系统部署图、网络结构图）
灾备系统运营维护
公司操作流程
切换操作流程
数据检查与验证
业务准备
确定演练时间
通知参与演练的客户
通知参与演练的业务部门
技术准备
做好演练前的数据备份
检查灾备各应用服务状态
参与部门
开发部门
测试部门
业务部门
模拟灾难: 在演练开始时间，关闭主交易中心的所有的应用，模拟灾难发生。此时，公司应完全按照“公司操作流程”和“灾备系统切换流程”来切换灾备系统。
演练过程: 见“切换操作”和“公司操作流程”
演练级别定义
演练的方式有两种
演练方式
第一种方式适合灾备演练初期，因为各部门都有准备，是在良好的环境下进行，大家都坐在电脑前，看着严控数据，有条不紊按部就班。
但故障是随时都能出现的，是无法预知的。所以我们还需要实行“突击演练”。“突击演练”最近接真是故障发生的场景，可能大家会手忙脚乱，打破之前的各种流程。你会接到各部门领导的电话，可能你当时还在睡觉或外出路上，你没有地方上网，你的脑子一片空白，这才是真实场景。
切换前操作
主要的工作室数据备份，其他工作可能作为演练的一部们，工作流程等各种问题在演练中暴漏出来，才能对后面的工作改进有所帮助。
双活互备切换操作，要进行两次，第一次将A机房视为主机房，从A向灾备机房B切换。完成后检查无误，再反向操作一次。
切换要模拟各种故障，通常采用的手段就是拔网线，关闭服务器，关闭应用，使其每条灾备链路都能跑通。
数据中心故障
模拟机房停电，将另一侧灾备机房关机
接入链路故障
防火墙设备故障
交换机故障设备故障
服务器故障
切换过程中，每一次动作，都应该收到来自监控系统的报警并精确描述的故障。这也是完善监控系统绝佳机会。
应用系统服务状态检查
主库备库数据是否一致
接口能否正常工作
网上交易能否正常进行
交易压力是否正常
公司需要进行多方面的数据核对，包括
委托单是否一致, 委托回报是否完整
成交回报是否完整, 交易记录是否完整
行情数据是否正确
客户资金是否正常
当主交易系统切换到灾备系统后，必然会有一些影响业务的情况会发生，公司需要事先有所准备，并制定相关应急预案。
由于发生重大事件，可能造成灾害发生时切换到灾备中心的交易系统无法切换回主交易系统。导致交易需要长时间在灾备中心运行，对灾备中心形成压力。对于此情况，公司应该制定详细的预案，保证灾备中心能承担起正常交易压力，使用户交易正常进行。 当确认灾备中心无法在短时间切换回主交易中心时，公司应立即启动预案，并和服务部门联系，请求技术支持。通过增加服务器、增加访问带宽、交易数据备份等方式，使灾备中心转换为主交易系统，长期承担主交易系统交易工作。
当主交易系统需要切换到灾备系统时，为避免一部分人仍然连接到主交易系统，一部分人连接到灾备系统，切换前必须关闭主交易系统的应用服务器或者段外网络。
在切换以后，有部分业务将受影响，以下为部分情况：
当灾备中心承担交易时，灾备系统中的所有交易数据将进行备份，供事后的查询和备案。公司可以采用热备系统，备份灾备中心的交易数据。并做好灾备中心数据及时转移到安全位置。确保灾备中心数据不会丢失。
实现双活最大的障碍是人，不是技术。你是否有足够的权限起到很大的作用。
很多企业动不动讲流程，跨部门沟通十分困难，甚至设置了很多部门防火墙（无形的墙），部门领导平级更是问题，这样会无休止争论下去，无法决策。
另外很多企业管理层不懂技术，无法做决策，有些领导更是怕担责任。
开发人员都会抵触你方案，因为在现有的稳定系统上增加改动且他并不理解的工作，后续的测试，验收都受到影响。
运维也很不情愿，只要是生产环境任何调整都存在一定的风险。
如果你的企业向上面一样，企业已经在走下坡路了，不做事就不出事，拒绝创新.....
总之，装B的人不在少数。
Many people think they are full of niubility and like to play zhuangbility, which only reflect their shability and erbility.
