中間件技術及雙十一實踐·穩定性平台篇穩定性平台——系統穩定運作的保障者

大多數網際網路公司都會根據業務對自身系統做一些拆分，大變小，1變n，系統的複雜度也n倍上升。當面對幾十甚至幾百個應用的時候，再熟悉系統的架構師也顯得無能為力。穩定性平台從2011年就開始了依賴治理方面的探索，目前實作了應用級别和接口級别的依賴自動化治理。在2013的雙11穩定性準備中，為共享交易鍊路的依賴驗證和天貓破壞性測試都提供了支援，大幅度減小了依賴治理的成本和時間。另一方面，線上容量規劃的一面是穩定性，另一面是成本。在穩定性和成本上找到一個最佳的交彙點是線上容量規劃的目的所在。通過容量規劃來進行各個系統的機器資源配置設定，在保證系統正常運作的前提下，避免對機器資源的過度浪費。

依賴治理的一些基礎概念

依賴模型分為關系、流量、強弱，實際的使用場景有：

依賴關系：線上故障根源查找、系統降級、依賴容量、依賴告警、代碼影響範圍、系統釋出順序、循環依賴等。

依賴流量：配置設定流量比、優化調用量、保護大流量。

依賴強弱：線上開關演練，系統改造評估。

關系資料可以通過人工梳理、代碼掃描、線上端口掃描的方式擷取。流量資料可以通過分析調用日志的方式擷取。強弱資料則必須通過故障模拟才能拿到。故障模拟分為調用屏蔽和調用延遲兩種情況，分别代表服務不可用和服務響應慢的情況。依賴的級别分為應用級依賴和接口方法級依賴，兩個級别的故障模拟手段完全不同，下面分開來描述。

應用級别強弱依賴檢測

應用級别故障模拟比較做法有幾種，即：修改代碼，寫開關，遠端調試，填錯服務的配置項。這幾種方式對配置人要求相對較高，并且對應用代碼有一定的侵入性，是以沒有被我們采用。linux有一些原生的指令（如iptables、tc）預設就有流量流控功能，我們就是通過控制linux指令來達到模拟故障的效果。指令舉例：

上面的指令表示：目前主機屏蔽掉來自xxx.xxx.xxx.11的網絡包。

指令表示：在網卡eth0上面設定規則，對xxx.xxx.xxx.111的網絡包進行延遲，延遲的時間是6000ms。

接口級别強弱依賴檢測

理想情況下，我們希望确定任意一次遠端方法調用的強弱，确定到接口方法級别的強弱資料。要想達到這個目的，就隻能在通信架構和一些基礎設施上面做文章。基于這個思路，我們設計了接口級别強弱依賴檢測的方案。方案如下：

過濾規則配置元件(伺服器端)

過濾規則配置元件提供一個web界面給使用者，接受使用者配置的屏蔽指令和測試機器ip資訊，并把配置資訊更新到配置中心元件中去。

配置的規則舉例：

上面的規則分别表示在用戶端發起對遠端接口xxx.itemreadservice:1.0.0.daily的queryitembyid~lqa調用時，在用戶端模拟一次異常或延遲4000毫秒後調用。

配置中心元件

配置中心元件的主要作用是接受用戶端（過濾規則配置元件）發來的配置資訊，持久化配置資訊到存儲媒體中，并實時把配置資訊實時推送到配置中心的所有用戶端（即每一個故障模拟元件）。此部分功能通過中間件開源産品diamond實作。

分布式服務調用元件

發生rpc調用時，會傳遞一些調用資訊，如：rpc發起者的ip、目前的方法名稱、下一級調用的方法名稱。

故障模拟元件

故障模拟元件是一個插件，可以被服務調用元件（hsf）加載。插件可以接受配置中心推送的配置資訊，在服務調用元件發生調用前都比對一下據配置資訊的内容，當rpc發起者的ip、調用方法都合條件的時候，發生故障模拟行為，進而達到故障模拟的效果。

線上容量規劃最重要的一個步驟為線上壓力測試，通過線上壓力測試來得知系統的服務能力，同時暴露一些在高壓力場景下才能出現的隐藏系統問題。我們搭建了自己的線上自動壓測平台來完成這一工作，線上自動壓測歸納起來主要包含4種模式：模拟請求、複制請求、請求引流轉發以及修改負載均衡權重。

模拟請求

