业务代码层面灾备思考和设计

简介

        随着业务的扩展，用户的增长，稳定性和可用性要求也越来越严格。从主备切换，一主多从，读写分离，哨兵模式等，我们经历很多应用部署层面和应用架构层面的灾备，在业务代码层面其实我们很多业务也做很多稳定性和可用性的工作。

        因为我们基础服务将要迎来很多业务方的接入，对我们稳定性和可用性也提出更多的要求。现在我们就来看看我们在业务代码层面灾备思路

1: 存储方面

        众所周知不论是什么样的业务最终都是要将数据落到数据库中，基础服务同样。为了能够保证我们的服务稳定和搞笑，在代码层面我们引入了缓存和其他存储类型，以及异步化。

2：不同存储类型（MYSQL，REDIS，HBASE，MONGODB）

        不同的存储类型之间可能存在自身一些独特语法和特色，比如我们存储的灾备计划使用HBASE 来替换 MYSQL 中一张核心log表，这样能够利用Hbase 读写上的优势解决Mysql大数据量带来的瓶颈问题

3: 问题

        1： 语法不同

        因为HBase 本身是通过一些Filter来进行数据筛选，如果想使用SQL就需要安装一些第三方的相关插件（例如：Apache Phoenix 或其他），这些第三方的插件会有一些独特的语法，无法直接使用Mysql 的sql 进行数据管理，此时就需要我们参考原有的DAO层，实现一套新的DAO但是彼此间的业务逻辑和执行结果要保证幂等一致。此处大家可以考虑使用代理或者适配器模式进行实现

        2:验证

        因为只是切换了存储类型，那么完成相关代码开发后就需要对相关DAO层进行验收，验收的标准，就是相同条件下，两个DAO层的执行结果要一致，一旦出现执行结果不一致就很可能造成生产事故。

        3.业务场景问题

        很多基础服务，可能开发自身测试时正常，但是碰到大数据量或着部分特殊的业务场景时，改造后的两个DAO执行的结果会出现不一致问题？这个时候就体现出测试任务和任务执行的也无妨参与测试验收，测试的时间可以尽量延长一点，如果时间允许可以联合测试人员进行一轮或多伦压测，对程序的运行情况和部署情况做到心中有数。方便后期维护和扩缩容。

4: 中间件

        其实代码层面我们的灾备几乎都是大同小异，就是确保代码再执行过程能够顺利的执行下去，有些时候我们可以接受慢一点，但一定要准确可能。而很多中间饮用可以解决我们程序运行中大部分的问题，而且很多同类中间件时可以替换的。例： MQ （RokectMQ，RabbitMQ，Kafka等）完全可以再业务代码层面完成一些替换

5：优先级备选方案

        在短信发送，语音，文件存储这些基础服务，我们完全可以做一些优先级和备选方案，例如短信的发送，现在有很多的短信运营商，我们可以将这些运营商根据价格，稳定性，限制做出一些排序，然后不对的业务可以使用不同的运营商来进行短信的发送，如果其中一个运营商出现问题我们可以通过开关或者程序自动进行降级和不可用，甚至自动切换到其他运营商将短信发送出去。

        

总结

        不论是存储层面的灾备还是业务功能上的灾备，我们最终的目的都是为了程序的稳定和可用，同时将成本降低，将能力提升