前言

58作為一個分類資訊網站，作為資訊服務的提供平臺，我們的客戶在我們的平臺的交易鏈路，抽象后可以描述為：商戶購買服務->將購買后的資源托管到資源中心->商家消耗相關資源->收入的核算，

具體業務流程如下圖：

圖0-1 資源中心業務流程圖

資源中心就是我們交易鏈路中客戶購買相關服務后將相關服務資源托管的管理中心，是我們進行資源管理及后續收入核算的核心服務，

其在整個交易鏈路所處的位置為：

1、購買鏈路：房產、招聘等各大業購買平臺->支付->資源中心，

2、消耗鏈路：房產、招聘等各大業使用平臺->資源中心->攤銷算收入->業績、經分進行相關資料處理，

可見其在58的整體交易鏈上的重要性，無論是在商戶購買58相關服務還是商戶在實際使用58付費服務的程序中，都需要和資源中心進行互動，那么，如何治理好這個服務就是一個非常重要的課題，本文我們將從高可用性、性能優化兩個方面介紹服務治理在資源中心的具體實踐，

一、高可用應用架構演進

系統的建設并非一蹴而就的，資源中心的高可用，也是經過2年的不斷建設演進，達到目前的4個9的可用級別的，我們的技術演進，既有我們通過技術的實踐，主動優化的，也有在使用場景中遇到的問題，血淚教訓后的填坑補丁，

1、高可用的理論框架

圖1-1 高可用理論架構

如上圖，從通用的高可用架構理論上，一個高可用架構通常包含高可用的硬體架構、高可用的應用、高可用的服務、高可用的資料、高可用的軟體質量保證及最后的相關監控，對于硬體、網路、Nginx、DB、MB等相關基礎設施，通過58私有云作為IAAS/PAAS直接提供給我們服務，對軟體的質量保障和后續的相關監控，也有相關部門提供了完整的支持，也不是我們核心要點，這里核心介紹高可用服務的建設，

2、我們的具體實踐

高可用服務的建設可以分為分級管理、超時設定、異步呼叫、服務降級、冪等設計這幾個方面，

2.1分級管理

分級管理在實踐中的難點是統一跨部門之間對重要性的認知，我們通過跨部門協作，制定共同的服務可用性OKR，完成服務重要性的協同認知，

在認知一致的基礎上，基礎運維部將我們的服務作為最高級來進行，首先是我們在私有云的容器，1是通過跨機柜，跨機房等方式，盡量避免硬體層面問題帶來的風險；2是獨立部署，避免混合部署，其他服務帶來的潛在風險，其次在資料庫層面上，采用最新的硬體進行獨立部署，同時進行任務的集群隔離，讓DBA單獨拿出一個從節點專門用來進行DB相關任務處理，與處理線線上請求的機器進行隔離保障性能，最后是溝通機制上，針對我們的服務，單獨安排獨立介面人，負責相關問題的處理，保障相關問題發生后，能夠第一時間進行處理，

同時，針對不同的請求方，我們設定了不同的容器分組，做到不同業務間的分級管理，保障不同業務組之間不會因為流量的暴漲影響彼此，

2.2超時設定

為什么要進行超時設定呢？

由于下游服務回應過慢、執行緒死鎖、線上BUG等一系列原因導致我們作為呼叫方呼叫之后一直沒有回應，從而最終導致用戶請求長時間得不到回應，同時在長時間占有執行緒資源甚至會拖垮整個服務影響其他正常請求，所以我們應該進行超時設定，這是微服務中快速失敗的一個基本手段，

第二個問題，我們該如何設定呢？

通常有兩個層面的超時：服務級超時、介面級別的超時，服務級別的超時時間一般以最慢介面的耗時時間為基準，而且大部分框架都只會有服務級的超時設定，很少有介面級的超時設定，介面級的超時設定，沒有必要所有介面都設定，僅針對流量極大、性能要求較高的介面進行單獨設定就行，這里教大家一個小Tips：可以使用位于JUC包中的Future進行介面級的超時設定，簡單有效，

