基于全国产基础设施的双活系统建设

在业务配合下，用逻辑复制的方式实现多地多活是比远程RAC更好的双活模式，2009年的时候，我们帮助顺丰的核心系统阿修罗建设过一个深圳，合肥，成都三地三活的系统。深圳承担80%的业务，成都合肥分别承担10%的业务。当三地数据复制延时低于1小时的时候，业务上可以确保数据不会有冲突。当数据复制延时高于30分钟的时候，暂停成都，合肥的系统，只保留深圳主站提供对外服务。这是一个基于Oracle streams的三活环境，数据库是Oracle 10.2.0.4。这种双活环境主要的目的是确保某一地数据中心故障的时候，核心业务能够不被中断。因为之前顺丰出现过阿修罗故障导致车辆在到达海关后无法打印通关单，导致车辆只能卸货返回的恶性事故。1个多小时的系统故障导致了2000多万的经济损失。

2015年底和某省调的客户交流IT新技术，我们讲了一堆技术，最后客户的领导指了指双活，说我们对双活感兴趣，能不能帮我们做一个双活的试点项目。我们的OMS主站在杭州，备站在湖州，两地有100多公里长的光纤相连，以前主站出问题，备战接管总是不顺利，有时候业务会停大半天，甚至对一些电厂的业务都产生了一定影响。说实在的，听到这话，第一时间我感到有点头痛，因为省调的系统从上到下都是国产的基础设施，存储、服务器、操作系统、数据库、中间件、负载均衡、网络设备都是国产的，在国产的达梦数据库上做双活我们还真没做过。我们的交流材料里介绍的营销系统双活的案例是基于ORACLE 远程RAC的双活，核心技术采用了veritas的卷复制，和客户要做的双活是两码事。当时在客户的强烈要求下，我答应先测试一下基于达梦构建双活系统的可信性。客户看上去也真的很有决心做这件事，不到一星期就把和这项目有关的几个厂家，包括软件开发商和存储供应商华为、负载均衡厂商华三、数据库厂商达梦、操作系统厂商凝思。经过大家的集思广益，我们确定了采用一个比较稳妥的方案。主方案基于达梦数据库准同步逻辑复制的读写分离双活方案，主站负责读写业务，并按比例分发30-40%的读业务到备站上。开发商对方案没有任何异议，唯一的要求是让应用尽可能少改造甚至不改造。初步方案有了，下一步就是测试，正好我们在南瑞基础架构实验室里有一套为ORACLE EXTENDED RAC准备的20公里光纤模拟环境，可以用于跨机房双活的测试工作。虽然实际环境光纤距离超过100公里，网络上会增加一些延时，不过因为当时选择OMS这个省调的核心系统的时候也是做过一些考量的，这个系统数据量不大，不到2TB，高峰期访问并发量也就100来个，并发压力并不大，这点网络延时还是可以承受的。刚刚开始测试的时候并不顺利，各个国产软件厂商和国产硬件厂商之间的配合并不融洽，我们刚开始把凝思操作系统当成红帽来用，理所当然的认为一些软件包是必须存在的，实际上为了在凝思上解决连接我们的分布式存储的iscsi tgt都花了将近一个月的时间。不过好在参与的各方都比较积极的配合我们的工作。基于达梦DMHS复制与JDBC读写分离网关的测试进行的比较顺利，达梦的这个刚刚发布不久的读写分离网关迎来了第一个核心系统用户，他们的研发人员也十分积极的帮助我们优化网关的性能。几个月后，我们把工作进度向省调领导汇报的时候，他和我们说了实话，当时他选择双活这个项目的时候的真实目的有两个，第一个是OMS的备战升级确实一直是他想做的事情，第二个目的是想给我们出个难题，让我们知难而退，因为他当时并不认为基于全国产基础设施的双活系统能够搞出来。当我们把初步测试的结果拿出来的时候，还是很出乎他的意外的。我们的工作得到了他的认可，于是一方面让我们继续完善方案，一方面客户开始了正式项目立项和说服上级领导的工作。有了客户答应立项的承诺，后续的方案完善也得以继续。因为无法像远程RAC那样自动接管故障节点的业务，因此我们需要开发一个双活管控工具，用于业务接管的自动化切换工作。

双活工具根据zookeeper集群中实时采集的各种状态数据，自动判断下一步工作任务的清单，随时准备接受一键切换的任务。

在这个方案中基于DMHS的准同步复制与达梦JDBC读写分离网关是最为核心的，最后双活系统的运行效果取决于这两部分的工作效率。因此基于OMS系统我们结合DMHS复制做了大量的优化。最后的优化效果是在主站导入200万笔数据（大约900M），备站的复制延时不超过2秒钟。实际上在2016年6月，OMS双活系统上线的条件就已经基本具备了，我们把环境从南瑞的实验室搬到了省调的测试环境，利用真实的环境进行了大量的测试。系统迟迟不能上线的主要原因不是技术问题，而是来自于各方对全国产双活系统能否建成的质疑。经过半年的不断测试，这套基于全国产的双活系统终于在2017年正式上线了。当时也没做什么宣传，不过客户的自动化处的领导当时兴奋的和我说，这不一定是全国第一套全国产的双活系统，但是一定是国内第一套基于全国产基础设施的OMS双活系统，我们应该是创造了历史。这件事已经过去三年多了，如果不是春节期间客户搬迁主站系统出了一点问题，搬迁后我们的分布式存储（主站的数据库使用的存储系统是我们基于CEPH封装的分布式存储系统，备站用的是华为的OCEANSTOR 5500）出了点问题，需要我们帮忙解决一下，我都已经忘记了这件事。我问他们搬迁工作为什么不找我们配合一下，他们居然说，这系统挺皮实的，上线后没出过什么问题，主站搬出点问题，备站能接管，所以也就没想着麻烦我们了。实际上，建设这套基于全国产基础设施的双活系统，技术工作并不复杂，花在技术验证上的时间也不多，更多的资源是浪费在应对各种质疑上，数据库国产化替代也好，信创也好，恐怕面临的是相同的问题。如果大家都不敢担责任，那么还是维持现状就好。如果当年没有那位处长的坚持，也不会有这套OMS双活的成功上线。