Categories
程式開發

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考


攜程從.Net技術棧的時代就已經開始微服務領域的探索,轉入Java技術棧之後,先是自研微服務框架,然後是高性能的Dubbo。目前我們正在Service Mesh的道路上探索,希望接下來能夠實現微服務框架的全面標準化以及雲原生。

一、過去(自研服務框架)

攜程在.Net技術棧時代,開始是基於ESB總線,雖然解決了內網服務調用的治理問題,但是集中式的服務架構,經常會出現單個服務把整個總線拖垮,進而導致全網癱瘓的現象。基於註冊中心的SOA服務架構,通過分佈式的服務調用,解決了單點故障帶來的巨大影響。

目前,攜程主要是以Java技術棧為主,考慮到兼容歷史.Net技術棧,現在的框架以自研為主,但是對比開源的高性能服務框架,自研的框架可能又存在下述提到的幾個問題。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 1

二、現在(CDubbo服務框架)

CDubbo名字裡的C代表攜程的治理,Dubbo代表阿里開源的Dubbo SDK。縱觀過去兩年的實踐和探索,從2018年4月的第一個版本落地,到現在的近萬服務實例,我們大致可以總結為下面的幾個主要里程碑。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 2

2.1 註冊發現

註冊發現是分佈式服務框架的核心要素,為了支持現有的服務互通,所以需要接入攜程的註冊中心。

服務註冊支持健康檢測擴展機制,業務可以根據業務場景自定義健康檢測擴展,例如當依賴的數據庫不可用時不再對外提供服務。服務端通過5s一次的心跳保持服務的可用性,當連續N次沒有發送心跳時就會自動通知客戶端。

客戶端發起對服務的訂閱,通過推拉結合的模式,保證節點在客戶端的最終一致性。通過Dubbo的擴展機制,實現了自定義的路由策略,比如根據方法名指定路由策略,以及根據請求參數決定不同的路由策略,同時也能夠支持就近訪問,優先訪問本機房的服務。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 3

2.2 監控-CAT

對微服務來說,沒有了監控就好比瞎子一樣,什麼也不清楚。 CAT提供了分佈式鏈路追踪的能力,可以提供很好的報表,以及場景化的問題分析。

有時,需要了解服務總的請求量以及單機的請求分佈和QPS,或者還要知道服務的執行耗時及99線。 CAT的聚合報表可以幫助我們更好的了解服務的健康狀況。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 4

對於超時,可能需要知道哪個階段變慢,客戶端還是服務端,序列化階段還是服務執行過程太慢。對於異常報錯,可以看到哪個過程出現的異常,同時會打印異常堆棧信息,幫助問題的定位。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 5

2.3 監控-Metrics

框架人員需要了解公司服務的宏觀情況,比如各機房都有哪些服務,哪些服務使用了protobuf序列化格式,哪些服務使用了SOA協議等,以及平均執行耗時等情況。業務同事可能也想知道自己服務具體情況,比如有哪些調用方,線程池是否已經跑滿了。

通過接入攜程的Dashboard,可以提供全局的總量、錯誤量、線程池統計信息,也可以根據機房、協議、序列化格式等聚合數據。還能夠自定義告警規則,在問題發生時能夠儘早的介入。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 6

2.4 動態配置

對業務同事來說,有可能會存在依賴的服務突然變慢導致客戶端超時的情況。框架人員可能需要在機房故障時,需要全局調整check為false,以解決AB 服務循環依賴誰都無法啟動的問題。動態配置提供了配置熱生效的能力,不需要為了一個配置重新發布,成本很高。

服務端的多個方法,可能執行耗時也會有所不同,通過多級別的參數配置,可以設置服務默認超時為1s,單獨為執行較慢的方法設置獨立的超時時間為5s。

服務Owner可能更清楚自己服務的耗時,通過服務端對客戶端的參數設置,不需要每個調用方都設置一次超時,設置的時間也會更合理一些。為了避免配置出錯帶來的損失,我們提供了友好的可視化界面。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 7

2.5 SOA協議及互通

