点击“开发者技术前线”，选择“星标????”

13：21 在看|星标|留言,  真爱

▌概述

很多互联网公司在发展过程中大多出现过多次机房网络故障的情形，如果发生故障，一般需要动用整个IT部门的人力进行流量切换和客诉处理。为了避免此类情形的发生，公司计划进行服务的高可用建设。会员部门持续跟进公司网络基础设施建设，和网络等基础服务部门一起，实现服务的高可用。目前已经实现了同一Region的互备，这里分享一下会员服务的高可用建设的实战和探索。

对于网络、机房、硬件服务器之类的故障，一般采取多备份和绕路回避的策略，将流量从出故障设施切换到正常的集群中，将故障服务下线，待服务恢复后再切换回来。总体来说，须要求多副本部署、实时故障检测和服务快速切换。目前会员已经实现从最上层的DNS服务到底层的数据库的自动切换。

▌高可用的方案

▌升级网络架构

1.运营商出口的互备

系统网络部门研发了域名，LB的运维管理平台，支持故障监测，业务异常时切换到备用资源，变更配置时进行通知。会员在使用过程中，提出了很多优化需求，如展示IP的地域和运营商信息，提升用户体验，目前部署了三套独立的出口IP，相互之间可以在网络层隔离和自动切换。因为数据库的主库暂时无法多机房部署，所以订单、权益等核心服务和数据库保持同城部署。目前在同城机房部署了两套出口IP，可以进行互备和自动切换。

用户访问最近的机房总是最快的，会员将DNS区域划分出北方，华中，华南三个独立的区域进行部署，设置独立的出口IP，区域划分上也保证了流量的均衡。网络组提供自动化的运维设施，通过故障演练，已经可以在故障时进行流量的自动切换。

在人员方面，邀请网络部门专业人员对会员团队进行网络基础架构和网络保障方案等的讲解，对过往故障进行整体分析总结，并一起对业务灾备方案做出调整。通过大家的共同努力，近一年来将业务故障率降为零。

2.内网IDC机房的互备

各机房通过专线互连互通。应用的部署与上下游的服务保持在同一个机房最佳，不占用专线带宽，提升服务稳定性，减少网络抖动和晚高峰的影响。在统计了应用的上下游的流量分布之后，应用在部署上覆盖了主要的机房，将最早的自建机房定义为备用机房。当主机房故障时，DNS系统通过定时检测，发现异常后会自动切换到备用机房。内网服务间东西向流量是很大的，高峰时直接切换到另一个机房可能会引起机房不稳定，所以每个服务从Nginx层配置了应用级别的限流。极端情况下的流量监控和限流成为保障服务安全稳定的最后屏障。流量可以在机房间进行切换，如果流量超过机房承载能力，会触发限流和报警。

▌升级应用服务

1.改造单点的应用

部分应用如worker一般都存在单点的情况，将应用改造成可以部署在多个IDC中，形成多个互备的集群。Worker一般会执行定时任务，通过改造定时任务，并使用了开源项目xxl-job，开发出了异步任务框架和调度系统(vip-job)，定时任务由调度系统触发，随机选择一台服务器进行任务调度，解决了单点问题。

2.核心应用多机房部署

核心服务（如会员影片播放链路上的应用）会覆盖尽量多的IDC，期望流量在同机房流转，保证服务质量，同时核心应用的DNS配置根据地域和运营商两个维度进行优化，给用户提供最优的服务体验。

3.升级数据库

公司的数据库部署架构为DNS+HA。通过实现Raft协议，开发了HA-Master/HA-Agent监控和切换软件。当数据库实例宕机时，agent会发送心跳检查，触发主备切换或是将宕机实例从DNS中下线，避免人工运维成本和宕机带来的数据丢失。

▌消息中间件和Redis的高可用

会员使用服务云提供的RocketMQ，申请支持跨机房互备。

将ActiveMQ和历史不支持HA的RocketMQ进行替换和升级以支持互备。

Redis使用Sentinal机制进行主备切换。两者都具备HA的能力，使用起来比较方便。

1.会员应用的部署架构

会员将目前的机房进行了抽象和划分，自建的核心机房可以承载所有的流量，部署了会员全套的应用。租赁机房存在扩容困难，机器折旧，流量单一，应用覆盖不全的问题。将租赁机房划分成一个整体，抽象成一个虚拟机房，从外部看，虚拟机房和自建机房一样，支持多运营商，容量大，应用覆盖全面，可以提供高质量的服务。目前会员实现的是自建机房与虚拟机房的互备。

2.运维平台

会员打通了从DNS到虚拟机的资源信息，开发了运维平台，建立了一系列的监控指标和运维工具。为机房之间业务切换和日常运维提供支撑服务和工具，架构如图所示：

▌砥砺前行与未来展望

会员服务的高可用方案随着公司的网络与计算设施部门的工作进展而不断优化升级，基础设施部门提供了更多的能力和服务，方案也更整洁和强大。未来的重点将放在提升资源利用率，优化会员服务，同时保证业务的故障恢复在用户无感知的情况下进行。

END