分享主要分为五个部分:整个平台建设的里程碑,帮助大家对建设过程有个整体认识;整体设计目标,描述一下我们的整体设计思路;关键技术实现方案,主要是关键组件的切换方式;平台建设完成之后的收益情况;未来陆金所多活机房建设的远期规划。
2012 年,陆金所开始对外提供服务,前后差不多经历了 7 次机房搬迁,截止到 2017 年底,陆金所才真正完成了同城双活的基础设施建设工作。2018 年初,我们整个网站架构完成了多活改造。2018 年 2 月,陆金所真正以双活形态对外提供相关服务。
为了应对未来双活及多活的运营场景和相关挑战,我们启动了切换平台建设。整个平台建设周期约为 3 个月,基于陆金所自研的 DevOps 流水线及自动化运维技术体系。2018 年 6 月,第一期平台功能开发和上线工作完成,2018 年 7 月,通过非核心业务、覆盖 5% 相关组件的切换场景验证了整个切换平台。
至此之后,我们每月会有一次例行的切换演练过程,并且从一些非核心、非关键的业务逐步演练覆盖到全部的组件和服务。我们在半年的时间里,进行了 6 次比较大的切换,2018 年 12 月,陆金所正式完成了覆盖全部服务的切换验证工作,12 月底,通过切换平台,陆金所完成了第一次主辅机房的正式切换,整体耗时 4 分 38 秒,符合预期。但是我们也从中发现了一些问题,所以 2019 年 3 月,我们在此基础上重新迭代了一个版本,将整体耗时从 4 分 38 秒缩短为 4 分 5 秒。
接下来,介绍一下陆金所的整体设计目标。
众所周知,陆金所现在大部分的技术框架都是在云计算、容器、微服务等技术环境下进行的。所以,数据中心多活或双活运营的核心问题都是在解决有状态服务的高可用管理。陆金所把有状态服务所在的机房称为主机房,相对应的,不是主服务所在的机房就是辅机房。
因此,在切换平台建设初期,我们就把平台的使用场景和建设目标确定为当主机房发生大面积服务故障时,能够通过切换平台在 5 分钟之内完成主机房内各个组件和服务的主辅角色切换,从而达到快速故障恢复的目标。
陆金所发展到现在已经是个很庞大的系统,包含超过 1400 个子应用,120 套 DB 实例,300 个大网关,3000 个 Job 调度,非自研、非外购的不能做双活的主备系统,基于状态的核心组件,例如分布式锁、文件系统等等。基于这样庞大的应用系统,想要在 5 分钟之内完成主机房全部组件的角色切换,难度是显而易见的。
我们是通过下面八个字来解决这些难题的:大而化小,分而置之。我们的整体目标是在 5 分钟之内完成整个机房服务的角色切换,而这个大目标又可以拆解为几个关键的核心指标:时效性、独立性、健壮性和数据闭环。然后再把这些关键指标逐层分解,下派到需要服务切换的团队,由他们进行对应指标达成率的细化设计、迭代式的优化和改进,通过小演练、大演练、小切换和大切换的方式,不断迭代优化实现整体平台设计目标。
接下来,介绍一些具体的实现技术方案,我会抽取几个比较有代表性的核心组件。
GTM 用户引流方案,GTM 是一个依托于 F5 设备的互联网域名管理平台,我们根据这套解决方案又进行了二次封装和开发,开发了一套基于互联网用户流量的白屏化工具,然后根据这个工具对互联网域名