第三個問題，服務超時時我們該如何處理呢？

基于這個這個問題，我們需要從上下游、流量、業務場景這三個維度進行考量，

超時的處理手段一般有兩種：重試、例外快速回傳，重要的寫事務場景需要重試，我們要盡最大努力保證事務成功，流量較大的介面一般不適合重試，直接回傳例外就好，最極端的場景下容易導致流量翻n倍，導致后面的鏈路奔潰，

2.3異步呼叫

異步呼叫可以分為同行程下的執行緒異步和行程間的異步呼叫，在最初的架構設計中，我們針對非核心流程但是相對關系較為緊密的內容做了單行程下的異步，使用的Disruptor佇列異步寫日志，用Event Bus異步化非核心流程，系統平穩運行了多年，以至于我們極少關注我們的非核心異步相關的服務，但是，一次線上事故還是給了我們深刻的教訓，

2020年8月，突然有人反饋服務大量超時，我們通過我們的監控發現我們的請求大量積壓，有一組服務處于無法提供服務的狀態，經過比較發現，這組服務依賴的日志寫入資料庫出現超時，導致異步寫日志的執行緒池創建了大量等待執行緒，進而導致正常處理請求的執行緒所能占用的CPU時間大大降低，最終大致正常請求超時并出現雪崩現象，這里有我們執行緒池引數設定不合理的原因，同時，也提醒我們，在同行程下異步，在出現小概率事件之后，依然可能影響到我們的服務可用性，針對這種情況，我們整體梳理了我們的核心流程和非核心流程，將非核心流程采用訊息的方式，進行行程間隔離，進行服務治理完成之后我們大概的服務拓撲圖如下圖：

圖1-2 資源中心服務拓撲圖

2.4服務降級

圖1-3 資源中心依賴方串列

如上圖我們的服務拆分了非核心依賴之后還有十幾個核心依賴，假設每個服務都是4個9高可用的服務，99.99^10≈99.9%我們的服務可靠性立馬下降了一個資料量級，極大的影響了服務的穩定性，

2020年10月28日上午由于下游的某一個服務出現問題，導致30%的流量持續將近3分鐘不可用，如下圖：

圖1-4 資源中心流量監控

30%是個什么概念呢？資源中心的核心服務日訪問量4.5億+，峰值近百萬QPM，30%持續3分鐘大概100萬的請求不可用，所以降級對我們來時勢在必行，

首先我們團隊僅僅4個人，還得花90%的時間處理業務需求，所以自己造輪子是不可取的，就成本來說開源框架也是極好的選擇，業內知名的幾款降級框架對比如下圖：

表1-1 降級開源框架比較

最終降級組件我們選的是Sentinel，首先先不考量Resilience4J因為其缺少生產級別的配套設施，相關監控系統以及控制臺，我們無法感知到內部運行情況以及出現問題時無法從外部人工接入，再說Sentinel與Hystrix相比我們看中其原始碼簡單、例外處理靈活兩大特點，我們大部分介面平均耗時在2ms以后，所以我們果斷采取信號量隔離機制，此時Hystrix另外一個優點執行緒池個隔離對我們來說意義也不大，所以選擇了Sentinel，

為什么我們會將例外處理作為選擇Sentinel的一個點呢？Hystrix在進行降級閥值計算時，所有的例外都會被統計，其實正常的業務例外是不需要被統計的，例如有的服務介面引數校驗不通過時會拋例外，這時因為引數不合法而觸發降級是不合理的，所以我們只針對超時、服務掛了等幾個特殊例外才會進行降級處理，

組件選擇好之后該怎么實作呢？

我們本著：關注點聚焦業務、將降級工具化的思想，利用自動掃包工具+RPC框架過濾器機制設計我們的組件，實作機制如下圖：

圖1-5 資源中心降級方案

我們的組件在使用降級的時候只需要兩步就可以：1、實作要降級的介面，定義Fall Back類；2、要Fall Back方法上以注解的形式配置降級引數，

