前言

? ?? 隨著微服務的流行，每個互聯網公司后臺都有無數大大小小的服務，服務與服務之間又有著千絲萬縷的調用關系。要保證整個微服務系統的成熟穩定，就必須保證每個微服務的成熟度。但如何來定義服務的成熟度？應該從哪些緯度來考量？各個緯度里又有哪些普遍的問題？如何來優化？

? ? ?本文介紹了愛奇藝技術產品團隊用來衡量服務成熟度的模型，并基于此模型對多個后臺服務進行評估，總結出了一些常見的低分項，并對低分項整理了相關優化方案。希望對大家有所幫助。

01

?服務成熟度模型

? ? ? ?為了能夠對服務的成熟度進行量化，我們需要從多個維度對服務進行評估。

? ? ? ?每個服務隨著需求不斷迭代，每個迭代周期都需要經歷如下三個階段：開發測試，運維上線，線上運行。每一個階段，都需要一系列的措施來保證服務最終的成熟可靠。我們針對每一個階段，梳理出來需要關注的指標，來衡量該階段的整體質量。

? ? ? ?我們對上面3個階段進行綜合評分，并根據評分對服務成熟度進行了等級劃分。（1-5分為準入級，6-7分為服務級，8-10分為成熟級。）

? ? ? ?通過這樣的服務成熟度模型，我們就可以以量化的指標直觀的評價一個服務的成熟度，并發現服務有哪些可改進項。

02

?低分項梳理

? ? ? 基于服務成熟度模型，我們對多個后臺服務進行了評估，發現了一些指標項在各個服務中普遍得分較低。這些指標項包括：

• 開發測試方面：代碼規范，單元測試，壓力測試，接口撥測；

• 運維上線方面：灰度上線，上線回滾；

• 線上可用性方面：系統保護，數據備份，報警處理，應急預案。

? ? ?? 于是我們優先對這些低分項的優化方案進行了梳理，期望通過對低分項的優化，提升服務的成熟度，使我們的服務提升至成熟級別。

03

?低分項優化方案

? ? ? 我們的服務主要基于Java語言開發，主要是虛機部署的部署方式，并少量采用容器部署。所以下面的優化方案主要圍繞我們的服務現狀展開。

3.1

開發測試

? ? ? ?線上bug往往都是開發新需求引入的，如果在開發測試階段盡可能的發現問題，提高代碼質量，能夠將問題的影響范圍控制在最小。下面是開發測試階段一些常見的措施和手段：

3.1.1 代碼規范

? ? ? ?代碼風格：采用統一的代碼風格，一方面可以使得代碼的可讀性提升，另一方面會減少代碼合并時的沖突，并與開發工具集成，支持自動提示不規范代碼，有的不規范代碼甚至可以一鍵修正。配合GitLab CI和Sonar檢查，可以對每次的提交進行代碼規范的檢查，并以報告的形式直觀的展現。

3.1.2 單元測試

? ? ? 單元測試位于測試金字塔的最底層。運行效率快，一般完成的測試case跑下來不會超過10分鐘，可以集成在CI流程中，快速反饋問題。維護成本低，單元測試在開發階段就能發現問題，修復成本低。測試金字塔越向上反饋的時間越長，實現的成本也越高。因此推薦大家提升單元測試的覆蓋率。

? ? ? Java最常用的測試框架是Junit。另外配合Mock測試庫Mockito和測試覆蓋率工具Jacoco形成完整的單元測試工具集。在IDEA和SonarQube中都可以配置Jacoco的插件來直觀的展示單元測試的覆蓋率。

? ? ? 在推進單元測試的過程中，我們經常遇見的問題是：項目補充單元測試費時費力，新增代碼的測試覆蓋率如何把關？

我們的解決思路是：

• 已有代碼優先對重要代碼（如公共庫，工具類）補充單元測試。

• 新增代碼增加代碼覆蓋率的指標（如：設定新增代碼測試覆蓋率不得低于90%）

• 隨著新增代碼和對老代碼修改，項目整體的測試覆蓋率會逐步提升。
  

新增代碼測試覆蓋率統計：使用diff-cover工具可以通過分析分支代碼差異和Jacoco測試報告，計算出當前分支修改代碼的測試覆蓋率。

3.1.3 單元測試

（1）為什么要做壓力測試？通過壓力測試，我們能夠：

·? 發現性能瓶頸

·? 預估資源使用情況

·? 為限流配置提供參考

·? 發現新需求引入的問題

（2）壓力測試工具應具備什么功能？

常見的壓力測試工具有JMeter等。我們使用愛奇藝云平臺提供的LoadMaker云壓測系統，它具備如下特點：

·? 多個施壓集群，壓力可以達到很高

·? 創建和保存壓測場景，重復執行

·? 提供壓測報告：QPS，響應時間，錯誤率等數據

