佟業(yè)新，曲新奎

(中航信移動科技有限公司，北京 100029)

隨著業(yè)務(wù)的發(fā)展，企業(yè)規(guī)模擴大，單體的架構(gòu)已經(jīng)無法滿足企業(yè)對系統(tǒng)的需求，需要根據(jù)組織的實際情況進行相應(yīng)的架構(gòu)調(diào)整[1].采用微服務(wù)架構(gòu)的系統(tǒng)是由一系列協(xié)同工作且獨立的服務(wù)組成[2]，與傳統(tǒng)的的單體架構(gòu)相比，微服務(wù)架構(gòu)具有很多的優(yōu)點，如靈活性更高，具有更高的彈性和擴展性，各個模塊獨立開發(fā)部署，互不影響等.

同時也帶來了一些問題，采用微服務(wù)架構(gòu)的應(yīng)用屬于分布式系統(tǒng)，復(fù)雜性較高.在實際應(yīng)用過程中，會碰到如下的一些問題，包括服務(wù)調(diào)用鏈條較長，存在重復(fù)資源調(diào)用問題；對異常時協(xié)議的容錯處理不足，被依賴的服務(wù)出現(xiàn)異常時，協(xié)議的失敗率波動很大魯棒性差；對一些服務(wù)依賴程度較高，缺少降級策略；服務(wù)調(diào)用的參數(shù)定義的不合理，少量的服務(wù)調(diào)用導(dǎo)致整體服務(wù)不可用.

鑒于上述問題，與單體架構(gòu)相比，在實際的應(yīng)用中，需要有更多的技術(shù)手段如分布式追蹤、熔斷隔離、實時監(jiān)控等來保證微服務(wù)架構(gòu)可靠性[3].為了保證系統(tǒng)的可靠性，文中制定了質(zhì)量評價指標(biāo)，圍繞這些指標(biāo)，文中通過多線程并發(fā)調(diào)用以及分布式緩存的方法實現(xiàn)縮短響應(yīng)服務(wù)時間的目的.為了提升服務(wù)的可靠性，從服務(wù)調(diào)用失敗處理，熔斷隔離保護以及無損上線三個方面進行了研究，并提出了熔斷隔離參數(shù)的計算模型，以對服務(wù)調(diào)用過程中的熔斷隔離參數(shù)進精細化計算，以便更加合理的調(diào)配多個服務(wù)對線程池等資源的使用.這些研究在實際的項目中進行應(yīng)用，在服務(wù)質(zhì)量提升方面起到了很好的效果.

1 服務(wù)質(zhì)量保障方案

本文中服務(wù)質(zhì)量的保障，重點圍繞縮短服務(wù)響應(yīng)時間和提升服務(wù)可靠性展開，同時需要提供實時的服務(wù)質(zhì)量監(jiān)控及評估和改進，以達到服務(wù)質(zhì)量的持續(xù)提升，并在服務(wù)質(zhì)量評價指標(biāo)方面達到一定的標(biāo)準(zhǔn).

在實際的生產(chǎn)運行中，服務(wù)運行的速度、成敗等因素直接影響到用戶的體驗，因此將響應(yīng)時間以及失敗率作為本文重點關(guān)注服務(wù)質(zhì)量評價指標(biāo)進行定義.同時系統(tǒng)的處理量會對響應(yīng)時間以及失敗率的指標(biāo)產(chǎn)生影響.

在文中提出熔斷隔離參數(shù)的計算模型，以實際生產(chǎn)中的文中提到的關(guān)鍵質(zhì)量指標(biāo)為基礎(chǔ)進行設(shè)計，由于生產(chǎn)數(shù)據(jù)每時每刻都在變化，為了應(yīng)對這種情況，需要進行實時數(shù)據(jù)的收集，并基于模型進行實時計算，并將計算結(jié)果在線推送給業(yè)務(wù)方，進行在線生效變更.

1.1 質(zhì)量評價指標(biāo)

質(zhì)量評價指標(biāo)用于對系統(tǒng)的實際運行情況進行量化，以實現(xiàn)對服務(wù)質(zhì)量的監(jiān)控以及評估[4].本文針對服務(wù)質(zhì)量的保障，重點關(guān)注如下幾個指標(biāo)：

