为什么要有自动化和人工的两种切换方式?这里我要解释下 ， 一种新的事务上线之前 ， 都会面临一些挑战和怀疑的 ， 都是一个循序渐进的过程 ， 特别是是在金融行业 ， 自动真的好么？万一搞错了怎么办？决策因素和模型是否设计正确？设计正确了是否编码正确？最难的是还要应对不同应用场景的需求 ， 有的应用要求RPO优先 ， 有的应用又要求RTO优先 。
我们之前经过充分调研 ， 预见到该种情况 ， 所以我们提供了多种高可用策略的灵活配置 ， 以便满足不同应用的个性化要求 。我们的高可用整体上面基于MySQL的复制技术 ， 通过半同步复制和多数派共识机制实现冗余备份 ， 基于MySQL binlog日志实现自动数据补全 ， 保障数据的一致性 。
4、其他考量
文章插图
除此以外 ， 数据库选型后 ， 还应完善相关体系 ， 规范设计、开发、测试和运维 ， 实现管控的体系化和自动化 ， 才能避免眼高手低 ， 减少生产安全风险 。
1）在设计层面 ， 在验证功能、新特性和配置基线 ， 数据备份恢复的基础上 ， 我们参考了爱可生、阿里等公司的规约 ， 建立了MySQL设计指引 ， 可以说 ， 我们是站在巨人的肩膀上成长的；加强元数据管理 ， 提出元数据完备性、明确性、具象性和前瞻性的要求 ， 建立应用的元数据标准 ， 统一数据架构设计 ， 架构师设计表结构时均基于元数据进行设计 ， 提升数据架构质量；此外 ， 我们还开发了表结构设计工具 ， 将其融合在Excel中 ， 实现对元数据的自动应用 ， 支持自动生成脚本 ， 简化架构师的贯标操作 ， 将人员成熟度的要求降至最低 ， 提升设计效能和质量 。
2）在开发层面 ， 我们制订了开发规范和SQL调优指引 ， 同时基于sonar开发了MySQL检查工具 ， 支持对基于myBatis的mApper文件进行解析 ， 提前发现SQL不规范的写法 ， 同时将sonarlint插件纳入开发人员必备插件 ， 实现规则的云化部署和本地联动扫描分析 ， 将规范融入开发过程中 ， 提升开发人员的SQL编写能力 。
3）在测试层面 ， 我们自研压力测试服务平台 ， 尽量减少性能瓶颈 ， 提前发现SQL性能问题 。
4）在运维层面 ， 感觉应该是最重要的一个层面 ， 我们需要考虑自动化部署、监控告警、故障分析、自动巡检以及SRE平台 ， 还有数据迁移、备份恢复、配置管理、版本升级、多租户等等 。
随着节点的增加 ， 运维实际上是一个很大的挑战 ， 几千几万个节点 ， 安装、监控、报警、故障、人工处理等非常麻烦 。必须要实现自动化的安装部署 ， 进行批量安装部署 ， 同时批量串行还不行 ， 时间太长了 ， 要并行 ， 并行太高了 ， 网络的流量又会受到很大的影响 ， 所以很多场景都需要细细打磨 ， 还要按照博弈论的思路建立纳什均衡 。
监控告警里有事件等级 ， 如何划分各种等级 ， 都需要灵活定制支持 ， 建立基线告警 ， 建立应急流程 。像华为等公司都有基于设备的网络拓扑图 ， 问题在哪个节点 ， 可以快速分析和定位 ， 所以说运维是一个很麻烦的事情 ， 像故障分析 ， 完善日志记录、采集和分析 ， 建立故障分析规范 。自动巡检 ， 自动化的巡检和评分报告 ， 对实例状态进行健康评分 。在这个阶段我们实现了同城RPO=0 ， RTO=分钟级目标 ， RPO为0的切换 ， 问题可监控 ， 实现了人工或自动的一键式切换 。
最后我们不得不提到SRE ， 很多人会联想到运维工程师、系统工程师 ， 其实不然 ， SRE本质上仍然是软件工程师 。SRE最早在十多年前Google提出并应用 ， 近几年逐步在国内外TOP互联网公司都开始广泛应用 。其中Google缔造了SRE ， 并奠定了其权威的地位 ， 而Netflix将SRE的实践做到了极致 ， Netflix仅有的个位数的Core SRE支持了190个国家、数亿用户、数万微服务实例业务规模的运维 。
推荐阅读
- 考试|高三学生要谨慎选“走单招”，不然会悔不当初，选择比努力更重要
- 食品安全|好丽友澄清配料“双标”问题：在韩国用的也是代可可脂
- “万塔之邦”指的是什么？
- |“男人解手的时候抽烟，女人解手的时候干什么呢？”
- 穿衣搭配|女人上了年纪后，4个在外人看来很“作”的细节，才是减龄的关键
- 数九寒天是中风高发期！预防有个“三四五”
- 高血压患者如何安全“过冬”
- 教你冬季健康吃火锅 去火“三宝”不可少
- 冬季成老年人“绝命杀手” 10招让老人安全过冬
- 冬季防晒“停不下来” 雪地里紫外线最强