? ? ?? 同時，為了壓測不影響線上用戶的真實流量，我們構建了單獨的壓測資源池。在需要壓測時，選擇資源池中的機器和帶壓測模塊，可自動構建壓測環境。

（3）什么情況下需要壓測？

·? 例行壓測：版本灰度期間對重點項目進行例行壓測。

·? 新項目/接口上線前壓測：新項目上線前壓測，指導容量預估和限流配置。

3.1.4 接口撥測

? ? ? ?對于后臺接口服務，我們比較關心線上接口返回的數據是否正確以及新代碼上線是否影響了已有邏輯？接口撥測可以很好的覆蓋上面兩個問題。一方面可以用于線上接口返回數據的校驗，實時發現接口異常。另一方面可以用于自動化接口測試，配合上線流程，發現新增代碼是否有引入的問題，及時終止上線操作。一個接口撥測系統應具備如下特性：

（1）支持對接口返回結果做校驗。

（2）復雜校驗支持編寫腳本。

（3）可設置多個撥測點，模擬正式用戶請求場景。

（4）支持報警。

（5）詳細的測試報告。

（6）和上線流程打通，支持灰度后的自動化接口測試。

3.2

運維上線

3.2.1 灰度上線機制

? ? ? ?代碼在測試環境測試通過并不能保證代碼完全沒有問題，仍然有可能因為測試疏漏或環境差異等原因導致未發現的問題。如果沒有灰度上線的機制，這些潛在問題直接上線，可能對線上系統帶來災難性的后果。

? ? ? ?灰度上線需要配合灰度檢查來確保本次上線的安全性。我們采用的檢查方式有：

（1）灰度上線后針對灰度機器進行自動化接口檢測。

（2）對比灰度機監控指標和線上機器的監控指標。

（3）灰度環境測試功能驗收。

3.2.2 上線回滾

? ? ? ?如果發生因為上線新代碼導致的線上問題，首先要做的應該是回滾操作，而不是去分析問題和修復代碼上線。回滾操作需要盡量做到以下幾點：

（1）回滾速度快，如果需要revert代碼，重新編譯打包，上傳至服務器，整個流程會比較漫長，故障恢復的時間也會比較長。

（2）回滾完整，有些代碼和配置文件是有依賴的，如果只回滾了代碼，可能導致啟動后的異常。

（3）可回滾性，這需要架構層面的思考，不要出現無法回滾的情況，如上線后數據寫入，對回滾后的代碼不兼容。

? ? ???我們采用的是RPM打包的方式進行上線和回滾。通過RPM的形式把一次部署的所有內容（代碼和配置）打包，部署時服務器保留歷史版本的RPM包，當需要回滾時，直接執行Job安裝歷史版本的RPM包即可。如果服務采用的是容器部署，則回滾起來會更簡單，只需啟動歷史版本的鏡像即可。

3.3

線上可用性

3.3.1 系統保護

? ? ? ?線上運行時可能面對各種各樣的問題，機器故障，網絡問題，依賴的服務方掛掉，流量劇增等等。如何在如此險惡的環境下生存？不能相信別人，只能提升服務自身的可靠性。一般采取方式有：熔斷，限流，降級，重試等。

熔斷

? ? ? 當我們依賴的服務方有問題時，不能把我們的服務拖垮，常用的方式是熔斷。當依賴方成功率低于我們設置的閾值時，暫停對其調用，過一定間隔再去重試。

? ? ? 常用的熔斷組件有：Hystrix，Sentinel等。下表是Hystrix和Sentinel的對比。

? ? ? 鑒于Netflix對Hystrix不再維護，以及Sentinel更加豐富的功能，我們選擇了Sentinel作為我們的熔斷組件。

降級

? ? ? ?當發生突發事故，服務整體超負載時，為了避免服務整體不可用，一般會啟用服務降級，以保證重要或基本服務正常運行，非重要服務延遲使用或暫停使用。

? ? ? ?為此，我們實現了一個頁面降級服務。該服務會定時請求頁面接口，并對其進行校驗，校驗通過后將結果保存起來；當服務出現異常或超負載時，打開降級開關，頁面服務會直接讀取之前保存的靜態頁面數據返回。犧牲個性化，從千人千面降級為千人一面。由于去除了頁面構造的流程，處理能力會大幅提升，保證服務的正常運行。

限流

? ? ? ?限流非常重要，它是保護服務正常運行的重要關卡。尤其是在出現流量突增時，合理的限流可以保護你的服務不被打垮。如果沒有配置限流，不但流量突增時服務會被打垮，服務也難以恢復，因為服務重啟后會被再次打垮。

? ? ? ?我們一般會在網關層和服務層分別配置限流。

? ? ? ?網關層使用nginx的限流插件可以配置單機的限流。

? ? ? ?服務層使用Sentinel限流。Sentinel可以基于QPS，并發數，調用關系來限流，并且支持集群整體限流。下圖是Sentinel集群限流的實現。

重試

