本期作者
背景
账号登录系统，作为游戏发行平台最重要的应用之一，在当前的发行平台的应用架构中，主要承载的是用户的账号注册、登录、实名、防沉迷、隐私合规、风控等职责。合规作为企业经营的生命线，同时，账号登录作为在线链路转化的第一站，因此账号登录系统的稳定性，一直面临极高的要求。
出于稳定性需要，游戏发行平台在很早期就实践了两地三中心的多活架构。目前以公司公司机房为中心，同时在华东公有云和华南公有云，实现了两地三中心部署方案。依托公有云的主要考量因素在于，早期公有云提供的快速弹性和按量付费的能力，能够高效的承接游戏业务方的发展诉求；其次，对于华南地区的选择，也是优先考虑重要合作方所处的地理位置。
基于稳定性、效率、成本的多方考量，最终实现了公司机房、华东公有云A、华南公有云B的混合云架构。混合云架构带来便利的同时，也存在普遍的挑战，其中最显著在于两个方面：
其一、数据架构，数据在云端存储的存在的泄露风险。在具体实施层面，数据架构的差异化，将会导致底层的领域服务所能交付的API必定存在差异，主要差异体现在API的能力范围。比如，bilibili授权登录等能力，云上机房是无法做到实际支持的，服务端只能将相关请求转发至公司机房处理。
其二、PaaS平台的差异。公司基础架构在数据库管理平台、KV数据管理平台、消息队列等产品支撑已相当成熟，但早期在公有云的应用部署只能依托云原生的能力。这导致在底层的依赖上，原本需要建立一个标准防腐层，屏蔽具体的实现差异，但因为业务进度的需要，导致有所折中欠缺。
由于存在以上两个显著的挑战，项目进展等因素的考虑，最终演变的应用架构如下，也因此账号登录系统，在公司机房和公有云机房演变出了两套代码仓库(login-idc-api / login-cloud-api)。
游戏账号登录应用的两套代码，迭代至今已近7年。当前应用，虽然在主观上理解已经迭代趋于稳定，但是基于最近一年完成的迭代版本统计，全年迭代版本超过10次，版本平均耗时接近4周，包括设计、开发、测试、上线。双代码仓库导致的设计、开发、测试，部署平均耗时增加了30%~40%。其次，在双代码仓库，且依赖Spring等核心组件版本较低的情况下，对齐公司基础架构的各项产品，可预见工作量的前提之下，该系统的重构工作，已经到了不得不行的地步。
挑战
为稳定性诉求极高、迭代长久的系统发起重构，需要巨大勇气，得失于转瞬之间。
-
重要性：承载千万MAU，L0不可降级链路；支撑113个SDK版本（采样周期：2024/02/15 - 2024/03/15）
-
稳定性：重构过程中SLO 4个9的约定，必须在执行之前规划完成执行细节和过程，全面又不失细致；
-
复杂度：业务本身内在的复杂度，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集群。
数据验证
产品视角
-
基于用户维度，验证比对新老集群的数据写入和查询；
-
基于游戏维度，验证比对新老集群的数据写入和查询；
-
生产环境SDK，基于测试域名，实现核心SDK产品回归验证，覆盖全量用例；
-
其他非SDK API，实现全量的单测覆盖，基于接口实现验收。
数据视角
-
数据库：基于Job任务，实现源与目标数据源内容比对；
-
缓存：纯缓存场景，灰度期间隔离部署，回滚后不影响业务逻辑。缓存未命中直接远程调用；
-
埋点/报表：基于灰度过程观察游戏维度的报表趋势，并与过往数据进行比对。
发布方案
发布计划设计，严格遵守公司安全生产要求：可灰度、可观测、可恢复。
可灰度
灰度过程一共分为两个大步：
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