為了支持現有客戶端遷移到CDubbo,需要考慮支持現有的SOA協議。除了要確保兼容HTTP 1.1協議不變,其次要保證跟客戶端的序列化器一致。

CDubbo會通過Tomcat端口接收SOA協議的請求,利用現有的序列化器執行請求對象的轉換,並保證Dubbo內部調用和Filter鏈路的一致性,確保業務邏輯的統一,也就是業務代碼不需要改動,就可以啟動兩個協議。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 8

2.6 測試平台

對於私有的二進制協議來說,沒有現成的Postman等工具可以使用。有時,開發人員需要在本地驗證測試環境的服務,也可能要驗證本地啟動的服務端,每個開發人員都構造一個客戶端顯得成本比較高。

通過VI(github開源叫coreStone),以及利用Dubbo 2.7.3提供的元數據中心和泛化調用能力,我們實現了類似postman的調用工具。不但可以支持直連,也能夠支持本地測試,同時還可以支持protobuf序列化格式。關於protobuf序列化的測試方案,已經貢獻到dubbo社區,感興趣的同學可以自行了解。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 9

2.7 升級Dubbo 2.7.3

關於Dubbo 2.7.3的詳細升級歷程,可以參考https://www.infoq.cn/article/kOxdaV3y9fMZ0Bzs0jb2

現在回顧下升級的最終結果如何。目前,攜程99%的服務已經跑在dubbo 2.7.3之上,迄今為止0故障,只有一些不兼容的小問題,對於不兼容的問題也是確保了編譯時提前暴露,運行時沒有任何問題。

在發布後,也陸續的出現了一些小的問題,比如預熱能力不生效,異常情況下不會回調onError等問題,支持服務端異步的Trace埋點等,這些問題已經在開源版本徹底修復了。

2.8無螺紋

業務同事反饋,需要把線程控制在理想的範圍之內。但是,dubbo的線程數量太多,一方面是服務級獨享線程池,當調用方依賴了10個服務,每個服務的QPS為1,lantency可能只有10ms的情況下,由於每個服務獨立線程池,至少也需要10個線程了。如果多服務共享一個線程池,由於客戶端默認是Cached的線程池模式,那麼在這個場景下可能只要1個線程就足夠了。另一方面,對同步服務來說,dubbo 2.7.5的threadless可以省去DubboClientHandler線程,Netty IO線程直接把響應交給業務線程,從而節省了一次線程切換。

通過實踐,業務線程數量有了很大程度的下降,在高QPS以及依賴服務數量較多的情況下,甚至可以下降60-70%。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 10

2.9 CDubbo服務體系

現有CDubbo的服務體系,同時支持Dubbo和SOA協議,對於Dubbo客戶端能夠支持TCP協議的傳輸,對於現有的SOA客戶端,能夠兼容現有的SOA協議。

同時,也能夠支持內網和外網gateway的請求,保證了多協議的配置統一,以及兼容了SOA的序列化格式。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 11

2.10 性能表現

從協議層面來看,Dubbo協議的響應較SOA協議有所提升,平均耗時從之前的1ms降低到了0.3ms左右,當然具體提升也要根據​​服務的報文及請求量有所差異。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 12

可能有些人會覺得幾毫秒的性能提升不足以掛齒,但是性能的穩定性對服務來說會很重要。我們觀察了服務流量突增3-4倍的情況下,客戶端還能保持0異常。長連接的多路復用,提供了很好的抗衝擊能力。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 13

2.11 擴展性

微服務框架跟業務代碼耦合比較重,框架人員主要是用20%的時間解決業務80%的需求,另外20%的需求卻需要80%時間的問題,更適合留給業務自己去解決,能夠提供這個能力的唯有擴展性,dubbo無論橫向和縱向的擴展能力都很好。

通過實踐,發現業務的確在各個層級都有自己的擴展。例如:業務擴展了Router層,支持自己的路由規則,擴展了負載均衡策略,機票同事甚至擴展了Transport層換成了適合自己的傳輸協議。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 14

2.12 生態

