重构国内游戏账号登录系统的思考和实践

本期作者

背景


账号登录系统,作为游戏发行平台最重要的应用之一,在当前的发行平台的应用架构中,主要承载的是用户的账号注册、登录、实名、防沉迷、隐私合规、风控等职责。合规作为企业经营的生命线,同时,账号登录作为在线链路转化的第一站,因此账号登录系统的稳定性,一直面临极高的要求。

出于稳定性需要,游戏发行平台在很早期就实践了两地三中心的多活架构。目前以公司公司机房为中心,同时在华东公有云和华南公有云,实现了两地三中心部署方案。依托公有云的主要考量因素在于,早期公有云提供的快速弹性和按量付费的能力,能够高效的承接游戏业务方的发展诉求;其次,对于华南地区的选择,也是优先考虑重要合作方所处的地理位置。

基于稳定性、效率、成本的多方考量,最终实现了公司机房、华东公有云A、华南公有云B的混合云架构。混合云架构带来便利的同时,也存在普遍的挑战,其中最显著在于两个方面:

其一、数据架构,数据在云端存储的存在的泄露风险。在具体实施层面,数据架构的差异化,将会导致底层的领域服务所能交付的API必定存在差异,主要差异体现在API的能力范围。比如,bilibili授权登录等能力,云上机房是无法做到实际支持的,服务端只能将相关请求转发至公司机房处理。

其二、PaaS平台的差异。公司基础架构在数据库管理平台、KV数据管理平台、消息队列等产品支撑已相当成熟,但早期在公有云的应用部署只能依托云原生的能力。这导致在底层的依赖上,原本需要建立一个标准防腐层,屏蔽具体的实现差异,但因为业务进度的需要,导致有所折中欠缺。

由于存在以上两个显著的挑战,项目进展等因素的考虑,最终演变的应用架构如下,也因此账号登录系统,在公司机房和公有云机房演变出了两套代码仓库(login-idc-api / login-cloud-api)。


游戏账号登录应用的两套代码,迭代至今已近7年。当前应用,虽然在主观上理解已经迭代趋于稳定,但是基于最近一年完成的迭代版本统计,全年迭代版本超过10次,版本平均耗时接近4周,包括设计、开发、测试、上线。双代码仓库导致的设计、开发、测试,部署平均耗时增加了30%~40%。其次,在双代码仓库,且依赖Spring等核心组件版本较低的情况下,对齐公司基础架构的各项产品,可预见工作量的前提之下,该系统的重构工作,已经到了不得不行的地步。


挑战


为稳定性诉求极高、迭代长久的系统发起重构,需要巨大勇气,得失于转瞬之间。

  1. 重要性:承载千万MAU,L0不可降级链路;支撑113个SDK版本(采样周期:2024/02/15 - 2024/03/15)

  2. 稳定性:重构过程中SLO 4个9的约定,必须在执行之前规划完成执行细节和过程,全面又不失细致;

  3. 复杂度:业务本身内在的复杂度,7年来的高速发展,积累的大量技术债。


价值


1.效率:开发效率提升50%,迭代效率提升30%-40%

2.成本:节省人力(预期当前系统的生命周期至少5年)

3.质量:

  • 代码圈复杂度:降低40%;

  • 内网调用去SLB依赖,核心链路接口RT 99.9Line 提升31.5%

4.文化:践行“极致执行”的价值观。


实践:如何实现重构?


战略方向


方案一、放弃现有的两地三中心,账号登录全部统一到公司标准,不依赖云厂商。该方案作为未来的长期方向,完全回公司部署符合公司长期战略规划,难点在于发行平台的应用架构,目前绝大多数服务还是重点依赖公有云,短期内不具备独立完成的可行性。

方案二、推动主站账号团队,打通公司和公有云的数据架构,实现领域能力的对等,但存在数据安全风险,考虑到项目收益和跨团队的工作成本,并非当前最高ROI的选择。

方案三、将双代码仓库中,有关于数据架构和PaaS的差异,以重构的办法实现兼容,达到最终的代码仓库统一。


思考过程


重构的前提


回顾Martin Flower有关重构的著作《重构 改善既有代码的设计》一文中,将”重构“以名词、动词两种方式定义如下:


重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。

重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。


这本关于重构的经典,在两种定义方式中,提到了3个关键概念,”调整“、”结构“、”不改变软件可观察行为“。这3个关键词组合起来,约等于行动指南。”不改变软件的可观察行为“作为前提,如何理解可观察行为,Martin并未在技术和业务上做过明确的定义,因此在这个概念的理解上,不免要多一些执行者的个人理解和思考。

如果把应用架构视为当前的结构,对于“可观察行为”的理解,从以下几个角度尝试去思考:

1.系统职责,前后端分离的应用架构之下,交付这些职责的API是一类可观察的行为;

2.系统依赖项,是一类可观察的行为,包括两个大部分:

  • bilibili账号的领域服务、游戏发行的领域服务、第三方服务(比如:极验服务提供商)

  • PaaS基础架构(公司的数据库、KV数据系统、消息队列等等;公有云的云MySQL、Redis、Kafka等等)

3.系统的横向服务。从分层架构的层次上来说,当前定位是应用服务层BFF,本不应该出现较大的横向影响,但是过往高速演进的过程中,承载了部分领域服务的职责(比如:查询游戏信息、查询活跃游戏、查询用户信息等),因此姑且对于这一类概括为横向的影响。


