本期我們組的技術分享，打算跟大家講講服務治理。我在上篇文章中介紹了我們美團.點評北京總部用的OCTO框架，其實在上海點評部門用的是另一套Pigeon。這兩套框架都很重。這是和我們的業務有關的，其實服務治理這個東西都創業公司到成熟的大公司都在用，只是做到的程度不同。 先說說服務治理的邊界。本質上任何能 ...
本期我們組的技術分享，打算跟大家講講服務治理。我在上篇文章中介紹了我們美團.點評北京總部用的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做了限流，這就是過載保護的一種方式。
