服务器 频道

领域化、中台化和多Region化,携程账号系统演进之路

  一、前言

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

  本文分享的账号系统,指的是提供用户账号管理、登录认证相关能力的系统。介绍了携程在不断发展的过程中,账号系统在领域化、中台化和多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部署的账号中台,这是业务发展和互联网技术进步的一种体现和必然趋势。

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

0
相关文章