高德億級流量接入層服務的演化之路

2019杭州雲棲大會上，高德地圖技術團隊向與會者分享了包括視覺與機器智能、路線規劃、場景化/精細化定位時空數據應用、億級流量架構演進等多個出行技術領域的熱門話題。現場火爆，聽衆反響強烈。咱們把其中的優秀演講內容整理成文並陸續發佈出來，本文爲其中一篇。

阿里巴巴資深技術專家孫蔚在高德技術專場作了題爲《高德億級流量接入層服務的演化之路》的演講，主要分享了接入層服務在高德業務飛速發展過程當中，爲應對系統和業務的各方面挑戰所作的相關係統架構設計，以及系統在賦能業務方面的思考和將來規劃。

如下爲孫蔚演講內容的簡版實錄：

高德地圖的DAU（日活）已通過億，服務量級是數百億級。高德的應用場景，好比實時公交、實時路況、導航、司乘位置的同時展現等，對延遲很是敏感。如何作到高可用、高性能的架構設計，高德在實踐中總結了一套解決方案。

今天主要分享三個方面的內容：

接入層定位思考與挑戰

高可用、高性能的架構設計

高德服務端的思考及規劃

1、接入層定位思考與挑戰

首先介紹下Gateway，從架構上看，Gateway在中間位置，上層是應用端，下層是引擎，例如駕車引擎、步導引擎等等。目前已接入80+應用，500多個API透出，QPS峯值60W+。

從Gateway的定位來思考，做爲網關，最重要的就是穩定，同時能提效和賦能。一句話歸納：如何在資源最少的狀況下，在保證穩定的前提下，以最快速度幫助業務的達成，這就是服務端的定位。

高德的網關設計挑戰在於天天數百億級的流量過來，場景對延遲又特別敏感。舉個例子，不少開發者和應用都在使用高德定位服務，定位服務架構挑戰5毫秒內需返回。

爲了解決這些問題，高德作過一次比較大的系統架構升級，主要作了幾方面的工做。首先是流式、全異步化改造。機器數量減小一半，性能提高一倍，經過這個架構升級達到了。

其次是增強基礎支撐能力建設，爲配合引擎提效，作了接口聚合、數據編排和流量打標與分流。

此外，爲了提供服務穩定性，同時提高單元性能，作了高德單元化網關解決方案。最主要是方便其餘業務快速實現單元化。

2、高可用、高性能的架構設計

重構前比較嚴重的問題是服務性能低，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%。

3、思考及規劃

Gateway如今是集中化的場景，怎麼變成分佈式的解決方案？

這方面咱們也作了嘗試。分佈式網關通常有兩種實現路徑：第一種是作SDK，第二種是作邊車或服務網格的方式。SDK方式的分佈式網關咱們已經在部分場景使用，缺點是對異構支撐困難，和應用的隔離性很差，好處是開發比較快，目前天天也有過百億的請求在訪問。

邊車或者服務網格實際上是咱們架構的終局，他能解決異構、應用系統隔離性等問題。由於：

Gateway Sidecar與業務應用運行於同服務器的獨立進程，既具備分佈式部署優點又具有較好的隔離性；

Gateway Control Manager負責管理分佈式Gateway Sidecar，至關於Service Mesh的控制面，主要負責網關配置和元數據管理、服務高可用以及統計打點、異常監控和報警等。

服務網格優點是去中心化的分佈式部署方式，自然就具有高可用性和水平擴展性，無單點和性能瓶頸問題，缺點是不太適合實現聚合API的實現。服務網格咱們目前是基於螞蟻SOFA來作，主要用來解決異構RPC調用的問題。

最後給個建議，根據實際經驗，你們若是在作服務或Gateway相關的事，若是你面臨的挑戰是機器數量減小一半，性能提高一倍，全鏈路異步化架構可能會對你有所幫助。

(關注高德技術，找到更多出行技術領域專業內容）       複製代碼