2016中國應用性能管理大會運維自動化專場58到家架構師任桃術題為《58到家服務治理和跟蹤系統》的演講，現場解讀了會重點講解58到家在處理對系統性能的監控、流量監控、快速擴容等難點上的解決方案和監控系統的設計思路。

大家下午好，我叫任桃術，來自58到家。今天給大家分享的主要內容是《58到家服務治理實踐》。

我們從三個方面來進行，第一個是為什么需要服務治理，第二個是58到家是怎樣在服務治理這一塊實踐做了哪些事情，讓系統能夠更好的運行;最后是小結。

為什么需要服務治理?

早期58到家也是一個初創型的公司，包括家政、麗人、速運、三方平臺，早期因為是初創公司大家都忙于滿足需求的研發，很少對一些公共服務或者公共組件進行分裝。

那時候我們有不同的研發團隊在維護著不同的業務，所以說出現了很多類似的重復系統，比如說收銀臺，或者訂單、支付系統等等。這樣會導致什么問題?代碼重復率高，可維護性非常差。另外我們在做一些測試或者開發，包括一些迭代更新的時候，如果沒有一些公共服務，在每個不同業務線只要有一部分功能修改，所有的業線都都要做調整，無法做到敏捷交付。

另外在數據這一塊，我們早期也是怎么快怎么做。很多業務系統的數據，之前是在一個大庫里面大概有好幾百張表，后續根據業務的特征，系統的職責做了一些解耦。初創性公司還是以需求響應快為目標，但是現有架構不能滿足58到家迅猛的業務發展需求，所以我們有了后續一系列的動作。

服務化+立體化監控

做的就是服務化+立體化監控。首先要做的一件事情就是服務拆分，我們根據業務的特征以及系統的職責做了一些垂直劃分，同時根據業務之間的交互處理，通過消息的方式實現了解耦做了水平拆分。通過服務化我們可以做到把之前一些工作的模塊解耦，做到服務快速擴容。我們完成現有監控可以做到比較及時發現問題，不至于很被動的響應客服的投訴。

雖然做了架構升級，但是還是面臨另外一個問題：我們服務化同時系統規模越來越大，整體架構越來越復雜，服務也越來越多，服務之間調用的關系也越來越復雜，導致在排查某一個問題時很可能出現整個調用鏈太長，在排查問題的時候無法很快的定位問題具體發生在哪一層，所以我們又做了后續的一些動作。

到家服務治理實踐

今天主要講一下58到家針對服務治理開展的事情。主要包括綠框里面的幾部分內容，后續重點講一下58到家是怎樣在服務化治理的路上，做了哪些事情。
 

       如果做服務化肯定要把服務的地址暴露出來，我們會有一個注冊中心，這個中心的實現有多種。大致的做法是會把注冊中心跟服務提供者和服務消費者聯系起來，我們會有一個長鏈接的保持，當為服務方啟動的時候，就可以把服務提供者的信息，包括服務的名稱，或者服務的端口上報到注冊中心。對于消費者來說，他們會根據業務的需要，將這些服務真正發起遠程調用時從注冊中心獲取相應消費者的信息。我們做服務擴容，對于客戶方來說對服務地址是無感知的。早期初創性公司在服務擴容的時候，是需要更改服務的一些配置節點，需要整體服務才能達到這樣的效果。

另外就是基于注冊中心，我們可以做服務的分組以及安全的測量。比如說不同的業務方會有不同的需求優先級或者說系統的重要性，我們會根據不同的業務方給它進行不同的服務分組，這樣可以做到服務的隔離。

另外還有一些工作也是通過注冊中心做的，我們可以做一些TCP心跳監測，保證服務的可用性。

高可用這方面，因為注冊中心是一個強依賴的東西，不管是服務提供者還是服務的消費者，都是強依賴的組件，所以注冊中心的重要性就不言而喻了，必須要保證注冊中心的高可靠性。通過兩個方面，一方面就是本身注冊中心是有儲備的。另外在消費者這邊，當挖取到了注冊中心服務提供方的配置信息之后，可以在本地做一個備份，這樣就可以不再那么強依賴于注冊中心了，這是服務的發布和訂閱。
 

另外針對一個服務集群，需要做相應的服務集群路由和容錯。

服務集群路由&容錯

