一、前言

　　在互联网早期时代，账号系统的功能非常广泛，包括账号管理、登录认证相关能力以及维护各类用户信息，比如头像、昵称、积分、等级等。随着业务的发展，每个功能逐渐分化出自己的需求和架构侧重点，独立出各自的领域服务也成了业界共识。

　　本文分享的账号系统，指的是提供用户账号管理、登录认证相关能力的系统。介绍了携程在不断发展的过程中，账号系统在领域化、中台化和多Region化方向上的演进、探索和一些思考。

　　二、领域化

　　微服务迅猛发展阶段，账号系统分裂出了很多应用。比如，专门支持三方登录的应用，专门保存账号实名信息的应用，针对不同平台的接入应用。一开始确实可以满足迅速开发上线的需求，当应用裂变到几十个的时候，应用分层不合理，领域逻辑不内聚带来的问题逐渐显现出来：

　　1）用户请求会经历多个应用之间的RPC调用，性能和稳定性受影响。

　　2）操作无法原子性，易出现脏数据。

　　3）应用过多，开发、运维、测试范围大，影响效率。

　　领域化是对账号系统的全面重构，有以下两个目标：

　　1）合理划分领域，逻辑内聚。

　　2）改造需要对业务透明。

　　2.1 全面梳理，重新划分领域　　

　　账号系统功能主要分为3个类型：

　　1）核心功能：负责管理和维护账号系统的核心功能和数据。由于涉及到用户的核心数据，相关插入、变更接口只可暴露给业务BFF层。

　　账号领域：包括账号信息查询；账号注册/注销；手机、邮箱、三方等数据的绑定/解绑；openid的生成；密码的管理和认证等功能。

　　登录态领域：负责登录态生成、验证、续期、踢出、过期删除等功能。

　　日志监控领域：负责记录账号相关业务埋点和日志。

　　2）辅助功能：不仅可以被账号相关业务依赖，也可以开放出去供类似业务场景的接入。

　　Token（临时凭证）领域：负责Token的生成、验证、过期删除等功能。

　　验证码领域：负责验证码生成、发送、验证等功能。

　　3）接入功能：负责账号相关的业务功能接入，包括端上接入和内网服务接入。

　　BFF层：主要负责各类业务逻辑的组合（注册、登录、改绑手机等）以及接入方权限的控制。

　　前端UI、SDK：前端显示UI以及提供出去供业务接入的SDK。直接对接BFF层。

　　其他一些业务中必须依赖的模块，如风控模块，依赖公司相应团队提供的能力即可。

　　2.2 读写对比，透明改造

　　账号系统非常核心，上游是公司的各类业务，依赖方非常多，牵一发而动全身。同时，业务也在急速发展，不会停下来等待系统的改造。对账号系统的改造无疑是在快速开动的汽车上更换轮胎。因此，对账号系统的改造需要一套完整的比对流程，需要满足两个条件：

　　1）完整性。比对需要覆盖100%的场景，避免场景遗漏。

　　2）隔离性。比对需要在离线集群和存储上进行，避免对在线系统造成影响。同时，需要屏蔽掉离线集群不必要的对外请求，以免对下游造成影响（包括RPC调用，消息，监控数据等）。

　　在此基础上，完成了账号系统的读写比对流程：

　　读对比：转发-比对。利用镜像流量的能力，将镜像流量导入离线Old代码集群。Old代码集群在处理流量的同时，会转发到离线New代码集群，完成接口返回数据比对。　　

　　写比对：录制-回放-比对。提前录制生产环境的流量，记录输入、输出和发出的消息等数据；分别部署New/Old代码离线集群和两套相同的离线DB（里面数据为同一时间点的Snapshot）；将录制好的流量（DB Snapshot时间点后）回放到两套集群上，比对输出、存储、发出来的消息等数据，确保New/Old集群和录制的结果三方一致。　　

　　完成了领域化改造后，核心数据的变更沉淀到对应的领域服务中，相关操作可以满足原子性，避免脏数据的产生；应用减少以及引入BFF层，减少了应用间，用户端和服务端的交互次数，提升了系统稳定性，提升了开发、运维、测试的效率。

　　三、中台化

　　和大部分互联网公司一样，随着集团的发展，会出现不同的品牌，需要一套独立的账号体系。也有业务团队会将自己研发的账号系统交给账号团队统一管理。如果账号系统没有做好中台化的准备，势必会在接入的过程中手忙脚乱。不仅代码中会存在大量的判断逻辑，接入时间也会很长，甚至可能无法满足业务的需求。中台化的改造需要考虑以下三点：

　　1）降低改造复杂度

　　减少系统的架构改造复杂度

　　降低业务接入的复杂度

　　2）配置化

　　将需求抽象为功能，减少对业务需求的定制化开发

　　简单配置即可快速接入

　　3）提供多样化的接入方式，以满足不同业务方的接入需求

　　3.1 降低改造复杂度

　　中台化改造过程中，账号体系ID是最核心的概念。

　　标志着账号所属的业务体系，相互之间隔离

　　控制账号体系的策略和权限

　　路由每一个账号体系对应的存储

　　因此，对于账号相关查询请求，如果不知道账号所在的体系ID，就无法找到对应的存储。要么进行全存储查询，要么需要一个大表存储UID到体系ID的映射关系，这会引入额外的依赖，提高成本的同时，也会使得系统变得复杂。

　　另外，要求所有上游新增一个参数需花费大量的资源推动。　　

　　UID全局唯一，并且通过编码区分不同的体系ID，可以大大降低改造和接入的复杂度。

　　新接入的账号体系，通过UID的编码可以快速判断账号体系ID。

　　对于存量UID，默认属于最早的账号体系。