完全的假請求，可以通過代碼或者采用工具進行模拟，常用到的工具有http_load、webbench、apache ab、jmeter、siege等。模拟請求有一個很明顯的問題，即如何處理“寫請求”？一方面由于“寫請求”的場景不大好模拟（一般需要登入），另一方面“寫請求”将要面臨如何處理一緻性場景和髒資料等。模拟請求方式的壓測結果準确性我們認為是最低的。

複制請求

可以看成是半真實的假請求。說它半真實，因為它是由複制真實請求而産生。說它是假請求，因為即使複制的真實請求，它的響應是需要被特殊處理的，不能再傳回給調用方（自從它被複制的那一刻，它就已經走上了不真實的軌道）。複制請求同樣可以通過代碼實作（比如我們有通過btrace去複制對服務的調用）， 此外也有一些比較好用的工具：比如tcpcopy等。如果想在nginx上做請求複制，可以通過nginx的nginx post_action來實作。“複制請求”模式被壓測的那台機器是不能提供服務的，這将是一個額外的成本，此外複制請求模式的壓測結果準确性也會由于它的半真實而打上折扣。

請求引流轉發

完全真實的壓測模型，常用于叢集式部署的web環境當中。我們對于apache和nginx的系統基本上都采取這種方式來做線上壓力測試。用到的方式主要通過：apache 的mod_jk和 mod_proxy子產品；nginx的proxy以及upstream等。這種方式壓測的結果準确性高，唯一的不足是這種方式依賴系統流量，如果系統流量很低，就算是将所有的流量引到一台機器上面，仍不足以達到壓測目的。請求引流轉發模式的壓測結果準确性高。

修改負載均衡權重

同樣為完全真實的壓測模型，可以用于叢集部署的web環境中，也可用于叢集部署的服務類系統。在web環境中我們通過修改f5或者lvs的機器負載均衡權重來使得流量更多的傾斜到其中的某一台後者某幾台機器上；對于服務類系統，我們通過修改服務注冊中心的機器負載均衡權重來使得服務的調用更多配置設定到某一台或者某幾台機器上。修改負載均衡權重式的壓測結果準确性高。

系統的服務能力我們定義為“系統能力”。在系統機器配置都差不多的情況下，系統能力等于線上壓力測試擷取的單台服務能力乘以機器數。在得知了系統能力之後，接下來我們需要知道自己的系統跑在怎麼樣的一個容量水位下，進而指導我們做一些決策，是該加機器了？還是該下掉一些多餘的機器？通常系統的調用都有相關日志記錄，通過分析系統的日志等方式擷取系統一天當中最大的調用頻率（以分鐘為機關），我們定義為系統負荷；目前一分鐘的調用頻率我們定義為目前負荷。計算系統負荷可以先把相關日志傳到hdfs，通過離線hadoop任務分析；計算目前負荷我們采用storm的流式計算架構來進行實時的統計。

水位公式

系統水位 = 系統負荷 / 系統能力；目前水位 = 目前負荷 / 系統能力。

水位标準

單機房（70%）；雙機放（40%)；三機房（60%）。

單機房一般都是不太重要的系統，我們可以壓榨下性能；

雙機房需要保障在一個機房完全挂掉的情況下另一個機房能夠撐得住挂掉機房的流量；

三機房同樣需要考慮挂掉一個機房的場景後剩下兩個機房能夠撐得住挂掉機房的流量。

機器公式

理論機器數 = （實際機器數 * 系統負荷 * 系統水位）/ （系統能力 * 水位标準）

機器增減 = 理論機器數 – 實際機器數

強弱依賴檢測面臨的最大挑戰就是如何使使用者使用友善，接入成本最小，主要需要解決下面兩件事情：

如何複用現有的測試用例？

我們開發一個注解包，裡面封裝與csp的互動協定。伺服器端完成測試環境的管理，測試用例端專注應用系統的驗證。這是一種測試平台無關的方式，不需要修改現有的測試代碼，隻需要配置注解的方式就使測試用例支援了強弱依賴驗證的功能。

如何解決故障模拟元件覆寫不全導緻的驗證局限？

依賴調用一定存在client和server端，很有可能出現一端沒有安裝故障模拟元件的情況。為此，我們改造了故障描述協定，增加了client和server兩種模式，隻要client或server有一方安裝了故障模拟元件就可以完成強弱依賴校驗。

穩定性平台通過依賴治理、容量規劃、降級管理、實時監控等手段，對阿裡各系統穩定性的治理給予了支援。未來我們将繼續深挖穩定性這個領域，彙總各種資料，真正做到穩定性的智能化、自動化。