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

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

iPhone 11 Pro、衛衣、T恤等你來抽，馬上來試試手氣 https://www.aliyun.com/1111/2019/m-lottery?utm_content=g_1000083877