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

綜述

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

7.1、依賴治理實踐

依賴治理的一些基礎概念

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

依賴關係：線上故障根源查找、系統降級、依賴容量、依賴告警、代碼影響範圍、系統發佈順序、循環依賴等。
依賴流量：分配流量比、優化調用量、保護大流量。
依賴強弱：線上開關演練，系統改造評估。

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

應用級別強弱依賴檢測

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

iptables -A INPUT -s xxx.xxx.xxx.111 -j DROP

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

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 6000ms
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dst xxx.xxx.xxx.111/32 flowid 1:1

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

接口級別強弱依賴檢測
理想情況下，我們希望確定任意一次遠程方法調用的強弱，確定到接口方法級別的強弱數據。要想達到這個目的，就只能在通信框架和一些基礎設施上面做文章。基於這個思路，我們設計了接口級別強弱依賴檢測的方案。方案如下：

過濾規則配置組件(服務器端)
過濾規則配置組件提供一個web界面給用戶，接受用戶配置的屏蔽指令和測試機器IP信息，並把配置信息更新到配置中心組件中去。
配置的規則舉例：

client|throw|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|java.lang.Exception
client|wait|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|4000

上面的規則分別表示在客戶端發起對遠程接口xxx.ItemReadService:1.0.0.daily的queryItemById~lQA調用時，在客戶端模擬一次異常或延遲4000毫秒後調用。

配置中心組件

配置中心組件的主要作用是接受客戶端（過濾規則配置組件）發來的配置信息，持久化配置信息到存儲介質中，並實時把配置信息實時推送到配置中心的所有客戶端（即每一個故障模擬組件）。此部分功能通過中間件開源產品Diamond實現。

分佈式服務調用組件

發生RPC調用時，會傳遞一些調用信息，如：RPC發起者的IP、當前的方法名稱、下一級調用的方法名稱。

故障模擬組件

故障模擬組件是一個插件，可以被服務調用組件（HSF）加載。插件可以接受配置中心推送的配置信息，在服務調用組件發生調用前都比對一下據配置信息的內容，當RPC發起者的IP、調用方法都合條件的時候，發生故障模擬行爲，從而達到故障模擬的效果。

7.2、容量規劃實踐

線上容量規劃最重要的一個步驟爲線上壓力測試，通過線上壓力測試來得知系統的服務能力，同時暴露一些在高壓力場景下才能出現的隱藏系統問題。我們搭建了自己的線上自動壓測平臺來完成這一工作，線上自動壓測歸納起來主要包含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%）。
單機房一般都是不太重要的系統，我們可以壓榨下性能；
雙機房需要保障在一個機房完全掛掉的情況下另一個機房能夠撐得住掛掉機房的流量；
三機房同樣需要考慮掛掉一個機房的場景後剩下兩個機房能夠撐得住掛掉機房的流量。

機器公式

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

7.3、穩定性平臺雙11準備與優化

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

如何複用現有的測試用例？
我們開發一個註解包，裏面封裝與CSP的交互協議。服務器端完成測試環境的管理，測試用例端專注應用系統的驗證。這是一種測試平臺無關的方式，不需要修改現有的測試代碼，只需要配置註解的方式就使測試用例支持了強弱依賴驗證的功能。
如何解決故障模擬組件覆蓋不全導致的驗證侷限？
依賴調用一定存在client和server端，很有可能出現一端沒有安裝故障模擬組件的情況。爲此，我們改造了故障描述協議，增加了client和server兩種模式，只要client或server有一方安裝了故障模擬組件就可以完成強弱依賴校驗。