淺談服務治理、微服務與Service Mesh

Spring Cloud 之“出身名門望族”

作為當下最火熱的微服務框架，Spring Cloud的名字可以說是無人不知、無人不曉，憑藉之前Spring Framework的良好群眾基礎和Cloud這個具有時代感的名字，Spring Cloud一出現便被大家認知。

提到Spring Cloud，便會讓人想起剛剛釋出了2.0版本的Spring Boot。Spring Boot和Spring Cloud都是出自Pivotal公司，Spring Boot和Spring Cloud雖然火熱，但是瞭解Pivotal公司的人在國內卻是不多。實際上Pivotal公司在雲端計算、大資料、虛擬化等領域都有所建樹，這裡先給大家簡單八卦下Pivotal的情況。

Pivotal公司是由EMC和VMware聯合成立的一家公司，GE（通用電氣）也對Pivotal進行了股權收購，同時GE也是Pivotal的一個重要大客戶。除了Spring Framework、Spring Boot和Spring Cloud之外，我們日常開發中經常使用的Reids、RabbitMQ、Greenplum、Gemfire、Cloud Foundry等，目前都是歸屬於Pivotal公司的產品。其中Gemfire也是被中國鐵路總公司12306使用的分散式記憶體資料庫，也就是說你過年回家買不到火車票，這個鍋Pivotal的Gemfire也會跟著一起背（開個小玩笑，哈哈）。

Spring Cloud 之“入門”

Spring Cloud作為一個微服務的開發框架，其包括了很多的元件，包括：Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius）、Spring Cloud Config、Spring Cloud Bus、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Task、Spring Cloud ZooKeeper、Spring Cloud Connectors、Spring Cloud
Starters、Spring Cloud CLI等。

在上述元件中，Spring Cloud Netflix是一套微服務的核心框架，由網際網路流媒體播放商Netflix開源後併入Spring Cloud大家庭，它提供了的微服務最基礎的功能：服務發現（Service Discovery）、動態路由（Dynamic Routing）、負載均衡（Load Balancing）和邊緣伺服器（Edge Server）等。

Spring Boot是Spring的一套快速配置腳手架，可以基於Spring Boot快速開發單個微服務。Spring Boot簡化了基於Spring的應用開發，通過少量的程式碼就能建立一個獨立的、生產級別的Spring應用。由於Spring Cloud是基於Spring Boot進行的開發，因此使用Spring Cloud就必須使用到Spring Boot。

下圖是一個常見的關於Spring Cloud的架構圖。下面此圖為例，對Spring Cloud最常用的幾個元件做一個簡單的介紹：

• Eureka：服務註冊中心，一個基於REST的服務，用於定位服務，以實現微服務架構中服務發現和故障轉移。
• Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。
• Turbine：Turbine是聚合伺服器傳送事件流資料的一個工具，用來監控叢集下Hystrix的Metrics情況。
• Zuul：API閘道器，Zuul是在微服務中提供動態路由、監控、彈性、安全等邊緣服務的框架。
• Ribbon：提供微服務中的負載均衡功能，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。
• Feign：Feign是一種宣告式、模板化的HTTP客戶端。
• Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠端伺服器，集中化管理叢集配置，目前支援本地儲存、Git以及Subversion。
• Spring Cloud Security：基於Spring Security的安全工具包，為微服務的應用程式新增安全控制。
• Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為SpringCloud應用實現了一種分散式追蹤解決方案。

除了上面介紹的基礎元件外，常見的Spring Cloud元件還有非常多種，涉及到了微服務以及應用開發的方方面面：

• Spring Cloud Starters：Spring Boot式的啟動專案，為Spring Cloud提供開箱即用的依賴管理。
• Archaius：配置管理API，包含一系列配置管理API，提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回撥機制等功能。
• Consul：封裝了Consul操作，Consul是一個服務發現與配置工具，與Docker容器可以無縫整合。
• Spring Cloud Stream：資料流操作開發包，封裝了與Redis,Rabbit、Kafka等傳送接收訊息。
• Spring Cloud CLI：基於 Spring Boot CLI，可以讓你以命令列方式快速建立雲元件。
• Spring Cloud Task：提供雲端計劃任務管理、任務排程。
• Spring Cloud Bus：事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
• Spring Cloud Data Flow：大資料操作工具，作為Spring XD的替代產品，它是一個混合計算模型，結合了流資料與批量資料的處理方式。
• Spring Cloud ZooKeeper：操作ZooKeeper的工具包，用於使用ZooKeeper方式的服務發現和配置管理。
• Spring Cloud Connectors：便於雲端應用程式在各種PaaS平臺連線到後端，如：資料庫和訊息代理服務。

Spring Cloud之“精通”

Spring Cloud雖然集成了眾多元件，可以構建一個完整的微服務應用，但是其中的各個元件卻並非完美無缺，很多元件在實際應用中都存在諸多不足和缺陷。因此，需要我們對其中的一些元件進行替換和修改，方能構建一個強大、靈活、健壯的微服務架構應用。

