连B站都崩过，实现系统高可用的确有难度

　　7月13日，网友的深夜狂欢第一次出现了除消费盛宴、明星八卦、重大新闻以外的话题—网站崩溃。

　　B站崩了首先在微博热搜燃爆，豆瓣崩了、A站也崩了、晋江崩了紧随其后，上演了一出热搜会晤。

　　直到7月14日凌晨2:20分，官方回应机房发生故障，但是并未对具体宕机原因作说明。

　　于是，广大网友脑洞大开，开始推测本次故障是谁的锅。出现机房断电、机房着火、黑客攻击、云服务异常、CDN异常、运维实习生失误操作、奥特曼袭击等各种假说。。。

　　不管是何种原因造成的故障，只有经过完善的复盘，才能吸取教训，避免同样的问题再次发生。显然此次重大故障，再一次让许多企业意识到建设高可用容灾系统的重要性。应用级别的容灾体系通常包含了流量接入层、应用层、数据层多个方面的建设方案。

　　以数据库层面的高可用容灾建设为例，由于不同的业务部门对RTO（恢复所需的时间指标）以及RPO（能够恢复到的最新状态）两个指标的期望值不同，对性能、可扩展性、停机成本、维护成本等其他可用性变量的侧重点不同，最终的实现方案也存在一定的差异。

　　无论什么实现方案，最根本的核心始终围绕5个方面的高可用技术。

　　整体建设过程通常包含调研评估、架构规划、测试、上线四个阶段。

　　需要强调的是，容灾演练是验证故障发生时业务连续性、数据可用性的重要手段。对于7*24小时运行的系统，通常采取破坏性测试，模拟服务器、数据库、应用调度等多种场景的故障，以检验容灾系统是否具备业务接管的必要条件。

　　然而系统上线并不意味着容灾演练的结束，而是常态化的开始。由于系统随着业务的调整，会不断有框架升级或部署架构的迭代更新，只有通过定期演练，针对每一次变化确定具体的场景和范围，才能及时发现灾备系统的缺陷，提高突发事件响应与处置能力。

　　数据库高可用容灾实践

　　客户简介

　　该企业作为互联网+健康医疗整体解决方案提供商，首创国内互联网+健康医疗区域服务平台和标准智慧医院概念，通过优化咨询、预约、一卡就诊、电子病历管理、诊间支付等就诊流程，打造线上+线下的智慧医院O2O闭环服务生态系统，从而解决就诊过程的“三长一短”问题。

　　高可用需求

　　一次系统故障，让自助就诊系统突然卡死，导致多个医院的挂号业务全面瘫痪，严重影响了医疗工作的正常运转。

　　云掣数据库专家对系统进行了紧急救援，快速恢复业务。通过故障复盘，发现该企业在数据库运维管理方面存在开发规范缺失、变更审核机制不完善、集群选型与应用场景不匹配等一系列亟需解决的问题。

　　为了避免再次出现此类重大故障，同时提高系统的健壮性、稳定性和可靠性。客户委托云掣数据库专家针对业务现状，做数据库系统的同城双活高可用容灾架构改造。

　　主要难点

　　根据业务要求，整个高可用改造过程需要做到业务0中断，数据0丢失、0出错，同时核心业务的数据库系统要做到跨机房的容灾能力。

　　解决方案

　　通过详细的调研，基于该智慧医疗系统业务实际情况，围绕正常运行时间、恢复时间、恢复能力、停机成本4个核心可用性变量，云掣提供了以“MHA+ProxySQL+Keepalived”为基础的高可用架构方案：

　　使用千兆光纤物理专线连接同城双机房，确保网络连接质量和数据传输速度。

　　基于专线构建大局域网，降低网络环境复杂度，保障数据传输的安全性。

　　主机房部署双节点，限制服务器级故障转移在同机房内切换，保障恢复速度。

　　备份实例使用级联复制，隔离于业务系统之外，提供日常报表查询及数据库备份服务。

　　当主机房A瘫痪，所有功能模块会全部转移到容灾机房B，继续对外提供服务。

　　基于云掣数据库运维管控平台EasyDo，对数据库进行监控，降低运维成本的同时运维提高效率。

　　客户收益

　　彻底铲除原有架构暴露的安全隐患，跨机房MHA+自动备份机制，保障数据存储安全。

　　ProxySQL实现应用无感知切换，解决客户对架构改造的担忧，真正实现了业务0中断。

　　故障恢复效率得到明显提升，由服务器硬件引发的故障，可实现分钟级别切换到备库。

　　数据库系统作为智慧医疗体系中重要的后端支撑，自上线以来一直稳定运行，使患者获得了更好的就医体验。

　　但在整个业务系统中，数据库属于既核心又脆弱的一环，虽然做到了高可用，如果使用不当同样会对性能产生不良影响，给业务带来严重的损失，因此仍需要专业的专家运维服务持续为企业提供数据库稳定性保障。云掣通过读写分离、OLAP剥离以及SQL优化服务，有效提升了数据库性能，通过SQL变更审核服务，解决了数据变更及对象设计不规范的问题。

　　推荐阅读