2016中國(guó)應(yīng)用性能管理大會(huì)運(yùn)維自動(dòng)化專場(chǎng)58到家架構(gòu)師任桃術(shù)題為《58到家服務(wù)治理和跟蹤系統(tǒng)》的演講，現(xiàn)場(chǎng)解讀了會(huì)重點(diǎn)講解58到家在處理對(duì)系統(tǒng)性能的監(jiān)控、流量監(jiān)控、快速擴(kuò)容等難點(diǎn)上的解決方案和監(jiān)控系統(tǒng)的設(shè)計(jì)思路。
大家下午好，我叫任桃術(shù)，來(lái)自58到家。今天給大家分享的主要內(nèi)容是《58到家服務(wù)治理實(shí)踐》。
我們從三個(gè)方面來(lái)進(jìn)行，第一個(gè)是為什么需要服務(wù)治理，第二個(gè)是58到家是怎樣在服務(wù)治理這一塊實(shí)踐做了哪些事情，讓系統(tǒng)能夠更好的運(yùn)行;最后是小結(jié)。
為什么需要服務(wù)治理?
早期58到家也是一個(gè)初創(chuàng)型的公司，包括家政、麗人、速運(yùn)、三方平臺(tái)，早期因?yàn)槭浅鮿?chuàng)公司大家都忙于滿足需求的研發(fā)，很少對(duì)一些公共服務(wù)或者公共組件進(jìn)行分裝。
那時(shí)候我們有不同的研發(fā)團(tuán)隊(duì)在維護(hù)著不同的業(yè)務(wù)，所以說(shuō)出現(xiàn)了很多類似的重復(fù)系統(tǒng)，比如說(shuō)收銀臺(tái)，或者訂單、支付系統(tǒng)等等。這樣會(huì)導(dǎo)致什么問(wèn)題?代碼重復(fù)率高，可維護(hù)性非常差。另外我們?cè)谧鲆恍y(cè)試或者開(kāi)發(fā)，包括一些迭代更新的時(shí)候，如果沒(méi)有一些公共服務(wù)，在每個(gè)不同業(yè)務(wù)線只要有一部分功能修改，所有的業(yè)線都都要做調(diào)整，無(wú)法做到敏捷交付。
另外在數(shù)據(jù)這一塊，我們?cè)缙谝彩窃趺纯煸趺醋�。很多業(yè)務(wù)系統(tǒng)的數(shù)據(jù)，之前是在一個(gè)大庫(kù)里面大概有好幾百?gòu)埍�，后續(xù)根據(jù)業(yè)務(wù)的特征，系統(tǒng)的職責(zé)做了一些解耦。初創(chuàng)性公司還是以需求響應(yīng)快為目標(biāo)，但是現(xiàn)有架構(gòu)不能滿足58到家迅猛的業(yè)務(wù)發(fā)展需求，所以我們有了后續(xù)一系列的動(dòng)作。
服務(wù)化+立體化監(jiān)控
做的就是服務(wù)化+立體化監(jiān)控。首先要做的一件事情就是服務(wù)拆分，我們根據(jù)業(yè)務(wù)的特征以及系統(tǒng)的職責(zé)做了一些垂直劃分，同時(shí)根據(jù)業(yè)務(wù)之間的交互處理，通過(guò)消息的方式實(shí)現(xiàn)了解耦做了水平拆分。通過(guò)服務(wù)化我們可以做到把之前一些工作的模塊解耦，做到服務(wù)快速擴(kuò)容。我們完成現(xiàn)有監(jiān)控可以做到比較及時(shí)發(fā)現(xiàn)問(wèn)題，不至于很被動(dòng)的響應(yīng)客服的投訴。
雖然做了架構(gòu)升級(jí)，但是還是面臨另外一個(gè)問(wèn)題：我們服務(wù)化同時(shí)系統(tǒng)規(guī)模越來(lái)越大，整體架構(gòu)越來(lái)越復(fù)雜，服務(wù)也越來(lái)越多，服務(wù)之間調(diào)用的關(guān)系也越來(lái)越復(fù)雜，導(dǎo)致在排查某一個(gè)問(wèn)題時(shí)很可能出現(xiàn)整個(gè)調(diào)用鏈太長(zhǎng)，在排查問(wèn)題的時(shí)候無(wú)法很快的定位問(wèn)題具體發(fā)生在哪一層，所以我們又做了后續(xù)的一些動(dòng)作。
到家服務(wù)治理實(shí)踐
今天主要講一下58到家針對(duì)服務(wù)治理開(kāi)展的事情。主要包括綠框里面的幾部分內(nèi)容，后續(xù)重點(diǎn)講一下58到家是怎樣在服務(wù)化治理的路上，做了哪些事情。
如果做服務(wù)化肯定要把服務(wù)的地址暴露出來(lái)，我們會(huì)有一個(gè)注冊(cè)中心，這個(gè)中心的實(shí)現(xiàn)有多種。大致的做法是會(huì)把注冊(cè)中心跟服務(wù)提供者和服務(wù)消費(fèi)者聯(lián)系起來(lái)，我們會(huì)有一個(gè)長(zhǎng)鏈接的保持，當(dāng)為服務(wù)方啟動(dòng)的時(shí)候，就可以把服務(wù)提供者的信息，包括服務(wù)的名稱，或者服務(wù)的端口上報(bào)到注冊(cè)中心。對(duì)于消費(fèi)者來(lái)說(shuō)，他們會(huì)根據(jù)業(yè)務(wù)的需要，將這些服務(wù)真正發(fā)起遠(yuǎn)程調(diào)用時(shí)從注冊(cè)中心獲取相應(yīng)消費(fèi)者的信息。我們做服務(wù)擴(kuò)容，對(duì)于客戶方來(lái)說(shuō)對(duì)服務(wù)地址是無(wú)感知的。早期初創(chuàng)性公司在服務(wù)擴(kuò)容的時(shí)候，是需要更改服務(wù)的一些配置節(jié)點(diǎn)，需要整體服務(wù)才能達(dá)到這樣的效果。
另外就是基于注冊(cè)中心，我們可以做服務(wù)的分組以及安全的測(cè)量。比如說(shuō)不同的業(yè)務(wù)方會(huì)有不同的需求優(yōu)先級(jí)或者說(shuō)系統(tǒng)的重要性，我們會(huì)根據(jù)不同的業(yè)務(wù)方給它進(jìn)行不同的服務(wù)分組，這樣可以做到服務(wù)的隔離。
另外還有一些工作也是通過(guò)注冊(cè)中心做的，我們可以做一些TCP心跳監(jiān)測(cè)，保證服務(wù)的可用性。
高可用這方面，因?yàn)樽?cè)中心是一個(gè)強(qiáng)依賴的東西，不管是服務(wù)提供者還是服務(wù)的消費(fèi)者，都是強(qiáng)依賴的組件，所以注冊(cè)中心的重要性就不言而喻了，必須要保證注冊(cè)中心的高可靠性。通過(guò)兩個(gè)方面，一方面就是本身注冊(cè)中心是有儲(chǔ)備的。另外在消費(fèi)者這邊，當(dāng)挖取到了注冊(cè)中心服務(wù)提供方的配置信息之后，可以在本地做一個(gè)備份，這樣就可以不再那么強(qiáng)依賴于注冊(cè)中心了，這是服務(wù)的發(fā)布和訂閱。
另外針對(duì)一個(gè)服務(wù)集群，需要做相應(yīng)的服務(wù)集群路由和容錯(cuò)。
服務(wù)集群路由&容錯(cuò)
路由的方式，我們現(xiàn)在的是隨機(jī)、輪洵、基于權(quán)重、基于負(fù)載的，無(wú)法根據(jù)現(xiàn)有服務(wù)器配置做負(fù)載的分發(fā)�；跈�(quán)重也是初始化的時(shí)候，有一個(gè)靜態(tài)的分配。負(fù)載比如說(shuō)客戶端根據(jù)服務(wù)器返回的響應(yīng)時(shí)間，決定后續(xù)請(qǐng)求的分發(fā)。
其次，我們有一系列的路由策略現(xiàn)在也是配置化的，可以根據(jù)IP地址段做路由，同時(shí)可以根據(jù)方法名稱，比如說(shuō)要做讀寫(xiě)分離，可以根據(jù)方法查詢的，還是說(shuō)更新的或是新增的，可以做不同的方法名匹配，再做相應(yīng)路由。服務(wù)分組，我們可以根據(jù)實(shí)際業(yè)務(wù)的場(chǎng)景，業(yè)務(wù)的重要性，對(duì)服務(wù)進(jìn)行分組，做相應(yīng)的隔離。
另外還有一些特殊的需求，可能會(huì)根據(jù)某一些業(yè)務(wù)特征，需要把服務(wù)路由到固定的某一服務(wù)器上，根據(jù)特殊的路由規(guī)則提供路由的擴(kuò)展，可以給業(yè)務(wù)線做相應(yīng)特殊化的路由。
容錯(cuò)方面最主要一點(diǎn)就是故障轉(zhuǎn)移。現(xiàn)在在做服務(wù)化的時(shí)候，我們都是要求是冪等的服務(wù)。做故障轉(zhuǎn)移時(shí)如果一個(gè)服務(wù)不是冪等的，可能會(huì)出現(xiàn)我們本身不期望的結(jié)果。
失敗緩存也有相應(yīng)的機(jī)制，我們可以將失敗的一些請(qǐng)求，在本地做一個(gè)延時(shí)的訪問(wèn)，再過(guò)段時(shí)間重試這個(gè)服務(wù)是不是可以了。失敗通知與快速失敗，也是為了更好的快速返回。
路由和容錯(cuò)這一塊，在實(shí)踐過(guò)程中間需要注意，首先我們必須保證服務(wù)是無(wú)狀態(tài)。如果說(shuō)真要是有一些跟狀態(tài)相關(guān)的業(yè)務(wù)，我們建議是把它放到數(shù)據(jù)層，或者通過(guò)緩存的方式把跟狀態(tài)有關(guān)的數(shù)據(jù)存儲(chǔ)。當(dāng)一個(gè)節(jié)點(diǎn)出問(wèn)題的時(shí)候，我們重設(shè)可用的其他節(jié)點(diǎn)。
在重試過(guò)程中要注意一下會(huì)有一個(gè)延時(shí)，我們不可能無(wú)限制的做重試。因?yàn)樵诳蛻舳艘话阃鶗?huì)設(shè)置時(shí)間，如果客戶端做了太多嘗試，對(duì)應(yīng)整個(gè)業(yè)務(wù)的返回已經(jīng)沒(méi)有必要重試了，因?yàn)闃I(yè)務(wù)方那邊已經(jīng)出問(wèn)題了。這是在路由和容錯(cuò)這一塊，我們做的一些事情。
流量控制&流量告警
為了對(duì)服務(wù)做一些過(guò)載的保護(hù)，我們做了流控和流量的告警。流控就是要保命，當(dāng)我的請(qǐng)求不管是因?yàn)榛顒?dòng)出大錯(cuò)，還是一些誤操作或者非法調(diào)用導(dǎo)致整個(gè)數(shù)據(jù)請(qǐng)求突然上來(lái)之后，要做好相應(yīng)工作。首先會(huì)設(shè)置一個(gè)流控的閾值，當(dāng)訪問(wèn)量達(dá)到閾值80%的時(shí)候會(huì)有提前告警，不至于很被動(dòng)的去解決問(wèn)題，或者說(shuō)沒(méi)有相應(yīng)足夠的時(shí)間讓我們?nèi)?zhǔn)備處理問(wèn)題。
當(dāng)真正發(fā)生流量高峰的時(shí)候，我們要做的事情理想的是自動(dòng)擴(kuò)容，現(xiàn)在是通過(guò)手動(dòng)的快速擴(kuò)容來(lái)做的。手動(dòng)快速擴(kuò)容必須輔助注冊(cè)中心，消費(fèi)者這邊對(duì)服務(wù)的地址是透明的，客戶方不用做任何調(diào)整，能夠讓客戶端做到快速擴(kuò)充。
做流控閾值的在線調(diào)整，這個(gè)時(shí)候可以做到實(shí)時(shí)生效的。之前設(shè)置的閾值可能不合理，或者沒(méi)有到特殊業(yè)務(wù)場(chǎng)景，我們可以做到實(shí)時(shí)在線調(diào)整閾值。
流量告警的話，我們會(huì)有的閾值，另外還有波段的閾值，這一分鐘和上一分鐘比較流量是不是有比較大的波動(dòng)，如果有大的波動(dòng)，不管是流量突然上升還是突然下降都有流量波動(dòng)的告警，下圖是58到家流控的頁(yè)面，可以做到服務(wù)節(jié)點(diǎn)級(jí)別，對(duì)應(yīng)服務(wù)的方法級(jí)別，現(xiàn)在是按每分鐘的方式，通過(guò)數(shù)據(jù)縮減上報(bào)，實(shí)時(shí)掌握數(shù)據(jù)。
另外一個(gè)就是資源數(shù)的限制，數(shù)據(jù)庫(kù)的資源數(shù)一般設(shè)置也是閾值，包括最小值和值。最小值主要是解決高峰突然來(lái)臨的時(shí)候，數(shù)據(jù)庫(kù)硬件如果真不夠，可以提前預(yù)分配一部分硬件。的硬件也是對(duì)數(shù)據(jù)庫(kù)更好的保護(hù)，如果數(shù)據(jù)庫(kù)出問(wèn)題了，整個(gè)服務(wù)基本上也會(huì)出問(wèn)題。
另外一個(gè)是工作線程數(shù)的控制，主要是通過(guò)線程模型。比如說(shuō)IO線程跟未來(lái)的數(shù)據(jù)包放到對(duì)應(yīng)的工作線程里面處理，通過(guò)對(duì)應(yīng)的方式先把所有的請(qǐng)求放到一個(gè)對(duì)象里面，工作線程再?gòu)膶?duì)象里面獲取相應(yīng)的任務(wù)。我們也借鑒了一些變化和實(shí)踐，每個(gè)線程組會(huì)有一個(gè)工作對(duì)點(diǎn)，可以設(shè)置相應(yīng)的性能數(shù)，實(shí)現(xiàn)配置多個(gè)線程組，每個(gè)線程組擁有字節(jié)統(tǒng)一的工作隊(duì)列，減少在高并發(fā)情況下的競(jìng)爭(zhēng)。對(duì)于線程組和每個(gè)線程組里面的線程數(shù)，現(xiàn)在都是可以做到聯(lián)合的配置。
我們做服務(wù)化的時(shí)候，隨著架構(gòu)的升級(jí)服務(wù)數(shù)量會(huì)越來(lái)越多。在排查問(wèn)題的時(shí)候，特別是一些業(yè)務(wù)非常復(fù)雜的服務(wù)，整個(gè)的調(diào)用鏈?zhǔn)欠浅ｉL(zhǎng)的。之前印象比較深刻，出來(lái)一個(gè)問(wèn)題排查時(shí)間會(huì)特別長(zhǎng)。針對(duì)現(xiàn)狀我們做了服務(wù)工作系統(tǒng)，主要是基于日志的收集，我們開(kāi)發(fā)了一個(gè)公共的日志組件，海量的日志上報(bào)都可以支持，每分鐘會(huì)把相應(yīng)的請(qǐng)求和調(diào)用相關(guān)的一些信息統(tǒng)一上報(bào)到日志收集平臺(tái)。現(xiàn)在基本上涵蓋了所用的全部框架，自研的Web框架、服務(wù)框架，以及相應(yīng)的客戶端和數(shù)據(jù)庫(kù)的中間件，這些都是通過(guò)插件的方式，把每個(gè)框架的日志調(diào)用的信息統(tǒng)一上報(bào)到日平臺(tái)，做一些實(shí)時(shí)的展示以及后續(xù)業(yè)務(wù)調(diào)用數(shù)據(jù)的分析。
這是我們的效果圖。
我們可以做到根據(jù)這個(gè)請(qǐng)求的參數(shù)，比如說(shuō)前端有一筆訂單的請(qǐng)求，可以根據(jù)訂單的參數(shù)以及用戶ID等等做一些調(diào)用的檢索，特別是排查問(wèn)題的時(shí)候，出現(xiàn)異常或者說(shuō)服務(wù)的請(qǐng)求耗時(shí)特別長(zhǎng)的時(shí)候，可以很快的從后臺(tái)檢索到有問(wèn)題的一些調(diào)用鏈，進(jìn)而做出一些優(yōu)化。
調(diào)用跟蹤系統(tǒng)，大致講一下相關(guān)的技術(shù)點(diǎn)。首先就是整個(gè)調(diào)用鏈我們要從前端站點(diǎn)到服務(wù)層、數(shù)據(jù)層，整個(gè)調(diào)用關(guān)系或者調(diào)用鏈給串起來(lái)，主要依賴于兩個(gè)元素：一個(gè)是有一個(gè)全局的調(diào)用的工作ID，把我們所有的調(diào)用請(qǐng)求通過(guò)這個(gè)ID給串起來(lái)，這樣在定位問(wèn)題的時(shí)候，可以排查到每個(gè)調(diào)用環(huán)節(jié)。另外還有一個(gè)調(diào)用的層級(jí)關(guān)系，比如說(shuō)一個(gè)站點(diǎn)里面調(diào)了好幾個(gè)服務(wù)，設(shè)計(jì)了評(píng)級(jí)調(diào)用關(guān)系。另外這個(gè)服務(wù)本身內(nèi)部調(diào)了下游其他服務(wù)，也可以很方便的通過(guò)后臺(tái)系統(tǒng)看得見(jiàn)。
由于是分布式的系統(tǒng)，整個(gè)調(diào)用鏈不是在某一臺(tái)服務(wù)器上面可以全部搜集的到，往往是跨服務(wù)器，對(duì)于不同服務(wù)器之間調(diào)用鏈的數(shù)據(jù)怎么樣透?jìng)?如果同一臺(tái)服務(wù)器，同一個(gè)虛擬機(jī)里面的服務(wù)解決調(diào)用，我們是通過(guò)線上變量去做的這件事情。通過(guò)協(xié)議層面特別是跨服務(wù)器調(diào)用的時(shí)候，把這些數(shù)據(jù)放在協(xié)議里面，傳輸?shù)搅硗庖欢恕?/p>
另外調(diào)用鏈在推廣的過(guò)程中發(fā)現(xiàn)了一個(gè)問(wèn)題，當(dāng)我們?nèi)客普{(diào)用鏈的時(shí)候數(shù)據(jù)量特別大。所以我們做了全量的調(diào)用鏈相關(guān)的數(shù)據(jù)采集和采樣的方式，對(duì)于核心服務(wù)我們會(huì)有全量。采樣也可以解決出了問(wèn)題的時(shí)候可以比較快速的定位，一般情況下出問(wèn)題的時(shí)候，會(huì)有一定的延續(xù)性，調(diào)用也是相對(duì)比較隨機(jī)的，所以采樣是可以采到有問(wèn)題的數(shù)據(jù)。這是調(diào)用跟蹤系統(tǒng)一些相關(guān)的實(shí)踐工作。
調(diào)用跟蹤系統(tǒng)可以發(fā)現(xiàn)每一次調(diào)用可能存在的問(wèn)題，也可以以圖形的方式很快的看到我們想要知道的一些數(shù)據(jù)，這是針對(duì)每一次調(diào)用。另外針對(duì)調(diào)用鏈，每天會(huì)做一個(gè)數(shù)據(jù)全量的分析，主要的目的就是說(shuō)我們想知道整個(gè)或者說(shuō)以集群為單位，這個(gè)集群下面依賴于哪些下游，然后我們給哪些上游提供相應(yīng)的服務(wù)，這樣可以反向的來(lái)推動(dòng)服務(wù)架構(gòu)的優(yōu)化，因?yàn)橛锌赡軙?huì)出現(xiàn)像循環(huán)依賴或者說(shuō)調(diào)用鏈特別長(zhǎng)。而調(diào)用鏈特別長(zhǎng)的原因，本身可能是業(yè)務(wù)的不合理，或者說(shuō)本身設(shè)計(jì)的時(shí)候有一些拆分做得不是特別好，通過(guò)服務(wù)依賴以及調(diào)用鏈上報(bào)的數(shù)據(jù)，我們可以發(fā)現(xiàn)架構(gòu)層面的問(wèn)題，進(jìn)而反推架構(gòu)的優(yōu)化。
最后是一個(gè)小結(jié)，今天主講的內(nèi)容主要是為什么我們要做服務(wù)治理以及58到家是怎樣做的。服務(wù)治理一般是會(huì)伴隨服務(wù)化去做一些服務(wù)的拆分，目的就是為了更好的解耦，為了更好的做服務(wù)擴(kuò)容等等。
服務(wù)發(fā)布主要解決的是服務(wù)地址的透明化，以及基于注冊(cè)中心的集中管理。
路由和容錯(cuò)主要是解決可用性以及服務(wù)負(fù)載的問(wèn)題。
流控和告警主要是為了做過(guò)載保護(hù)。
數(shù)據(jù)庫(kù)的鏈接數(shù)，線程數(shù)、資源數(shù)的控制，也是對(duì)服務(wù)做更好的保護(hù)以及可以怎樣讓我們的服務(wù)更好的響應(yīng)客戶端的請(qǐng)求，怎樣提高閉環(huán)量。
最后一點(diǎn)是調(diào)用跟蹤系統(tǒng)，面臨著很多拆分出來(lái)的微服務(wù)，它們之間的調(diào)用關(guān)系特別復(fù)雜，為了更快速的定位線上問(wèn)題所以我們有了調(diào)用跟蹤系統(tǒng)，基于調(diào)用跟蹤系統(tǒng)，可以根據(jù)調(diào)用關(guān)系去反推架構(gòu)的優(yōu)化。
關(guān)于APMCon：
2016中國(guó)應(yīng)用性能管理大會(huì)(簡(jiǎn)稱APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召開(kāi)。APMCon由聽(tīng)云、極客邦和InfoQ聯(lián)合主辦的作為國(guó)內(nèi)APM領(lǐng)域影響力的技術(shù)大會(huì)，舉辦的APMCon以“驅(qū)動(dòng)應(yīng)用架構(gòu)優(yōu)化與創(chuàng)新”為主題，聚焦當(dāng)前最為熱門(mén)的移動(dòng)端、Web端和Server端的性能監(jiān)控和管理技術(shù)，整個(gè)會(huì)議設(shè)置包含了：性能可視化、服務(wù)端監(jiān)控實(shí)踐、運(yùn)維自動(dòng)化、數(shù)據(jù)庫(kù)性能優(yōu)化、APM云服務(wù)架構(gòu)和HTML5調(diào)優(yōu)實(shí)踐等話題，致力于推動(dòng)APM在國(guó)內(nèi)的成長(zhǎng)與發(fā)展。