? ? ?從客戶端到后端服務，中間各個環節都有可能出現異常，如DNS故障，運營商節點故障，后臺服務器故障等等，導致請求失敗。

? ? ? 針對不同的情形，適當的重試可以增加請求成功率。愛奇藝APP端的重試分為如下幾種：

1. IP直連重試，通過配置直連IP數來控制重試次數。

2. 超級管道重試，公司自研基于HTTP的網關代理服務，可做到異地重試。

3. HTTP重試。

4.原url重試。

? ? ? 詳細信息可以參考公眾號文章《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》。

? ? ? ?重試可以提高成功率，但是過度重試可能會導致后端服務壓力過大，出現雪崩效應。所以重試策略上應該注意如下幾點：

1. ?重試策略可云控，極端情況下可后臺配置關閉重試。

2. ?區分錯誤碼重試，不是所有錯誤碼都需要重試，如后臺觸發限流返回的錯誤碼就不需要重試。

3.3.2 數據備份

? ? ? ?在數據庫的使用上，我們需要考慮數據庫的高可用。在這方面，公司的服務云團隊做了很多方面的優化，大家可以在公眾號文章里查詢到，本文就不詳細展開了。作為業務方，我們需要注意的是數據庫的使用要嚴格按照兩地三中心的架構申請和使用。

3.3.3 監控報警

? ? ? ?完善的監控報警可以讓我們在服務出現問題的第一時間感知到，及時處理，避免問題的擴散。從不同的緯度，我們需要不同的監控，主要包括：

指標監控

? ? ?監控服務的關鍵指標，這里包括3部分：機器指標（CPU，內存，網絡流量等），服務指標（QPS，成功率，響應時間等），第三方接口指標（QPS，成功率，響應時間等）。

? ? ? 具體的實現方案是：通過Collectd和自研Meerkat組件進行指標上報，上報給Graphint進行匯總存儲，并通過Grafana進行展示。

應用日志監控

? ? ? 基于應用日志的監控可以讓我們發現更加細粒度的異常，如應用內拋出的異常，內部業務邏輯錯誤等。

? ? ? ?首先我們定義了一套日志打印的格式規范，所有需要監控的日志都按統一的格式進行日志輸出。然后通過日志收集組件Venus將機器上的日志投遞到Kafka隊列，最終入到Druid時序數據庫內，進行多維度的分析存儲。前端報表使用Graphna進行展示。

全鏈路監控

? ? ? ?如果要監控上下文的鏈路關系、跨系統的故障定位等相關問題，需要進行全鏈路監控。詳細信息可以參考公眾號文章《愛奇藝全鏈路自動化監控平臺的探索與實踐》。

3.3.4 應急預案

? ? ? ?盡管我們上面列舉了一系列的可用性優化措施，但在真實的線上環境里，仍然會出現各種各樣的異常，故障，需要我們進行手動處理。當問題真正出現時，如果現場去想應該如何處理，可能由于慌亂而沒有做到最優的處理方案。因此，我們需要提前想好可能出現的問題，以及出現這些問題時應該如何處理，并形成書面的文檔。在問題出現時，我們只需要對著文檔一步一步處理即可。

04

# 服務質量檢查

? ? ? ?有了優化方案，如何判斷服務有沒有按照優化方案實施？如何保證服務長期保持較高的可用性？我們不希望做完一輪優化，服務成熟度提升之后，長期沒有跟進的話，服務成熟度又慢慢的開始下降。

? ? ? ?因此對這些常見的服務成熟度指標進行了自動化的檢查，并形成每日的健康度報告，把服務的成熟度監控起來。一旦有某項指標出現異常，我們能夠及時處理。這樣使我們的服務成熟度保持長期的穩定狀態。

總結與展望

? ? ? ?在本文介紹了愛奇藝提出的服務成熟度模型的定義，以可量化的指標來評估服務的成熟度。然后以該模型為標準，對后臺服務進行了評估，并總結了各個后臺服務普遍得分較低的指標項。針對這些低分項，梳理了優化方案。并建立了自動化的服務質量檢測機制，以保證服務成熟度的長期穩定。

? ? ? ?通過可用性優化，多個重要服務的成熟度模型評分都已經提升到了8分以上，并通過自動化的服務質量檢測機制，長期監測成熟度的各個指標，一旦發現某些指標異常，及時進行修復改進。

? ? ? 未來，會在下面兩點進行持續的改進和增強：

1. ??成熟度模型評分的自動化。避免人工評分的主觀因素，同時提升效率。

2. ??自動化的服務質量檢測機制增加更多的指標。

? ? ? ?希望通過基于服務成熟度模型的優化，使我們的服務可用性得到持續的提升。

也許你還想看

愛奇藝號基于Prometheus的微服務應用監控實踐

愛奇藝微服務監控的探索與實踐

掃一掃下方二維碼，更多精彩內容陪伴你！

總結

以上是生活随笔為你收集整理的基于微服务成熟度模型的高可用优化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。