引數如何降級引數如何設定呢？

我們進行引數設計是需要遵循兩個原則：普通網路抖動不觸發降級，盡可能快的發現發現服務例外進入降級狀態，

我們的做法是：

1、統計過往服務正常狀態下由于網路抖動觸發的超時量；

2、以這個量基準與當時的請求量相比較得到降級觸發的閥值；

3、 開放在線手動微調介面，對其引數進行微調，以保證設定的引數達到最優效果，

2.5冪等防重設計

我們采用兩層防護措施進行防重設計，第一層DB層，冪等的key用唯一索引，保證DB底層只有一條資料入庫，第二層應用層，我們采用基于Redis的冪登鎖來保證資料的唯一性，引入第二層的原因是減少DB的壓力，第一層是兜底層，防止Redis掛了無法進行防重，

3、目前我們的架構

經過我們的實踐和建設，形成了我們目前的整體架構：

圖1-6 資源中心系統架構

二、性能優化之路

在保障高可用的前提下，作為支持商家使用的基礎服務，從性能上能夠快速回應，也是我們的重中之重，在性能優化的道路上，我們也介紹一下我們的一些實踐經驗，

1、服務外部優化

我們基于Mongo提供日志流水的查詢，經過我們進行索引優化后，還存在稍微量大一點的資料就會超時，就我們查詢的資料量來看在MySQL下一點問題也沒有，經過我們與DBA的長期觀察與解決，由于投入的人力、時間成本有限以及社區沒有相關的問題的解決方案，最終沒有找到問題的根本原因從而解決問題，

不能再一顆樹上吊死，我們換了另外一種思路，換個存盤介質是否可以？

1、 Mongo存的是操作日志，不存在更新的為，資料比較好遷移

2、 Mongo運維人員較少而且大資料平臺拉取資料支持的不友好

經過分析確實可行，我們最終選擇了TiDB，三方面原因：

1、不需要我們應用層進行分庫分表，性能也能滿足我們的需求；

2、運維以及公司的基礎環境相對比較完善投入的人力成本以及硬成本比較好；

3、社區比較活躍遇到棘手問題容易解決，

最終我們經過大概10個人天的時間從遷移資料到下掉雙寫代碼，而且效果非常好，原來200左右的超時量，下降到50以內，

2、服務內部優化

2.1、JVM調優

每次服務啟動或者重啟時都會有一段時間的超時，我們通過JSTAT命令監控服務，我們發現服務在每次啟動的時候都會有4次FGC，接下來我們觀察GC日志發現4次FGC的原因是因為元空間不夠了，最終4次GC后元空間的大小為100多M，最終我們將JVM的引數調整為：MateSpace=256m，為什么不是128呢？給未來預留余地，防止未來隨著專案的元資料增多再次發生同樣的問題，

啟動時FGC是沒有了，但是我們發現我們的服務由物理機遷移到docker云平臺后，YGC的時間大大的增加了，幾乎每次YGC時都會有服務超時，當時我們的新生代配置是10G空間，按照默認Eden和兩個Survivor的比例是8：1：1新生代的空間是老年代的8倍，我們的物理機的配置是32核128G而我們的云機器是8核16G，CPU核數少了四倍，記憶體少了8倍，總所周知JVM在進行GC處理的時候主要是利用CPU進行記憶體整理，算是一個CPU密集型操作，現在CPU計算能力減少了4倍GC的耗時理所當然的就要增加了，

這時我們并沒有貿然的增加云機器的配置，因為我們日常8核16G其實基本上夠用了，沒有必要為了YGC的問題額外的浪費成本，我們也沒有貿然的將現有的新生代減少4倍，這樣新生代空間驟然減少這么多倍，可能會帶來更加頻繁YGC的風險，導致服務整體耗時會更慢，甚至會出現線上事故，我們采取較為緩和的手段，一點一點減少新生代大小以及減少Eden以及Survivor的比例，最終，經過我們反復嘗試將JVM引數調至：-Xmn:8g -XX:SurvivorRatio=4，