这是学习笔记的第 1953 篇文章
今天和同事对于高可用方向和数据流转方向的一些事情做了交流，总体来说收获还是蛮多的。
其中主要的一点是这两个方向在我们的工作中的重视程度不够，在实际工作的进展，改善空间还是很大的。
比如对于高可用，基于consul的管理方式，可以对我们已有的MHA管理方式做一种补充，而MHA,consul之间的关系应该是更加的简化，比如我们可以寻求更好的高可用方案，其中一个目标就是对于数据库切换能够达到更高的标准，MHA只是一种方案，如果引入MHA方案，那么对于切换的逻辑我们还需要指定相关的健康检查脚本，更简单清晰的是MGR的方案，健康检查脚本还是需要的，但是逻辑就简化的多了。
另外我们的高可用有一个通用的问题是对于高可用的监控不足，我们缺少对于高可用组件的监控，导致高可用是相对脆弱的。比如我们使用额consul,但是我们缺少对于consul的监控，缺少对于域名解析的监控。
对于高可用来说，出彩的就故障转移功能和业务额快速切换，在这一块，我们需要持续补充一种支撑能力，那就是对于高可用的理解，不应该完全局限于数据库层面，我们其实从架构层面开始可以辅助去做一些事情，比如发生了故障，数据库实现了高可用，但是应用的支撑能力很有限，导致业务还是不可用，难以快速恢复，那么对于数据更高要求的情况下，发生了数据库故障，在故障转移的过程中势必会产生数据写入失败的情况，对于一些业务来说，从数据完整性角度来衡量就是不可接受的了。
对于数据流转来说，改进空间更大，目前为止我们有多个数据库方向的数据流转支持，但是对于异构数据流转，表结构流转，数据生命周期管理，流转任务日志管理这些方面，还是缺少一些完善的功能模块。datax是一个比较轻量级的工具，但是本身还是存在诸多的限制，我们可以在这个基础上，让数据流转的服务更加具有业务价值，那就是可以根据业务特点去定制流转规则，一种相对较好的方式是做到数据落盘的方式来流转，通过队列的方式去管理大批量的流转任务，确切的说，这是一套完整的流转服务，不会局限于单一数据库方向，而是要做到融合。数据的同步策略看起来还是比较简单的，但是实现起来和业务场景结合起来就需要功能的完整性和稳定性，结合任务调度，引入更多更完善的解决方案，不光局限于datax，其实可以打造一个通用流转平台，比如大批量的表结构变更，就可以充分结合逻辑备份恢复工具来做，而对于数据层面的复制，datax是一种轻量的方式，而对于更高要求的数据复制，比如源表有10亿，那么我们就需要更多考虑性能，比如对抽取的数据做分片，基于容量或者数据条数进行拆分，总体来说，具有业务流动性，业务价值自然就会体现出来。