好的生態,可以降低開發成本,例如利用現有的開源dubbo admin,dubbo go等組件。另外,也可以降低業務的學習成本,在其他公司學習的dubbo框架,到了攜程還可以接著用,不需要重新學習私有的服務框架。技術支持也比較少,很多業務同事對dubbo框架非常熟悉。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 15

2.13 Dubbo協議存在的問題

除了前面提到的各種優點,經過實踐發現現有的協議也存在著各種不足。除了對網關不太友好,沒有移動端的SDK等問題。現有的擴展機制,在A和B服務都擴展了cluster AOP的情況下,可能會導致擴展的相互影響,如何能夠保持擴展性又降低相互影響是值得探討和解決的問題。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 16

三、未來(Service Mesh)

網上關於Service Mesh的意義講了很多,眾說紛紜,個人認為可能最主要還是以下幾點。

  • 標準化意味著更低的成本,比如研發成本低,學習成本也比較低,其他公司學習的微服務框架,到攜程還可以繼續用,省去了學習和踩坑的成本。
  • 進程解耦,框架同學可能比較感興趣,中間件無法獨立昇級的問題一直困擾著框架研發同學,在這個問題上,envoy可以獨立昇級也是值得期待的。
  • 通過下沉,復用了雲基礎設施的一些能力,一方面,能夠更好的支持多語言,業務根據自己的場景選擇合適的語言,另一方面,通過下沉也能夠讓SDK更簡單,減少Jar依賴的兼容性問題。
  • 因為更加標準以及下沉,能夠帶來更好的雲部署能力,業務出海時可以根據實際情況部署需要的組件,不再依賴框架全家桶了。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 17

3.1 Service Mesh SDK

下圖是Istio官網提供的ServiceMesh架構圖,如果說istio解決了控制平面的標準化,envoy或者sofa-mosn解決了數據平面的標準化,那麼對於SDK來說,是否需要有個標準化的組件,或者是否存在適合我們的標準的SDK呢?

對於部分中小公司,沒有自己的中間件團隊,可能會選擇付費版的sofa。但是,對於攜程這樣的規模,對擴展性要求很強,同時已經存在上千dubbo服務的公司來說,我們可能更期待3.0的標準化能力。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 18

3.2 現有協議不適合下沉

現有的SOA協議可能不太適合作為標準協議,基於Http 1.1的文本協議,跟TCP協議相比,建連帶來的成本,很大程度上會導致長尾,影響服務的穩定性。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 19

Dubbo協議由於對網關不太友好,同時存在著跨語言和協議穿透性等問題,envoy本身也可以理解為單機網關代理,所以也不太適合作為標準協議。

其次,存在的跨語言和協議穿透性問題,阿里劉軍同學有過分享,感興趣的同學可以參考:https://www.infoq.cn/article/y5HC2JjtAvMWYILmVILU

3.3 新協議

既然現有的協議都不太適合,是否可以考慮雲原生的標準協議gRPC。沒錯,從協議層面來看,這個選擇沒有問題,但是gRPC跟proto強綁定的問題,需要攜程現有的幾千個服務重寫業務邏輯代碼,這個成本可是無法被接受的。

我們對於新的協議的期待,應該是能夠基於POJO對象,同時還要符合gRPC協議規範。一方面,能夠很好的利用雲原生的基礎能力。另一方面,對於小眾語言,也可以利用現有的gRPC框架實現與主流SDK的互通。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 20

對於新的SDK,不但要有標準的傳輸協議,同時考慮到服務框架與業務的緊密耦合,擴展性也是要保留的主要的特性,還需要考慮API的標準化,利用統一的監控組件。

3.4 總結

現在,我們實現了SDK的部分標準化。未來,我們一定會在雲原生的道路上走的更快,更穩,更標準。

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考 21

作者介紹

海洋,攜程技術專家。對微服務和並發編程,以及應用性能調優等領域有較濃厚興趣。

本文轉載自公眾號攜程技術(ID:ctriptech)。

原文鏈接

近萬服務實例穩定運行0故障,攜程微服務框架實踐及思考