配置中心

Spring Cloud Config可以說是Spring Cloud家族中實現最Low的一個元件，直接採用了本地儲存/SVN/Git的方式進行儲存。同時，Spring Cloud Config也缺乏一個完整的視覺化管理查詢後臺，當存在比較複雜的許可權管理和版本管理需求時，Spring Cloud Config會顯得非常力不從心。如果需要在配置修改後，能自動進行配置資訊推送的話，使用Spring Cloud Config也無法滿足要求，需要自行編寫程式碼進行實現。

目前開源社群中，已經有了很多的開源配置中心實現方案，同時很多公司也自研了自己的配置中心方案。包括淘寶的統一配置中心Diamond（已經多年未更新）、百度的分散式配置管理平臺Disconf、攜程的開源分散式配置中心Apollo、360的分散式配置管理工具QConf等等。目前，筆者公司採用的是自己公司自研的配置中心，沒有采用開源實現的主要原因是因為需要同時適配Spring Cloud和Dubbo等多種場景的應用。

註冊中心

作為Spring Cloud的服務註冊中心，從分散式CAP理論來看，Eureka採用是AP型設計，強調的是註冊中心的高可用性。和Dubbo常用的服務註冊中心ZooKeeper相比，ZooKeeper則是採用的CP型設計，強調的是註冊中心資料的一致性。

Eureka的設計確實簡單易用，但是預設沒有實現對註冊中心資料的持久化。同時，在極端場景下，也會出現多個Eureka註冊中心節點資料不一致，甚至服務註冊資料丟失的情況。當然，從分散式CAP理論來看，理論上是沒辦法做到同時兼顧CAP三點的。目前也有一些網際網路公司對Eureka進行了改造，支援了資料的持久化，但是尚不能完整的支援CAP的全部要求。

API閘道器

API閘道器可以說是微服務需求最多，也是最有難點的一個元件。Spring Cloud中整合的Zuul應該說更多的是實現了服務的路由功能，對於負載均衡等其他功能，需要結合Ribbon等元件來實現。對於很多個性化的需求，需要開發者自己來進行編碼實現。

和大部分基於Java的Web應用類似，Zuul也採用了Servlet架構，因此Zuul處理每個請求的方式是針對每個請求是用一個執行緒來處理。同時，由於Zuul是基於JVM的實現，因此效能也會在高併發訪問場景下成為瓶頸。雖然網上一些文章評測Zuul和Nginx效能接近，但是在效能要求較高的場景下，JVM的記憶體管理和垃圾回收問題，仍然是一個很大的問題。所以在實際的應用場景中，通常會採用在多個Zuul幾點前面再新增一層Nginx或者OpenResty來進行代理。

為了解決Zuul的效能問題，Netflix將自己的閘道器服務Zuul進行了升級，新的Zuul2將HTTP請求的處理方式從同步變成了非同步，並且新增諸如HTTP/2、websocket等功能。但是遺憾的是，開源版本的Zuul 2一直處於難產狀態中，始終沒有和大家正式見面。

熔斷器

微服務中對於服務的限流、降級、熔斷的需求是多種多樣的，需要在API閘道器和各個具體服務介面中分別進行控制，才能滿足複雜場景下微服務架構的應用需求。

單獨使用Spring Cloud中的Hystrix無法完整的滿足上述的複雜需求，需要結合API閘道器，並通過Kubernetes對資源、程序和名稱空間來提供隔離，並通過部分自定義編碼方能實現對全部服務的限流、降級、熔斷等需求。

監控系統

無論是Spring Cloud中整合的Spring Cloud Sleuth，還是整合經典的ELK，都只是對日誌級別的追蹤和監控。在大中型微服務應用架構中，尤其是基於JVM的專案，還需要新增APM的監控機制，才能保證及時發現各種潛在的效能問題。

APM整體上主要完成3點功能：1.日誌追蹤、2.監控報警、3.效能統計。目前，國內外商業版本的APM方案已經有很多，開源版本的APM方案也開始豐富起來。國內開源的APM方案主要有：大眾點評的CAT和Apache孵化中的SkyWalking。這裡給大家重點推薦下SkyWalking，SkyWalking是針對分散式系統的應用效能監控系統，特別針對微服務、Cloud Native和容器化（Docker、Kubernetes、Mesos）架構，專案的關注度和發展速度都很快，中文文件資料也比較齊全。

Spring Cloud之“放棄”