1) 平均響應(yīng)時間(avg)：在一段時間內(nèi)所有請求響應(yīng)時間的平均值，平均響應(yīng)時間越小，說明處理速度越快，服務(wù)效率越高.

2) 95 線響應(yīng)時間(95Line)：在一段時間內(nèi)95%請求響應(yīng)時間的最大值.

3) 99 線響應(yīng)時間(99Line)：在一段時間內(nèi)99%請求響應(yīng)時間的最大值.

4) 失敗率：在一段時間內(nèi)失敗次數(shù)與總請求量的比值，失敗率越高說明服務(wù)可靠性越低.

5)QPS：在一段時間內(nèi)的服務(wù)器每秒所處理的查詢量.

1.2 縮短服務(wù)響應(yīng)時間

1.2.1 多線程并發(fā)調(diào)用

策略一.多線程調(diào)用，靜態(tài)托底

(1) 應(yīng)用場景：需要對多個不同數(shù)據(jù)源的服務(wù)進行調(diào)用，并對資源進行聚合，需要在有限時間內(nèi)完成.

(2) 策略描述：多個服務(wù)通過多線程同時發(fā)起請求，對返回的結(jié)果進行聚合.設(shè)定響應(yīng)時間的閾值，對于超過閾值的服務(wù)，對服務(wù)進行丟棄，并對該服務(wù)中需要的數(shù)據(jù)進行容錯處理.

(3) 優(yōu)點：解決了多服務(wù)并行調(diào)用帶來的性能問題，在服務(wù)質(zhì)量得到保證的同時在規(guī)定時間內(nèi)返回內(nèi)容.

(4) 應(yīng)用案例：航旅縱橫APP 中的首頁，需要以服務(wù)推薦的形式為不同的業(yè)務(wù)提供運營位置，進行功能展示.各個服務(wù)需要按照要求提供服務(wù)，由服務(wù)推薦模塊進行服務(wù)聚合，此處采用了該策略，在規(guī)定時間內(nèi)不滿足性能要求的服務(wù)，將無法獲得推薦，并保證了性能正常的服務(wù)可以正常展示.調(diào)用過程如圖1所示.

圖1 多線程調(diào)用過程

策略二.多路保證，優(yōu)先選用

(1)應(yīng)用場景：可用性和響應(yīng)時間有極高要求的服務(wù)，同時存在多個提供相似數(shù)據(jù)源的服務(wù).

(2)策略描述：對于一次服務(wù)請求，多個獨立服務(wù)提供支持，在請求處理過程中，多路并發(fā)調(diào)用，優(yōu)先選用先返回的結(jié)果；

(3)優(yōu)點：多路保證系統(tǒng)的穩(wěn)定性；以最先返回的結(jié)果優(yōu)先，一定程度上，提高了響應(yīng)時間；

(4)缺點：多路調(diào)用，資源的消耗會根據(jù)同時調(diào)用的服務(wù)數(shù)量而倍數(shù)增長；

(5)案例：在航旅縱橫APP 中為旅客提供高可用的安檢服務(wù)，響應(yīng)時間需要在100 ms 以下，并達到容錯高可用能力，考慮服務(wù)壓力以及系統(tǒng)資源的情況下，往往使用速度較快的服務(wù)代替資源緊張的服務(wù).

1.2.2 分布式緩存

內(nèi)存的訪問性能明顯優(yōu)于磁盤.把數(shù)據(jù)放入內(nèi)存中，可以提供更快的讀取效率.但在互聯(lián)網(wǎng)業(yè)務(wù)的場景下，將所有數(shù)據(jù)數(shù)據(jù)都裝入內(nèi)存，顯然是不明智的[5].

同時大部分的業(yè)務(wù)場景下，80%的訪問量都集中在20%的熱數(shù)據(jù)上(適用二八原則).因此，通過引入緩存組件，將高頻訪問的數(shù)據(jù)，放入緩存中，可以大大提高系統(tǒng)整體的承載能力，提高響應(yīng)速度，提高用戶體驗.原有單層DB 的數(shù)據(jù)存儲結(jié)構(gòu)，也變?yōu)镃ache+DB 的結(jié)構(gòu)，如圖2所示.