路由的方式，我們現在的是隨機、輪洵、基于權重、基于負載的，無法根據現有服務器配置做負載的分發。基于權重也是初始化的時候，有一個靜態的分配。負載比如說客戶端根據服務器返回的響應時間，決定后續請求的分發。

其次，我們有一系列的路由策略現在也是配置化的，可以根據IP地址段做路由，同時可以根據方法名稱，比如說要做讀寫分離，可以根據方法查詢的，還是說更新的或是新增的，可以做不同的方法名匹配，再做相應路由。服務分組，我們可以根據實際業務的場景，業務的重要性，對服務進行分組，做相應的隔離。

另外還有一些特殊的需求，可能會根據某一些業務特征，需要把服務路由到固定的某一服務器上，根據特殊的路由規則提供路由的擴展，可以給業務線做相應特殊化的路由。

容錯方面最主要一點就是故障轉移。現在在做服務化的時候，我們都是要求是冪等的服務。做故障轉移時如果一個服務不是冪等的，可能會出現我們本身不期望的結果。

失敗緩存也有相應的機制，我們可以將失敗的一些請求，在本地做一個延時的訪問，再過段時間重試這個服務是不是可以了。失敗通知與快速失敗，也是為了更好的快速返回。

路由和容錯這一塊，在實踐過程中間需要注意，首先我們必須保證服務是無狀態。如果說真要是有一些跟狀態相關的業務，我們建議是把它放到數據層，或者通過緩存的方式把跟狀態有關的數據存儲。當一個節點出問題的時候，我們重設可用的其他節點。

在重試過程中要注意一下會有一個延時，我們不可能無限制的做重試。因為在客戶端一般往往會設置時間，如果客戶端做了太多嘗試，對應整個業務的返回已經沒有必要重試了，因為業務方那邊已經出問題了。這是在路由和容錯這一塊，我們做的一些事情。

流量控制&流量告警

為了對服務做一些過載的保護，我們做了流控和流量的告警。流控就是要保命，當我的請求不管是因為活動出大錯，還是一些誤操作或者非法調用導致整個數據請求突然上來之后，要做好相應工作。首先會設置一個流控的閾值，當訪問量達到閾值80%的時候會有提前告警，不至于很被動的去解決問題，或者說沒有相應足夠的時間讓我們去準備處理問題。

當真正發生流量高峰的時候，我們要做的事情理想的是自動擴容，現在是通過手動的快速擴容來做的。手動快速擴容必須輔助注冊中心，消費者這邊對服務的地址是透明的，客戶方不用做任何調整，能夠讓客戶端做到快速擴充。

做流控閾值的在線調整，這個時候可以做到實時生效的。之前設置的閾值可能不合理，或者沒有到特殊業務場景，我們可以做到實時在線調整閾值。

流量告警的話，我們會有的閾值，另外還有波段的閾值，這一分鐘和上一分鐘比較流量是不是有比較大的波動，如果有大的波動，不管是流量突然上升還是突然下降都有流量波動的告警，下圖是58到家流控的頁面，可以做到服務節點級別，對應服務的方法級別，現在是按每分鐘的方式，通過數據縮減上報，實時掌握數據。
 

另外一個就是資源數的限制，數據庫的資源數一般設置也是閾值，包括最小值和值。最小值主要是解決高峰突然來臨的時候，數據庫硬件如果真不夠，可以提前預分配一部分硬件。的硬件也是對數據庫更好的保護，如果數據庫出問題了，整個服務基本上也會出問題。

另外一個是工作線程數的控制，主要是通過線程模型。比如說IO線程跟未來的數據包放到對應的工作線程里面處理，通過對應的方式先把所有的請求放到一個對象里面，工作線程再從對象里面獲取相應的任務。我們也借鑒了一些變化和實踐，每個線程組會有一個工作對點，可以設置相應的性能數，實現配置多個線程組，每個線程組擁有字節統一的工作隊列，減少在高并發情況下的競爭。對于線程組和每個線程組里面的線程數，現在都是可以做到聯合的配置。
 