形形色色的差异


当前应用架构下,双仓库在逻辑模块、应用内分层(J2EE的3层模型)的特点,展示如图:


在不可变的前提之下,试图通过对齐双仓库代码差异,以求得统一的思路,单从Service这一层来说(其依赖的bilibili账号服务API超过80个),理解起来已足够让人头大,其变更风险也是极其巨大,更何况还有JDBC ORM、Redis在技术选型和使用约束上的差异。如此风险再加上即将投入较大的工作量,势必提案困难重重。基于静态的模块和应用内代码分层来看,这巨大的差异看似是无法“暴力”抹平。


消失的复杂度


柳暗花明时刻,来源于应用运行时的一个事实:“生产环境多次高可用切流”。这个事实不仅实现了对SDK上游异地多活的承诺,而且经过了生产环境的多次验证。简而言之,双仓库在Controller、Service这两个最业务逻辑最复杂,技术债积累最多的分层,虽各有千秋,但殊途同归。

由此推理,重构过程中的最大的认知注意力负担,可以直接从这两层忽视。这两层注意力的移除,同时也利好DB和Redis的兼容工作量,作为基础架构中最重要的两个组件,完全无需再关注各类RedisTemplate/Jedis,Key命名、JdbcTemplate/Mybatis 、SQL的之间的逻辑差异,因为他们只是Controller和Service最终呈现出来的一部分。


在混沌中聚焦


SDK API链路:由于Controller、Service复杂度的消失,那么剩余的不可变的可观察行为,就只集中在DAO。DAO差异的本质来源于混合云部署架构的挑战(数据架构、PaaS差异),那么实现策略也就清晰了,在DAO层基于运行时ZONE来标识依赖的bilibili账号API调用即可。参考六边形架构,对于外部依赖和业务逻辑的隔离方式,实现核心业务逻辑对于外部API和PaaS解耦,以此降低变更侵入的影响面。


PaaS的差异在业务逻辑层Service(或者少量的Controller)已经被消化,因此无需再考虑逻辑上的差异,只需关注框架和数据库的版本兼容性。

领域类和通知类API链路:这条链路虽然不是核心,但这是混合云数据架构差异的体现。生产环境的调用集中在公司机房,能力”较小“的公有云应用,向公司应用融合靠拢,也正因如此,统一之后的代码仓库是以公司机房代码仓为基准。

转发类API链路:这条链路差异化的本质也是来源于混合云部署的数据架构差异,在当前的融合方案中无法解决,因此只能沿用现有的转发策略,但转发后续可向上移交至API GW实现,这个已在计划当中。


具体实现


公司机房原仓库为基准,在公有云A/B可用区部署,可用区选择与当前两地三中心保持一致。依赖的DB Schema在三机房原本就相同,因此可直接复用已有的DB实例。Redis,因其均有读写操作,避免灰度过程对于线上应用的数据污染,因此部署单独的Redis集群用于数据隔离,待完成灰度之后,一并下线原应用和原Redis集群。


数据验证


产品视角


  1. 基于用户维度,验证比对新老集群的数据写入和查询;

  2. 基于游戏维度,验证比对新老集群的数据写入和查询;

  3. 生产环境SDK,基于测试域名,实现核心SDK产品回归验证,覆盖全量用例;

  4. 其他非SDK API,实现全量的单测覆盖,基于接口实现验收。


数据视角


  1. 数据库:基于Job任务,实现源与目标数据源内容比对;

  2. 缓存:纯缓存场景,灰度期间隔离部署,回滚后不影响业务逻辑。缓存未命中直接远程调用;

  3. 埋点/报表:基于灰度过程观察游戏维度的报表趋势,并与过往数据进行比对。


发布方案


发布计划设计,严格遵守公司安全生产要求:可灰度、可观测、可恢复。


可灰度


灰度过程一共分为两个大步:


Step1


在公司机房执行灰度部署,分批部署导入生产流量,发现异常立即回滚。


Step2


在公有云A执行全量发布,但未接流;通过SLB规则配置,基于域名、规则的重要性、API的量级(调用量/周)制定规则级的SLB发布计划。公有云B部署同样重复此步骤。


可观测


观测的主要维度:业务和SLO、日志、性能


观测1:原公有云A应用流量切流后分布和成功率



观测2:新公有云A应用流量切流后分布和成功率



观测3:新公有云A应用错误码分布




观测4:新公有云A应用API性能




观测5:新公有云A应用JVM性能




可恢复


1.公司机房应用执行灰度部署,如遇异常立即回滚,且不产生脏数据

2.新的公有云A/B应用,通过SLB基于规则分批发布,如遇异常立即回滚,回滚后流量指向原有对应机房服务集群,Redis写产生的脏数据不影响回滚后业务逻辑

3.新的公有云可用区,申请单独的Redis实例,用于隔离不同代码仓库,不同Key命名风格的数据,避免回滚过程中脏数据,对于原可用区服务的影响。


参考资料


  • 《B站安全生产专项建设实践》 https://mp.weixin.qq.com/s/tj1PEUWAyRZ1QzeW_oCWfg

  • 《重构 改善既有代码的设计》Martin Flower

  • 《Complexity Has to Live Somewhere》https://ferd.ca/complexity-has-to-live-somewhere.html



这是一个从 https://www.bilibili.com/read/cv33889286/ 下的原始话题分离的讨论话题