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

行业动态 高德地图标注高德亿级流量接入层服务的演化之路已关闭评论阅读模式
地图标注

提交资料后最快2小时标注成功

点击上方蓝字,关注高德技术!

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

原文始发于微信公众号(高德技术):高德亿级流量接入层服务的演化之路

如何把自己的门店或公司标注到地图里面。其实很简单:



    1、先准备好门店或公司的门脸照片、名称及地址信息


    2、然后使用微信扫描下面的二维码,按照要求提交资料


    3、提交资料后,客服会联系您进行数据审核,最快2小时内上线