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相关的事，如果你面临的挑战是机器数量减少一半，性能提升一倍，全链路异步化架构可能会对你有所帮助。