行业案例：高德服务单元化方案和架构实践.pdfVIP

作者：高德地图技术人员

一、为什么要做单元化

单机房资源瓶颈

随着业务体量和服务用户群体的增长，单机房或同城双机房无法支持服务的持续扩容。

服务异地容灾

异地容灾已经成为核心服务的标配，有的服务虽然进行了多地多机房部署，但数据还是只在中心机房，

实现真正意义上的异地多活，就需要对服务进行单元化改造。

二、高德单元化的特点

在做高德单元化项目时，我们首先要考虑的是结合高德的业务特点，看高德的单元化有什么不一样的诉

求，这样就清楚哪些经验和方案是可以直接拿来用的，哪些又是需要我们去解决的。

高德业务和传统的在线交易业务还是不太一样，高德为用户提供以导航为代表的出行服务，很多业务场

景对服务的RT要求会很高，所以在做单元化方案时，尽可能减少对整体服务RT的影响就是我们需要重

点考虑的问题，尽量做到数据离用户近一些。转换到单元化技术层面需要解决两个问题:

1.用户设备的单元接入需要尽可能的做到就近接入，用户真实地理位置接近哪个单元就接入哪个单元，

如华北用户接入到张北，华南接入到深圳。

2.用户的单元划分最好能与就近接入的单元保持一致，减少单元间的跨单元路由。如用户请求从深圳进

来，用户的单元划分最好就在深圳单元，如果划到张北单元就会造成跨单元路由。

另外一个区别就是高德很多业务是无须登录的，所以我们的单元化方案除了用户ID也要支持基于设备

ID。

三、高德单元化实践

服务的单元化架构改造需要一个至上而下的系统性设计，核心要解决请求路由、单元封闭、数据同步三

方面问题。

请求路由：根据高德业务的特点，我们提供了取模路由和路由表路由两种策略，目前上线应用使用较多

的是路由表路由策略。

单元封闭：得益于集团的基础设施建设，我们使用vipserver、hsf等服务治理能力保证服务同机房调

用，从而实现单元封闭(hsfunit模式也是一种可行的方案，但个人认为同机房调用的架构和模式更简洁

且易于维护)。

数据同步：数据部分使用的是集团DB产品提供的DRC数据同步。

单元路由服务采用什么样的部署方案是我们另一个要面临的问题，考虑过以下三种方案：

第一种SDK的方式因为对业务的强侵入性是首先被排除的，统一接入层进行代理和去中心化插件集成两

种方案各有利弊，但当时首批要接入单元化架构的服务很多都还没有统一接入到gateway，所以基于现

状的考虑使用了去中心化插件集成的方式，通过在应用的nginx集成UnitRouter。

服务单元化架构

目前高德账号，云同步、用户评论系统都完成了单元化改造，采用三地四机房部署，写入量较高的云同

步服务，单元写高峰能达到数w+QPS(存储是mongodb集群)。

以账号系统为例介绍下高德单元化应用的整体架构。

账号系统服务是三地四机房部署，数据分别存储在tair为代表的缓存和XDB里，数据存储三地集群部

署、全量同步。账号系统服务器的Tengine上安装UntiRouter，它请求的负责单元识别和路由，用户单

元划分是通过记录用户与单元关系的路由表来控制。

PS：因历史原因缓存使用了tair和自建的uredis(在redis基础上添加了基于log的数据同步功能)，目前已

经在逐步统一到tair。数据同步依赖tair和alisql的数据同步方案，以及自建的uredis数据同步能力。

就近接入实现方案

为满足高德业务低延时要求，就要想办法做到数据(单元)离用户更近，其中有两个关键链路，一个是通

过aserver接入的外网连接，另一个是服务内部路由(尽可能不产生跨单元路由)。

措施1：客户端的外网接入通过aserver上的配置，将不同地理区域(七个大区)的设备划分到对应近的单

元，如华北用户接入张北单元。

措施2：通过记录用户和单元关系的路由表来划分用户所属单元，这个关系是通过系统日志分析出来

的，用户经常从哪个单元入口进来，就会把用户划分到哪个单元，从而保证请求入口和单元划分的相对

一致，从而减少跨单元路由。

所以，在最终的单元路由实现上我们提供了传统的取模路由，和为降延时而设计的基于路由表路由两种

策略。同时，为解无须登录的业务场景问题，上述两种策略除了支持用