高德亿级流量接入层服务的演化之路

2019 杭州云栖大会上，高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆，听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布在「高德技术」公众号上，本文为其中一篇。

2019 杭州云栖大会高德技术专场讲师系列：

• 《视觉智能在高德地图的应用》
  

• 《高德在提升定位精度方面的探索和实践》
  

阿里巴巴资深技术专家孙蔚在高德技术专场做了题为 《高德亿级流量接入层服务的演化之路》 的演讲，主要分享了接入层服务在高德业务飞速发展过程中，为应对系统和业务的各方面挑战所做的相关系统架构设计，以及系统在赋能业务方面的思考和未来规划。

以下为孙蔚演讲内容的简版实录：

高德地图的 DAU（日活）已经过亿，服务量级是数百亿级。高德的应用场景，比如实时公交、实时路况、导航、司乘位置的同时展示等，对延迟非常敏感。如何做到高可用、高性能的架构设计，高德在实践中总结了一套解决方案。

今天主要分享三个方面的内容：

• 接入层定位思考与挑战

• 高可用、高性能的架构设计

• 高德服务端的思考及规划

一、接入层定位思考与挑战

首先介绍下 Gateway，从架构上看，Gateway 在中间位置，上层是应用端，下层是引擎，例如驾车引擎、步导引擎等等。目前已接入 80+应用，500 多个 API 透出，QPS 峰值 60W+。

从 Gateway 的定位来思考，作为网关，最重要的就是稳定，同时能提效和赋能。一句话概括：如何在资源最少的情况下，在保证稳定的前提下，以最快速度帮助业务的达成，这就是服务端的定位。

高德的网关设计挑战在于每天数百亿级的流量过来，场景对延迟又特别敏感。举个例子，很多开发者和应用都在使用高德定位服务，定位服务架构挑战 5 毫秒内需返回。

为了解决这些问题，高德做过一次比较大的系统架构升级，主要做了几方面的工作。首先是 流式、全异步化改造。机器数量减少一半，性能提升一倍，通过这个架构升级达到了。

其次是 加强基础支撑能力建设，为配合引擎提效，做了接口聚合、数据编排和流量打标与分流。

此外，为了提供服务稳定性，同时提升单元性能，做了 高德单元化网关解决方案。最主要是方便其他业务快速实现单元化。

二、高可用、高性能的架构设计

重构前比较严重的问题是服务性能低，BC 服务器综合性能在 1200QPS。稳定性风险比较高，特别是网络抖动，如何保证整个系统的稳定性，这可能是最大的挑战。所以，对于整个架构的思考，最主要的事情是做异步化。

高德接入层网关演进过程主要经历了 3 个阶段：

1. 异步+Pipeline 架构改造

1）流式、全异步化架构

如上图 Pipeline 的架构模型，我们在 2016 年开始做，那时候还没有很流行，我们自己实现了异步认知，再加入 Pipeline 架构模型。

采用流式、全异步化的架构模型，使用 Tomcat nio+Async Servlet + AsyncHttpClient。Gateway QPS 峰值 60W，服务 rt 控制在 1ms 左右。

整体服务是 Pipeline 架构，在服务的上行和下行关键节点进行了扩展点设计，利用该扩展点设计，解决了接口的历史包袱问题。使用到的相关工具类库也要注意异步性能问题，在全链路异步化的时候，最核心的是相关的工具，也必须解决异步化的问题。要不然就是内部有阻塞，基本上会带来整个链路的阻塞。

收益：单机性能提升了 400%，服务延迟低于 2 毫秒，现在基本上都是在 1 毫秒左右。

2）反应式编程探索：Vert.X && Webflux

我们也做了反应式编程，主要用 Vert.X。我们一些同步调用的场景需要修改为异步，他比较特殊，RPC 的依赖比较少，主要是同步依赖 RDB、Mongodb、Http 接口等，这时候我们用 Vert.X 来做 IO 任务及数据编排，Http 异步调用还是用的 AsyncHttpClient。最后的效果，QPS 大概在 5 万左右，RT 是 22 毫秒左右。