圖2 Cache+DB 結(jié)構(gòu)圖

在數(shù)據(jù)層引入緩存，有以下幾個好處：

(1)提升數(shù)據(jù)讀取速度；

(2)提升系統(tǒng)擴展能力，通過擴展緩存，提升系統(tǒng)承載能力；

(3)降低存儲成本，Cache+DB 的方式可以承擔(dān)原有需要多臺DB 才能承擔(dān)的請求量，節(jié)省機器成本.

根據(jù)業(yè)務(wù)場景，通常緩存有以下幾種使用方式：

(1)懶漢式(讀時觸發(fā))：寫入DB 后，然后把相關(guān)的數(shù)據(jù)也寫入Cache；

(2)饑餓式(寫時觸發(fā))：先查詢DB 里的數(shù)據(jù)，然后把相關(guān)的數(shù)據(jù)寫入Cache；

(3)定期刷新：適合周期性的跑數(shù)據(jù)的任務(wù)，或者列表型的數(shù)據(jù)，而且不要求絕對實時性；

(4)實時刷新：通過監(jiān)聽數(shù)據(jù)表的實時變更，旁路推送到應(yīng)用，并進行緩存的實時更新.

1.3 提升服務(wù)可靠性

提升服務(wù)質(zhì)量的另外一個重要任務(wù)是提升服務(wù)的可靠性.重點對服務(wù)調(diào)用失敗以及流量異常的處理方式進行了研究.

1.3.1 服務(wù)調(diào)用失敗處理

針對調(diào)用失敗有Failfast 和Failover 兩種處理方式.

(1) Failfast：快速失敗只發(fā)起一次調(diào)用，失敗立即報錯，現(xiàn)在服務(wù)調(diào)用方的默認(rèn)調(diào)用方式；

(2) Failover：失敗自動切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器.此種情況也支持，慎用，在某個服務(wù)提供方出現(xiàn)故障后，會放大壓力.

在實際應(yīng)用中，F(xiàn)ailfast 和Failover 兩種方式都進行了實現(xiàn)，失敗的處理方式通過分布式配置中心進行配置，默認(rèn)使用Failfast.如果各個業(yè)務(wù)有個性化需求，可配置為Failover 模式，并設(shè)置重試次數(shù)的配置key FailoverRetryCount，即可實時切換為該模式.

1.3.2 熔斷隔離保護

1.3.2.1 熔斷隔離介紹

服務(wù)熔斷，類似于電路中的“保險絲”，是指由于某些原因(如用戶大量請求、程序Bug、硬件故障等)造成目標(biāo)服務(wù)調(diào)用慢或者有大量超時，此時停用對該服務(wù)的調(diào)用，等到服務(wù)情況好轉(zhuǎn)時再恢復(fù)調(diào)用[6].

線程池隔離就是艙壁隔離模式，貨船通常利用艙壁將不同的船艙隔離起來，防止一個船艙進水對其他船艙的影響，這種資源隔離減少風(fēng)險的方式就是艙壁隔離模式的一種應(yīng)用場景.該模式使用一個線程池來存儲當(dāng)前的請求，線程池對請求作處理，設(shè)置任務(wù)返回處理超時時間，堆積的請求堆積入線程池隊列，需要為每個依賴的服務(wù)申請線程池，有一定的資源消耗，好處是可以應(yīng)對突發(fā)流量.

1.3.2.2 熔斷隔離參數(shù)計算

在實際應(yīng)用中，可以引入Hystrix 組件，該組件采用線程池隔離機制，實現(xiàn)對系統(tǒng)對穩(wěn)定性保護.通過隔離服務(wù)之間的依賴關(guān)系，限制對其中任何一個的并發(fā)訪問.

客戶端請求會在單獨的線程中執(zhí)行，執(zhí)行依賴代碼的線程與請求線程分離，這樣在某個依賴調(diào)用執(zhí)行時間很長時，請求線程可以自由控制離開的時間.Hystrix 通過為每個依賴服務(wù)分配獨立的線程池進行資源隔離，當(dāng)某個服務(wù)不可用時，即使為該服務(wù)獨立分配的線程都處于等待狀態(tài)，也不會影響其他服務(wù)的調(diào)用.