我們做服務化的時候，隨著架構的升級服務數量會越來越多。在排查問題的時候，特別是一些業務非常復雜的服務，整個的調用鏈是非常長的。之前印象比較深刻，出來一個問題排查時間會特別長。針對現狀我們做了服務工作系統，主要是基于日志的收集，我們開發了一個公共的日志組件，海量的日志上報都可以支持，每分鐘會把相應的請求和調用相關的一些信息統一上報到日志收集平臺。現在基本上涵蓋了所用的全部框架，自研的Web框架、服務框架，以及相應的客戶端和數據庫的中間件，這些都是通過插件的方式，把每個框架的日志調用的信息統一上報到日平臺，做一些實時的展示以及后續業務調用數據的分析。

這是我們的效果圖。
 

我們可以做到根據這個請求的參數，比如說前端有一筆訂單的請求，可以根據訂單的參數以及用戶ID等等做一些調用的檢索，特別是排查問題的時候，出現異常或者說服務的請求耗時特別長的時候，可以很快的從后臺檢索到有問題的一些調用鏈，進而做出一些優化。

調用跟蹤系統，大致講一下相關的技術點。首先就是整個調用鏈我們要從前端站點到服務層、數據層，整個調用關系或者調用鏈給串起來，主要依賴于兩個元素：一個是有一個全局的調用的工作ID，把我們所有的調用請求通過這個ID給串起來，這樣在定位問題的時候，可以排查到每個調用環節。另外還有一個調用的層級關系，比如說一個站點里面調了好幾個服務，設計了評級調用關系。另外這個服務本身內部調了下游其他服務，也可以很方便的通過后臺系統看得見。

由于是分布式的系統，整個調用鏈不是在某一臺服務器上面可以全部搜集的到，往往是跨服務器，對于不同服務器之間調用鏈的數據怎么樣透傳?如果同一臺服務器，同一個虛擬機里面的服務解決調用，我們是通過線上變量去做的這件事情。通過協議層面特別是跨服務器調用的時候，把這些數據放在協議里面，傳輸到另外一端。

另外調用鏈在推廣的過程中發現了一個問題，當我們全量推調用鏈的時候數據量特別大。所以我們做了全量的調用鏈相關的數據采集和采樣的方式，對于核心服務我們會有全量。采樣也可以解決出了問題的時候可以比較快速的定位，一般情況下出問題的時候，會有一定的延續性，調用也是相對比較隨機的，所以采樣是可以采到有問題的數據。這是調用跟蹤系統一些相關的實踐工作。

調用跟蹤系統可以發現每一次調用可能存在的問題，也可以以圖形的方式很快的看到我們想要知道的一些數據，這是針對每一次調用。另外針對調用鏈，每天會做一個數據全量的分析，主要的目的就是說我們想知道整個或者說以集群為單位，這個集群下面依賴于哪些下游，然后我們給哪些上游提供相應的服務，這樣可以反向的來推動服務架構的優化，因為有可能會出現像循環依賴或者說調用鏈特別長。而調用鏈特別長的原因，本身可能是業務的不合理，或者說本身設計的時候有一些拆分做得不是特別好，通過服務依賴以及調用鏈上報的數據，我們可以發現架構層面的問題，進而反推架構的優化。

最后是一個小結，今天主講的內容主要是為什么我們要做服務治理以及58到家是怎樣做的。服務治理一般是會伴隨服務化去做一些服務的拆分，目的就是為了更好的解耦，為了更好的做服務擴容等等。

服務發布主要解決的是服務地址的透明化，以及基于注冊中心的集中管理。

路由和容錯主要是解決可用性以及服務負載的問題。

流控和告警主要是為了做過載保護。

數據庫的鏈接數，線程數、資源數的控制，也是對服務做更好的保護以及可以怎樣讓我們的服務更好的響應客戶端的請求，怎樣提高閉環量。

最后一點是調用跟蹤系統，面臨著很多拆分出來的微服務，它們之間的調用關系特別復雜，為了更快速的定位線上問題所以我們有了調用跟蹤系統，基于調用跟蹤系統，可以根據調用關系去反推架構的優化。

關于APMCon：

2016中國應用性能管理大會(簡稱APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召開。APMCon由聽云、極客邦和InfoQ聯合主辦的作為國內APM領域影響力的技術大會，舉辦的APMCon以“驅動應用架構優化與創新”為主題，聚焦當前最為熱門的移動端、Web端和Server端的性能監控和管理技術，整個會議設置包含了：性能可視化、服務端監控實踐、運維自動化、數據庫性能優化、APM云服務架構和HTML5調優實踐等話題，致力于推動APM在國內的成長與發展。