高德现在的打车业务中有一个业务场景，服务里要调服务 A、服务 B、服务 C、服务 D、服务 E、服务 F，最多的时候要调 27 个服务，还要做业务逻辑。用 Webflux 更合适一些，不仅可以做到异步化改造，还可以用它做复杂业务逻辑编排。使用 Webflux 可以直接使用 Netty 处理链接、业务层用 Reactor 交互，全反应式编程，IO 线程与业务线程互不阻塞，最大限度压榨 CPU 资源。

在这个项目里，反应式编程最终达到的效果，QPS 提升了 3 倍，RT 降低 30%。

2. API 聚合、数据编排与打标分流

面对新的业务，压力越来越大，并且每次迭代的速度要求越来越快。目前 API 数量超过 500+，接口数据项超过 400。对于 API 的定制化、复用，怎么解？就是通过 API 聚合和数据编排。

打标分流是另外一个挑战，随着业务的发展，很多服务都需要做架构升级，需要做重构，算法和模型也需要不断的调优，这时候对于业务或者研发来说，对业务参数进行打标和分流，可以降低风险。

3. 高德单元化网关

1）高德单元化网关：路由策略

对于 业务异地多活、单元化需求，我们做了单元化路由的解决方案，这里最核心的，给业务提供的能力是：当有用户请求过来时，能够实现就近接入能力，尽量减少跨单元调用。

单元路由主要帮助业务解决异地多活的能力，我们支持的路由策略，主要分为两种：第一种是基于路由表，第二种是基于取模策略。如果你的应用对就近接入需求比较强烈，对延迟敏感，就可以用基于路由表策略。如果是对多单元同写敏感度高的场景，用取模策略更合适。两种我们都支持。

2）高德单元化网关：路由计算

上图是我们做的路由计算核心逻辑图。具体而言注意以下几点：1）单元映射，用户划分分组、分组指向单元映射的方式完成用户到单元的绑定关系，单元切换时只切换分组到单元的映射关系；2）路由计算，多数情况下通过 BloomFilter 计算所在分组，新用户则会采用取模策略计算所在分组；3）跨单元路由，BloomFilter 的误命中会导致跨单元路由；新用户采用取模策略也将导致跨单元路由，直至路由表更新；4）数据结构，基于性能、空间、灵活性和准确率方面的综合考虑，在 BloomFilter 、BitMap 和 MapDB 多种方案中，选择 BloomFilter，万分之几的误命中率导致的跨单元路由在业务可接受范围内。

3）高德单元化网关：分组优化

这个是目前正在迭代做的网关虚拟分组优化，分为 3 单元*4 片，每个单元分成四个片。

目标提高单元划分的准确性，同时每次访问需要 7 次计算优化为 3 次，同时解决以前如果发现单元出现问题流量只能全切，现在可灰度切量。

目前使用的案例有云同步、用户等。用户单元化的案例，最终的收益是，整个单元计算耗时小于 2 毫秒，跨单元路由比例低于 3%。

三、思考及规划**

Gateway 现在是集中化的场景，怎么变成分布式的解决方案？

这方面我们也做了尝试。分布式网关一般有两种实现路径：第一种是做 SDK，第二种是做边车或服务网格的方式。SDK 方式的分布式网关我们已经在部分场景使用，缺点是对异构支撑困难，和应用的隔离性不好，好处是开发比较快，目前每天也有过百亿的请求在访问。

边车或者服务网格其实是我们架构的终局，他能解决异构、应用系统隔离性等问题。因为：

• Gateway Sidecar 与业务应用运行于同服务器的独立进程，既具有分布式部署优势又具备较好的隔离性；

• Gateway Control Manager 负责管理分布式 Gateway Sidecar，相当于 Service Mesh 的控制面，主要负责网关配置和元数据管理、服务高可用以及统计打点、异常监控和报警等。

服务网格优势是去中心化的分布式部署方式，天然就具备高可用性和水平扩展性，无单点和性能瓶颈问题，缺点是不太适合实现聚合 API 的实现。服务网格我们目前是基于蚂蚁 SOFA 来做，主要用来解决异构 RPC 调用的问题。

最后给个建议，根据实际经验，大家如果在做服务或 Gateway 相关的事，如果你面临的挑战是机器数量减少一半，性能提升一倍，全链路异步化架构可能会对你有所帮助。