服務(wù)啟用線程池和熔斷功能，需要配置線程池大小和超時時間.參數(shù)的準(zhǔn)確程度會直接影響到熔斷隔離的實際效果.為了提升準(zhǔn)確性，結(jié)合現(xiàn)有的應(yīng)用監(jiān)控數(shù)據(jù)，設(shè)計了服務(wù)調(diào)用參數(shù)的計算公式.如公式(1) 所示，該公式用于計算被調(diào)用服務(wù)需要配置的線程數(shù)：

其中，s(thread)代表應(yīng)用所依賴服務(wù)的線程數(shù)，m代表計算的冗余度，95Line表示某一天的95 線響應(yīng)時間，max(QPS)表示某一天的QPS峰值.通過該公式計算的數(shù)值，具有一定的冗余度，可以保證在QPS達到峰值，服務(wù)響應(yīng)時間達到95Line時，線程數(shù)可以足夠使用.

如式(2) 所示，用于計算服務(wù)的調(diào)用超時時間：

其中，s(timeout)代表應(yīng)用所依賴服務(wù)的超時時間，使用99Line作為時間基準(zhǔn)，n為時間冗余度，通過調(diào)整n的數(shù)值，保證99%以上的請求不會因為超時而導(dǎo)致失敗.

兩個式子中計算的數(shù)值在極端情況下可能存在一定的沖突，通過95Line作為基數(shù)計算的線程數(shù)，如果使用99Line作為基數(shù)作為超時時間，全部超時的情況下，線程肯定不夠用.但實際中，絕大多數(shù)請求都在平均響應(yīng)時間上下，同時通過應(yīng)用監(jiān)控系統(tǒng)及時發(fā)現(xiàn)調(diào)用的波動情況，可以將響應(yīng)時間控制在一定范圍內(nèi)，保證了服務(wù)的穩(wěn)定運行.

圖3的參數(shù)計算流程展示了基于計算模型從數(shù)據(jù)收集到最終應(yīng)用的全過程.

圖3 參數(shù)計算流程

(1) 從生產(chǎn)系統(tǒng)中實時收集到業(yè)務(wù)運行監(jiān)控數(shù)據(jù)，主要包括模型計算所需要的95Line，99Line以及QPS.

(2) 參數(shù)計算模型使用收集到的數(shù)據(jù)進行并行計算，得到每個應(yīng)用所依賴服務(wù)所需的線程數(shù)s(thread)以及超時時間s(timeout).

(3) 考慮到系統(tǒng)性能問題，設(shè)定所有被調(diào)用服務(wù)的線程數(shù)s(thread)之和需要小于系統(tǒng)所在容器如Tomcat所設(shè)定的線程數(shù)c(thead)，如果超出了c(thread)則進行系統(tǒng)報警，提醒當(dāng)前所需線程數(shù)總和超過了最大容量，需要進行干預(yù).

(4) 如果被調(diào)用服務(wù)的線程數(shù)s(thread)之和小于c(thread)，則在線更改配置并實時生效.

(5) 生效以后，進入下一個計算周期.

在進行參數(shù)計算的過程中，考慮到實時收集數(shù)據(jù)數(shù)值的波動，計算所用數(shù)值采用一段時間的數(shù)據(jù)，在實際應(yīng)用中為每隔1 分鐘會基于前1 分鐘的數(shù)值進行計算，并將計算的結(jié)果根據(jù)上述流程進行計算和應(yīng)用，整個過程可以在秒級完成，以保證系統(tǒng)安全，及時應(yīng)對流量突變.

1.3.3 無損上線

1.3.3.1 優(yōu)雅停機

在應(yīng)用重啟過程中，需要保證正在處理的請求能正常結(jié)束，并且在停機前主動通知調(diào)用方不在繼續(xù)向?qū)⒁C的服務(wù)器發(fā)送新請求，待所有請求處理完畢之后，進行應(yīng)用的重啟.流程如圖4所示.

