阅读 486

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

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

         (关注高德技术,找到更多出行技术领域专业内容)       复制代码
关注下面的标签,发现更多相似文章
评论