談談服務治理(2017)

語言: CN / TW / HK

本文首發於2017年,這次只是留存到公眾號上,讓自己記住當初那個沒把告警治理當成自己的事情來做的我。

本期我們組的技術分享,打算跟大家講講服務治理。我在上篇文章中介紹了我們美團.點評北京總部用的OCTO框架,其實在上海點評部門用的是另一套Pigeon。這兩套框架都很重。這是和我們的業務有關的,其實服務治理這個東西從創業公司到成熟的大公司都在用,只是做到的程度不同。

先說說服務治理的邊界。本質上任何能提升服務可用性,效能,讓服務更穩定等等,只要是能讓服務執行的更好,都屬於服務治理的範疇。服務治理比較常見的話題:服務發現,服務變更管理,服務監控,服務擴容縮容,服務自我保護,服務降級,服務授權防攻擊,服務上線驗證和灰度釋出,服務問題定位和跟蹤,服務負載,服務例項的排程等等。

說服務治理就要先聊聊服務。從業務角度而言,服務是一個可重複的任務。我是個做業務的,業務可以被粗粒度的劃分為一系列粗粒度的服務和流程。這本質上符合SOA架構的風格,而現在比較流行的微服務出現實際上應當歸功於SOA原則的成功。而微服務將服務劃分的更細,更多,會導致出問題的概率變大。這時候,服務治理的手段沒有進步的話,實際上服務的壓力是變大了。所以大家在選擇架構的時候,需要按照自己的業務發展現狀和趨勢合理的辯證的做決斷。就好像我在上篇文章裡舉的例子:如果要建一間房子,可能隨便建個土房子或者茅草房子就能用幾十年,但是隨著規模的擴大,建成四合院就要講究格局,建成一個小區,建成一座城市,就需要運用各種工程學的知識更加統籌的規劃。這就是為什麼我要來美團。我在樂視其實過得很舒服,很自由。因為我家微微一笑很傾城的男神老大不僅英俊帥氣,智商情商雙高,而且管理風格open,很合適我這種有自己想法的下屬。但是樂視各個部門更像是一個村落,大家都在各自建各自的房子,好處是有才能的人可以比較自由的發揮,缺點是格局不夠統一,各個部門做了很多重複的工作。所以樂視出來的人有水平非常高的,也有水平非常一般的。我個人覺得如果你個人能力非常好,可以去樂視試一試,說不定可以發揮自己的潛能。但是對於我而言,我發現了自己格局的問題,如果我堅持還是要去阿里的話,到那邊也是個擰螺絲的,平臺很好,但是能不能發揮是個問題。而來美團,我至少能夠得到的保證是:完成一個從對工作負責到對結果負責的轉變。什麼意思呢?我來這邊,我們架構師說我來之前,他需要找各個開發去告訴他們我們的工作,每個開發都聽明白了,然後回到工位完成了自己的那份工作。結果中間銜接的部分職責模糊的部分就很可能被漏掉了。我來了,我的工作是對結果負責,那麼涉及到內部職責的劃分,上下游的對接和業務瞭解。任何能讓結果變得更好的事情都屬於我的職責範圍。這和服務治理的理念不謀而合,這就是為什麼我要來研究服務治理。

我也自己創過業,做的最小的專案本質上也用到了服務治理相關的東西,就是nginx。nginx本身不處理業務邏輯。它做了什麼事情呢?服務發現,負載均衡。我自己覺得與其將其歸類為一個具體的服務元件,劃分為服務治理元件更為合適。nginx的服務發現大家都知道是在upstream裡配置的,可以做DNS動態解析。服務更變修改配置檔案後用nginx -s reload讓nginx發現最新的配置,可以說是一個輕巧簡單的服務發現機制。nginx的負載均衡大家說的比較多了,我就不詳述了。但是它做負載均衡的前提是它還實現了服務的分離。它可以將前端靜態請求轉發到靜態服務上,動態api轉發到api服務上,rpc呼叫轉發到rpc服務上。nginx的服務治理能力還體現在所有這些分離的服務,請求的log都是走nginx服務,我們可以更方便的觀察監控請求,所以相對於分散的服務有更好的治理能力的。

服務再大一些,就是用到另一個大家熟知的東西,就是zookeeper來做配置變更管理。有一本書叫做《從paxos到zookeeper》講了zookeeper的內部實現,怎樣保證其一致性和分割槽一致性。但是zookeeper的最大問題是網路抖動對其的影響。為了解決這個問題,美團.點評的OCTO服務治理框架採用了本地代理。

服務自動擴容縮容對於美團.點評這樣的,交易時間高峰基本在中午11點到13點。這段時間交易量大,實際上是需要擴容來保證的。交易量低的時段機器閒置造成很大的資源浪費。這種自動擴容縮容需要區分是正常的請求擴容還是異常請求擴容。一個環節擴容會不會給其他環節造成更大的壓力,反而壓垮整個鏈路。如果是異常請求,這個時候應該採用的是拒絕請求。比如有資料庫慢查詢,顯示呼叫結果是執行緒池滿了,要排隊。如果這時候採取了擴容,反而壓垮資料庫。這時候應該是報警而不是擴容。

在樂視的時候,阿里的陽哥自己開發了一個基於redis的異常日誌收集器。這個其實也屬於服務治理的範疇,這是一個統一的服務監控報警機制。報警是觸發門檻很低的異常處理機制。所以我在樂視的時候郵件,手機簡訊報警太多了,我就想換了工作再也不用收這些報警了。結果,好吧,換工作後多了N倍。異常再達到一定量級,可能會觸發過載保護。過載保護再不解決問題就要降級了。我之前部落格裡也提到的樂視用guava的RateLimiter做了限流,這就是過載保護的一種方式。