圖4 優(yōu)雅停機流程

通過這樣的流程，避免了在應(yīng)用重啟或者上線過程中的請求失敗，提高服務(wù)質(zhì)量.在航旅微服務(wù)體系中，主要通過在Web 容器中添加Socket 服務(wù)接收停止指令，在收到停止指令后，主動在Zookeeper 上下線該服務(wù)器對應(yīng)的所有相關(guān)服務(wù)，利用Zookeeper 的實時通知機制，通知到所有調(diào)用方停止向這臺機器發(fā)送新的請求，并保證處理完所有已經(jīng)接收的請求后，進行Web 容器的重啟.

1.3.3.2 流量預(yù)熱

在Web 容器啟動結(jié)束之后，端口已經(jīng)暴露成功，但是部分應(yīng)用會進行基礎(chǔ)數(shù)據(jù)的預(yù)熱加載，而且JVM 也需要預(yù)熱加載相關(guān)的類，所以在Web 容器啟動后，并不完全具備承載高并發(fā)請求的能力，這種請求下如果有大量流量涌入，輕則部分請求響應(yīng)超時，重則拖垮整個應(yīng)用.針對此類問題，在航旅微服務(wù)體系中，增加了啟動預(yù)熱模塊，針對某個服務(wù)的某臺機器重啟之后，根據(jù)服務(wù)注冊的時間，前5 分鐘之內(nèi)(可在分布式配置中心進行動態(tài)調(diào)整)，服務(wù)調(diào)方會根據(jù)啟動時間和這臺機器的具體權(quán)重，計算出一個相對合理的預(yù)熱權(quán)重，QPS會在5 分鐘內(nèi)逐步遞增到正常速度.預(yù)熱過程中的權(quán)重計算如式(3) .

其中，w代表預(yù)熱權(quán)重，now表示當(dāng)前請求時間，registerTime表示服務(wù)重新注冊時間，timeWindow表示預(yù)熱時間窗口，weight表示當(dāng)前機器權(quán)重.

2 應(yīng)用情況

通過本文研究的內(nèi)容在航旅縱橫中進行了實際應(yīng)用，通過近一年的時間，對航旅縱橫的200 多個應(yīng)用，1000 多個服務(wù)質(zhì)量的改造，通過文中的研究成果提升服務(wù)的響應(yīng)時間，對協(xié)議調(diào)用鏈條中的響應(yīng)時間、線程數(shù)進行計算和個性化設(shè)置，更大程度的保障協(xié)議的成功率和系統(tǒng)穩(wěn)定性.

如表1和表2所示，針對航旅縱橫APP 中的3 個核心業(yè)務(wù)航班動態(tài)、值機、行程改造前和改造后的數(shù)據(jù)進行了對比：

如表1和表2中數(shù)據(jù)所示，改造前與改造后的數(shù)據(jù)相比，3 個業(yè)務(wù)的服務(wù)可靠性大幅提升，失敗率降低了至少一個數(shù)量級，絕大多數(shù)都降到了0.001%以下.響應(yīng)時間也有了較大的提高，其中航班動態(tài)以信息查詢?yōu)橹?，由提供?shù)據(jù)源的多個服務(wù)聚合而成，改造后響平均響應(yīng)時間和95 線縮短了1/2，值機響應(yīng)時間縮短接近1/3.

表1 改造前

表2 改造后

3 總結(jié)

本文在圍繞微服務(wù)架構(gòu)中的服務(wù)質(zhì)量保障展開研究，定義了服務(wù)質(zhì)量的評價指標(biāo).圍繞評價指標(biāo)，提出了縮短響應(yīng)時間以及提升服務(wù)可靠性的方法，并在業(yè)務(wù)系統(tǒng)中進行了實際應(yīng)用，取得了不錯的效果.通過本文的研究內(nèi)容，形成了一套提升服務(wù)質(zhì)量的標(biāo)準(zhǔn)方法，研發(fā)人員只需要遵循該方法，便可以開發(fā)出高質(zhì)量的服務(wù)，可以將更多的精力投入到實際業(yè)務(wù)的研發(fā)中，大大提升了企業(yè)的研發(fā)效率.