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

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相關的事，如果你面臨的挑戰是機器數量減少一半，性能提升一倍，全鏈路異步化架構可能會對你有所幫助，

（關注高德技術，找到更多出行技術領域專業內容）

標籤：架構設計

上一篇：微服務分布式 spring cloud springboot 框架原始碼 activiti作業流 前后分離

下一篇：資料結構導論(第三章堆疊）