网站一条龙服务,做产地证的网站,做kegg通路富集的网站,wordpress做菜鸟教程2019杭州云栖大会上#xff0c;高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆#xff0c;听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来#xff…2019杭州云栖大会上高德地图技术团队向与会者分享了包括视觉与机器智能、路线规划、场景化/精细化定位时空数据应用、亿级流量架构演进等多个出行技术领域的热门话题。现场火爆听众反响强烈。我们把其中的优秀演讲内容整理成文并陆续发布出来本文为其中一篇。
阿里巴巴资深技术专家孙蔚在高德技术专场做了题为《高德亿级流量接入层服务的演化之路》的演讲主要分享了接入层服务在高德业务飞速发展过程中为应对系统和业务的各方面挑战所做的相关系统架构设计以及系统在赋能业务方面的思考和未来规划。
以下为孙蔚演讲内容的简版实录
高德地图的DAU日活已经过亿服务量级是数百亿级。高德的应用场景比如实时公交、实时路况、导航、司乘位置的同时展示等对延迟非常敏感。如何做到高可用、高性能的架构设计高德在实践中总结了一套解决方案。
今天主要分享三个方面的内容
接入层定位思考与挑战
高可用、高性能的架构设计
高德服务端的思考及规划
一、接入层定位思考与挑战
首先介绍下Gateway从架构上看Gateway在中间位置上层是应用端下层是引擎例如驾车引擎、步导引擎等等。目前已接入80应用500多个API透出QPS峰值60W。
从Gateway的定位来思考作为网关最重要的就是稳定同时能提效和赋能。一句话概括如何在资源最少的情况下在保证稳定的前提下以最快速度帮助业务的达成这就是服务端的定位。
高德的网关设计挑战在于每天数百亿级的流量过来场景对延迟又特别敏感。举个例子很多开发者和应用都在使用高德定位服务定位服务架构挑战5毫秒内需返回。
为了解决这些问题高德做过一次比较大的系统架构升级主要做了几方面的工作。首先是流式、全异步化改造。机器数量减少一半性能提升一倍通过这个架构升级达到了。
其次是加强基础支撑能力建设为配合引擎提效做了接口聚合、数据编排和流量打标与分流。
此外为了提供服务稳定性同时提升单元性能做了高德单元化网关解决方案。最主要是方便其他业务快速实现单元化。
二、高可用、高性能的架构设计
重构前比较严重的问题是服务性能低BC服务器综合性能在1200QPS。稳定性风险比较高特别是网络抖动如何保证整个系统的稳定性这可能是最大的挑战。所以对于整个架构的思考最主要的事情是做异步化。
高德接入层网关演进过程主要经历了3个阶段 1.异步Pipeline架构改造
1流式、全异步化架构 如上图Pipeline的架构模型我们在2016年开始做那时候还没有很流行我们自己实现了异步认知再加入Pipeline架构模型。
采用流式、全异步化的架构模型使用 Tomcat nioAsync 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相关的事如果你面临的挑战是机器数量减少一半性能提升一倍全链路异步化架构可能会对你有所帮助。 iPhone 11 Pro、卫衣、T恤等你来抽马上来试试手气 https://www.aliyun.com/1111/2019/m-lottery?utm_contentg_1000083877
原文链接 本文为云栖社区原创内容未经允许不得转载。