Spring Cloud可以說是一個完美的微服務入門框架，如果你是在一箇中小型專案中應用Spring Cloud，那麼你不需要太多的改造和適配，就可以實現微服務的基本功能。但是如果是在大型專案中實踐微服務，可能會發現需要處理的問題還是比較多，尤其是專案中老程式碼比較多，沒辦法全部直接升級到Spring Boot框架下開發的話，你會非常希望能有一個侵入性更低的方案來實施微服務架構。在這種場景下，Service
Mesh將會成為你的最佳選擇，經過一段時間的發展，目前Service Mesh這個概念已經開始逐步被大家瞭解和認知。同時，一些Service Mesh的實現方案也逐步成熟和落地，例如Istio、Linkerd、Envoy等。在本系列文章的下一篇中，將為大家對Service Mesh概念做一個系統的介紹。但是在瞭解Service Mesh概念之前，還是建議大家先對微服務和Spring Cloud這些概念和框架有一個深入的瞭解，這樣才能體會到應用Service Mesh的價值和意義。

Spring Cloud與Dubbo

網上關於Spring Cloud和Dubbo對比的文章很多，大多數對比結果都是Spring Cloud壓倒性優勢戰勝Dubbo，下表是對Dubbo和Spring Cloud做的一個基礎功能的對比：

實際上，Dubbo的關注點在於服務治理，並不能算是一個真正的微服務框架。包括目前在開發中的Dubbo 3.0，也不能完整覆蓋微服務的各項功能需求。而Spring Cloud一方面是針對微服務而設計，另外一方面Spring Cloud是通過整合各種元件的方式來實現微服務，因此理論上可以整合目前業內的絕大多數的微服務相關元件，從而實現微服務的全部功能。

而對Dubbo而言，如果一定要應用到微服務的使用場景中的話，上表中欠缺的大多數功能都可以通過整合第三方應用和元件的方式來實現，跟Spring Cloud相比主要的缺陷在於整合過程中的便利性和相容性等問題。

Spring Cloud與Docker

雖然網上也有很多文章寫到如何使用Docker來實現微服務，但是事實上單獨使用Docker是沒辦法完整的實現微服務的所有功能的。在實際上微服務架構中，Spring
Cloud和Docker更多的是一種協作的關係，而不是一種競爭的關係。通過Docker容器化技術，可以更好的解決引入Spring Cloud微服務後帶來的部署和運維的複雜性。

Spring Cloud生態圈中的Pivotal Cloud Foundry（PCF）作為PaaS實現，也提供一些類似於Docker的功能支援，但是無論上功能上還是易用性上和Docker還是存在比較大的差異。Pivotal Cloud Foundry和Docker之間的關係更多的是一種相容關係，而不是競爭關係，Pivotal Cloud Foundry的主要競爭對手是Red Hat的OpenShift。目前，Pivotal Cloud Foundry支援的IaaS包括：AWS、AZURE、GCP、vSphere、OpenStack等。

Spring Cloud與Kubernetes

網上也有一些“Spring Cloud與Kubernetes哪個更好”，“當已經有了Kubernetes之後，還需要使用Spring Cloud麼”之類的文章。首先說筆者並不認為Spring Cloud與Kubernetes是競爭關係，但是也不否認二者確實在諸多功能上存在一些重合。下圖是對Spring Cloud與Kubernetes在微服務架構中的一些基礎功能上的對比：

通過對比可以看出，Spring Cloud和Kubernetes確實存在一些功能上的重合，但是二者的定位其實差別很大。Spring Cloud是一個基於Java語言的微服務開發框架，而Kubernetes是一個針對容器應用的自動化部署、伸縮和管理的開源系統，它相容多種語言且提供了建立、執行、伸縮以及管理分散式系統的原語。Spring Cloud更多的是面向有Spring開發經驗的Java語言開發者，而Kubernetes不是一個針對開發者的平臺，它的目的是供有DevOps思想的IT人員使用。

為了區分SpringCloud和Kubernetes兩個專案的範圍，下面這張圖列出了幾乎是端到端的微服務架構需求，從最底層的硬體，到最上層的DevOps和自服務經驗，並且列出瞭如何關聯到Spring Cloud和Kubernetes平臺。

總結

通過Spring Cloud、Docker和Kubernetes的組合，可以構建更加完整和強大的微服務架構程式。通過三者的整合，使用Spring Boot提供應用的打包，Docker和Kubernetes提供應用的部署和排程。Spring Cloud通過Hystrix執行緒池提供應用內的隔離，而Kubernetes通過資源、程序和名稱空間來提供隔離。Spring Cloud為每個微服務提供健康終端，而Kubernetes執行健康檢查，且把流量導到健康服務。Spring
Cloud外部化配置並更新它們，而Kubernetes分發配置到每個微服務。

對於一名開發人員或者架構師來說，想要精通微服務設計與開發，能夠在大中型專案中應用微服務架構，單純掌握Spring Cloud是遠遠不夠的，Docker和Kubernetes等都是需要學習和掌握的內容。同時，由於採用微服務架構後帶來了分散式的相關問題，對於分散式系統理論也必須有一定的瞭解。當然，最重要的還是對系統業務的深入理解，對整體業務進行合理的規劃和拆分，才能真正行之有效的應用微服務架構，構建高效、健壯、靈活、可擴充套件的微服務應用。

參考連結：