AWSomeDay 中體會的微服務治理

  1. 服務治理這塊,根據經驗,有三個需要注意的。一是接口的統一性,當公司發展到幾百人的時候,如果沒有接口規範,那效率馬上就會下降。之前可以像遊 擊隊一樣打,但人多了之後,還是像正規軍一樣戰鬥力會比較強。二是容錯一定要做好,這塊可以參考Netflix開源的幾個組件。容錯如果沒有做好,在服務 化這樣的系統裏,很可能會造成雪崩效應。容錯的方案也有很多,比如限流、回退、隔離、熔斷。三是監控,在微服務出錯之後,團隊需要快速定位出錯的位置和原 因。

  2. 服務治理這塊,阿里巴巴有個不錯的框架Dubbo, 已經開源。拋開服務治理不說,我來舉個服務化的反例,Facebook內部是反服務化的。Facebook所有的代碼只有兩個庫,並且所有的發佈都是同時 進行的,每個機器都一模一樣。所以Facebook可以做到零運維,並且服務根本沒有版本的概念。阿里巴巴現在的服務也準備往回收,在沒有服務和過多的服 務之間找到一個平衡點。

  3. 服務方需要知道服務會被多少人調用,被哪些業務調用,每個時間點上的狀態是怎麼樣的。一個經驗是爲每個服務都起一個名字,當出現問題時,可以快速定位到。另外,阿里的eagleye和點評的CAT監控系統,支持對服務調用鏈和依賴關係進行可視化監控,可以參考學習。

  4. 微服務中,服務的測試是一個非常大的挑戰。服務和服務之間會存在依賴,所以環境的搭建可能就會涉及到多個團隊,這個時候就需要能快速部署環境,當然現在比較推薦的方案是容器。

  5. 微服務,其實對應的應該是微業務,是爲了適應業務的多變/面向最終用戶的個性化需求。而微服務的力度,很大程度上是取決於完成一項業務所要設計的 數據存儲所在的區域。微服務的監控,和原來的服務監控力度應該是類似的,包括業務、應用、系統多個層次,日誌、Metrics、調用鏈、告警等多個維度。

  6. 提到監控,大家一般都是從系統、應用等層面去考慮。我這裏拋一個思路給大家:輿情監控。很多時候,當系統出問題的時候,我們並不是在監控那裏得到 消息,而是從微博、微信等渠道中收到用戶反饋(XX系統真垃圾,又掛了之類…..)。我們努力了幾年了,就是想讓我們的監控系統能在輿論之前監測到系統的 異常狀態,但很難,所以現在我們也在重點考慮輿情監控。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章