　　同时，UID全局唯一也可以提高排障和TS时的效率（不用反复确认某一个UID属于哪个账号体系）。

　　当然，一些不通过UID进行的查询接口，如通过手机号查询账号的场景，还是需要业务方传递体系ID，但通过这样的设计已极大的缩小了需要改造的范围。

　　3.2 配置化

　　账号中台化后主要提供以下能力：

　　1）账号管理：管理账号的完整生命周期，包括注册，验证，注销。支持账号绑定手机号，邮箱，第三方账号，以及对应属性的变更、解绑操作。管理账号密码，支持多种加密逻辑。管理Oauth相关数据。

　　2）多样化登录方式：包括账号密码登录，手机验证码登录，手机一键登录，扫码登录，社交账号登录等登录方式。特别的，在社交账号登录方式中，账号系统已完成了与多个平台的对接，常见的比如微信、支付宝、QQ、微博、华为等。

　　3）登录态管理：包括登录态的生成、验证，登录态信息维护，按需续期、踢出等功能。

　　4）安全&监控体系：账号中台具有完善的日志体系，并已完成对接前端滑块和后端实时风控。

　　在中台化建设的过程中，虽然已经全量梳理了中台应该提供的能力，仍然会有新的需求需要支持。在接到新的需求，而现有的功能无法支持的时候，不要急于解决本次需求，需要思考本次需求涉及的具体功能，从而在实现的过程中避免定制化逻辑，沉淀为中台的新能力。

　　比如，某次需求为：一个账号体系全平台需要保证登录态是唯一的，即新的登录产生后，会踢出之前的登录态。可以抽象为需要中台提供对某一个账号体系的登录态数量进行控制。进一步的，可以按照平台（App、小程序、H5等）分别进行控制。　　

　　中台化建设完成后，不同的功能都可以通过配置进行控制，也可以对每一个功能进行细节上的调整。同一体系的配置放置在同一配置文件中，便于维护。如果没有特别的需求，直接使用默认配置接入即可。　　

　　3.3 多样化接入方式

　　为了适应业务多样化的接入需求，中台提供了3种接入方式：

　　1）UI接入：在携程的主Web站点、App和小程序，统一使用中台开发的前端界面，业务方按需拉起。

　　2）前端SDK接入：有少量定制需求，如显示的LOGO需要调整，协议需要变更等，可以使用中台的前端SDK接入。此SDK已包含所有的流程逻辑，接入时仅需替换掉对应的元素。

　　3）后端对接：若业务方有过多的与业务藕合的逻辑，则不适合将逻辑放在中台。此时，业务方可以自行开发一层BFF，利用中台BFF层和辅助系统（验证码、Token）提供的能力，组合出合适的业务逻辑。

　　中台化改造完成后，新账号体系需要申请接入时，仅需选择需要的能力，中台通过调整配置，小时级即可完成接入。大大减少了新增一套账号体系的支持成本。

　　四、多Region化

　　两地三中心是近期比较热门的部署方案，一方面可以更好的应对城市级别的故障，另一方面可以更好的服务当地用户（例如，一个产品定位于服务西部用户，相应的应用和数据部署在西部城市可以提供更好的用户体验）。账号作为业务的基石，需要第一时间完成多Region部署，为各业务的部署做好准备。

　　多Region部署，账号中台制定了两个目标：

　　1）数据支持多Region部署，请求正确路由。结合业务需求，账号中台的应用和数据按需部署到指定的Region中，相应的用户请求需要准确的落到对应的Region。

　　2）架构需要同构部署，不能因为多Region部署引入开发和维护上的额外成本。

　　4.1 用户识别及请求路由

　　为了满足数据不同Region部署的需求，需要对用户数据进行识别并打标，利用公司DB数据同步组件（DRC）进行带过滤的双向同步（有的数据仅需要本Region使用，会过滤不进行同步），将数据部署到需要的Region上。后续的更新也由DRC进行同步。　　

　　在数据部署完成后，如何保证用户的请求落到了正确的Region。

　　方案一：每次请求经过网关的时候，网关进行一次用户到Region的映射查询，再将请求正确的路由到数据所在Region。这样的做法不仅会对请求引入一次额外的查询，还会使得网关这一及其关键的节点引入一个依赖，会影响整个网站的稳定性。

　　方案二：基于用户的数据一定完整的存在某一个Region的前提，在用户登录的时候，将之前识别时打上的标识下发到端上。请求的时候，网关只需对标识进行简单的路由配置，即可正确的路由到对应的Region。　　

　　4.2 多Region架构

　　在多Region的部署中，账号中台实现了同构部署。

　　1）网关层。利用网关根据用户登录下发的标识，将请求路由到正确的Region。

　　2）内网服务。通过完整的部署，内网请求在同一Region内完成，实现Region闭环，提高服务性能。同时也避免了DB多Region写入引起数据冲突的问题。

　　3）数据层。

　　DB数据。DB表结构完全一致，通过DRC根据用户标识进行带过滤的多向复制。

　　Redis缓存数据。本地使用，不需要同步。当一个Region的数据有变更的时候，其他Region接受DRC的同步消息，对本Region的Redis进行删除。　　

　　在这样的多Region部署架构下，可以根据业务的使用场景和数据部署需求，实现用户数据的单Region或多Region存储。

　　五、结语

　　账号系统从最开始的巨大单体应用中剥离出来，经历了若干年的演进，变成了现在支持多Region部署的账号中台，这是业务发展和互联网技术进步的一种体现和必然趋势。

　　当然，这种趋势也不会停止于此，账号系统的功能和架构必将继续演进，其他系统也同样如此。回望过去，基于现在，展望未来，敢为人先，为各业务的发展打好基石，这正是账号等基础系统的意义所在，技术团队的价值也存在于此。