當我們在說微服務治理的時候究竟在說什麼
image
自從微服務架構開始變得火熱以後，越來越多的系統被拆解成了很多個細胞一樣的微服務。設想一下，如果你的系統有100個微服務構成，要對這100個微服務進行管理，這絕對是一個不小的挑戰。所以緊接著又出現了一堆讓人頭暈眼花的概念：服務註冊發現，請求鏈路追蹤，服務熔斷，服務限流，服務管控配置，服務預警。還有就是一抓一大把的開源工具：Eurake，Zuul，Ribbon，hystrix，zipkin，dubbo，Sleuth，Elastic Search，grafna，Promethues。
這樣，當我們在說服務治理時，是不是把這些概念和工具都用上了就能夠很好的治理這100多個微服務了？稍微用Google或者baidu搜尋一下“服務治理”這個關鍵字，就很容易發現其實整個社群對服務治理都沒有形成一個共識，有人理解的服務治理是基於dubbo的服務註冊和服務發現，有人理解的服務治理是一整套從請求閘道器，服務配置中心到日誌中心架構體系。
所以這篇文章我想從現在的現象出發，分析這些概念和這些工具究竟是在解決什麼問題，然後再嘗試做一個簡單的歸納和抽象，看看一個服務治理體系究竟應該解決哪些問題，而為了解決這些問題應該具備哪些能力。
服務治理的那些藥
如果我們把服務治理類比成是在給一個人治病，那麼上面提到的那些概念和工具，很明顯就是治病的藥了。既然有了這麼多藥了，那麼不妨讓我們先從這些藥下手，看看這些流行的藥都能是為了解決什麼問題的，然後再看看這些問題之間存在什麼關聯。
image
讓我們從Netflix全家桶開始，很多微服務架構都是基於這套全家桶的。作為一個視訊流媒體行業的公司，能夠自主開發並向社群貢獻了這麼多工具是我們應該表示感謝和敬意的。由於現在在使用這些工具的時候都是使用Spring Cloud封裝好的模組，所以下面基於Spring cloud 的工具棧來進行介紹：
- Eureka，這是一個用來註冊服務的工具，通過簡單的配置，在服務啟動的時候就會自動註冊到Eureka伺服器上。
- Hystrix，這是一個用來保護服務的熔斷工具，雖然最近宣佈已經停止維護更新了。
- Zuul，這是一個用來對請求進行路由的服務閘道器工具，最近的zuul2採用了Netty實現了非同步非阻塞程式設計模型。
- Ribbon，這是一個用來分配請求的負載均衡工具
- Feign，這是一個用來更方便呼叫其它服務的工具，也能進行負載均衡
- Archaius，這是一個管理配置API的工具
- Spring Cloud Config，用來對配置進行管理，可以把每個服務的配置放在遠端伺服器以方便進行配置修改
- Spring Cloud Sleuth，Tracing採集工具包，對Zipkin，HTrace進行了封裝
- Spring Cloud Consul，封裝了Consul操作，同樣是用來進行服務註冊發現的
- Spring Cloud Zookeeper，封裝了Zookeeper，也是用來進行服務註冊發現的
- Spring Cloud Gateway，給Spring MVC提供API閘道器功能的工具，裡面也包含安全處理等特性
除了Spring Cloud和Netfix提供的這些工具以外，還有下面這些工具也經常在服務監控治理中被使用：
- Dubbo，自稱是一個高效能的Java RPC框架，但是其實廣泛用於服務註冊發現，提供三個核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，服務註冊發現。
- logback，java日誌框架，是log4j的升級版本
- ElasticSearch，雖然是一個搜尋引擎和分析框架，但因為提供很好的儲存和查詢效能，所以經常用於日誌的採集和儲存
- Kibana，Elastic的視覺化外掛，可以配合Elastic使用視覺化查詢日誌
- logstash，Elastic的日誌分析工具
- grafna，時序性分析工具，提供漂亮的圖形化介面
- Promethues，強大系統監控和報警框架，提供多維度資料模型，靈活強大的查詢語句，有多種視覺化圖形介面
- Spring boot admin，用來管理Spring Boot應用的工具，提供視覺化的使用者介面
- Zipkin，分散式追蹤工具，用來採集程式的延時資料
- Htrace，Apache的分散式追蹤工具。
- resilience4j，用來被Hystrix指定作為熔斷的替代工具。
雖然這兩個長長的列表已經羅列了超過20個各種工具了，但是這20多個也僅僅是整個微服務治理生態工具鏈中的一小部分，你肯定還知道一些我沒有列出來的工具。由於這裡我們的目的並不是找出所有的藥，而是想分析一下這些流行的藥都有什麼特點，都是治什麼病的。所以就先基於這些藥，看看他們的共性是什麼。
如果把功能相同的進行一下歸類，會發現有這樣幾個主要功能：
- 服務註冊發現：Eurake，Dobbo，Consul，ZooKeeper
- 服務配置：Spring Cloud Config，Archaius
- 服務熔斷：Hystrix，resilience4j
- 閘道器：Zuul，Spring Cloud Gateway
- 負載均衡：Ribbon，Feign
- 追蹤工具：Sleuth，Zipkin，Htrace
- 日誌採集：logback，ElasticSearch
- 監控平臺：Promethues，Kibana，grafna，Spring boot admin
這樣面對這些紛繁複雜的工具我們有了一個基本的劃分，當然即便是這8個分類還是有點多，而且相互之間的關係也不明確，為什麼會有這8個分類的原因也不清楚。下面就一起深入一下，看看這些工具之間的內在關係究竟是什麼。
服務治理究竟要治的是什麼？
讓我們先放下微服務，像《微服務設計》那本書中說的一樣，把自己想象成一個城市規劃師，我們的目標不是治理微服務，而是要治理一個城市的交通，那麼我們會怎麼思考？
image
在進行城市交通規劃之前首先要做的第一個事情是收集資訊，要能夠知道這個城市發生了什麼，所以在各個路口需要安裝採集探頭，記錄車來車往的資訊。有了資訊以後就需要對資訊進行分析了，那麼就需要視覺化的圖形介面，能夠一眼就看出什麼地方出了問題，通往哪個工廠的路壞了。發現了問題就要解決問題了，限制一下擁堵路段的流量，把去往一個公園的車輛導向到另外一個類似的公園。最後，如果把城市作為一個國家來考慮，那麼每個進入這個城市的車輛都需要進行檢查，看看有沒有攜帶違禁品，最後給這些不熟悉道路的外地車規劃路線。通過上面這個思考的過程，我們發現要對一個城市進行治理的時候，第一要採集資訊，然後要能夠對採集的資訊進行監控和分析，最後根據分析的結果採取對應的治理策略。另外從整體安全的角度考慮還需要一個守門人。
因此我們也用同樣的思路來思考服務治理，閘道器就是整個整體的守門人，日誌採集，追蹤工具，服務註冊發現都是用來採集資訊的，然後需要監控平臺來展現這些採集的資訊，並進行監控和分析。最後根據分析的結果採取治理策略，有的服務快撐不住了要限流，有的服務壞了要熔斷，並且還能夠及時的調整這些服務的配置。
下面的腦圖就從這四個方面構建了一個簡易的服務治理體系：
請求閘道器，資訊採集，資訊分析，治理策略
微服務監控治理
服務治理體系
作為對當前服務治理領域各種紛繁複雜工具的一次簡單梳理，這個體系不一定是完全準確的。但是總不能每次說到服務治理的時候我們都把幾十個工具拿出來看看能用哪個工具吧。我希望達到的目的是，當大家需要對微服務進行治理和監控的時候，能夠用這個簡易的體系做個參考，明確的知道在請求閘道器，資訊採集，資訊分析，治理策略這四個方面還缺少了什麼東西。
當然，如果你發現除了這四個方面以外還缺少了什麼東西，也非常歡迎提出來進行探討，希望能夠通過討論得到一個更好的服務治理體系。