淺談服務治理、微服務與Service Mesh（一二三）
引言
本系列文章將為大家介紹當下最流行的服務治理、微服務等相關內容，從服務治理、SOA、微服務到最新的服務網格（Service Mesh）進行綜合介紹和分析。作為本系列文章的開篇，本文將以Dubbo為例，開始為大家介紹SOA、服務治理等概念，以及Dubbo的基礎知識和最新發展情況。
SOA與服務治理
SOA（面向服務的體系結構）概念由來已久，在10多年前便開始進入到我們廣大軟體開發者的視線中。SOA是一種粗粒度、鬆耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。SOA可以看作是B/S模型、Web Service技術之後的自然延伸。
服務治理，也稱為SOA治理，是指用來管理SOA的採用和實現的過程。以下是在2006年時IBM對於服務治理要點的總結：
l 服務定義（服務的範圍、介面和邊界）
l 服務部署生命週期（各個生命週期階段）
l 服務版本治理（包括相容性）
l 服務遷移（啟用和退役）
l 服務註冊中心（依賴關係）
l 服務訊息模型（規範資料模型）
l 服務監視（進行問題確定）
l 服務所有權（企業組織）
l 服務測試（重複測試）
l 服務安全（包括可接受的保護範圍）
限於當時的技術發展水平，廣大軟體設計與開發人員對於SOA和服務治理的技術認知還主要停留在Web Service和ESB匯流排等技術和規範上，並沒有真正在軟體開發中得以充分落地。
Dubbo開源
直到2011年10月27日，阿里巴巴開源了自己的SOA服務化治理方案的核心框架Dubbo，服務治理和SOA的設計理念開始逐漸在國內軟體行業中落地，並被廣泛應用。
Dubbo作為阿里巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經每天為2000+個服務提供3,000,000,000+次訪問量支援，並被廣泛應用於阿里巴巴集團的各成員站點。Dubbo自2011年開源後，已被許多非阿里系公司使用，其中既有當當網、網易考拉等網際網路公司，也有中國人壽、青島海爾等傳統企業。
Dubbo簡介
Dubbo是一個高效能服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案，使得應用可通過高效能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫整合。
作為一個分散式服務框架，以及SOA治理方案，Dubbo其功能主要包括：高效能NIO通訊及多協議整合，服務動態定址與路由，軟負載均衡與容錯，依賴分析與服務降級等。Dubbo最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地鬆耦合）。從服務模型的角度來看，Dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。
Dubbo包含遠端通訊、叢集容錯和自動發現三個核心部分。提供透明化的遠端方法呼叫，實現像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何API侵入。同時具備軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。可以實現服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者。
下圖來自Dubbo官網，描述了服務註冊中心、服務提供方、服務消費方、服務監控中心之間的呼叫關係，具體如下圖所示：
節點角色說明：
|
節點 |
角色說明 |
|
Provider |
暴露服務的服務提供方。 |
|
Consumer |
呼叫遠端服務的服務消費方。 |
|
Registry |
服務註冊與發現的註冊中心。 |
|
Monitor |
統計服務的呼叫次數和呼叫時間的監控中心。 |
呼叫關係說明：
1. 服務容器負責啟動，載入，執行服務提供者。
2. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
3. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
4. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
6. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo總體架構
Dubbo框架設計共劃分了10層，最上面的Service層是留給實際使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面，位於中軸線上的為雙方都用到的介面。
各層說明：
l Config 配置層：對外配置介面，以 ServiceConfig, ReferenceConfig 為中心，可以直接初始化配置類，也可以通過 spring 解析配置生成配置類。
l Proxy 服務代理層：服務介面透明代理，生成服務的客戶端 Stub 和伺服器端 Skeleton, 以 ServiceProxy 為中心，擴充套件介面為 ProxyFactory。
l Registry 註冊中心層：封裝服務地址的註冊與發現，以服務 URL 為中心，擴充套件介面為 RegistryFactory, Registry, RegistryService。
l Cluster 路由層：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以 Invoker 為中心，擴充套件介面為 Cluster, Directory, Router, LoadBalance。
l Monitor 監控層：RPC 呼叫次數和呼叫時間監控，以 Statistics 為中心，擴充套件介面為 MonitorFactory, Monitor, MonitorService。
l Protocol 遠端呼叫層：封將 RPC 呼叫，以 Invocation, Result 為中心，擴充套件介面為 Protocol, Invoker, Exporter。
l Exchange 資訊交換層：封裝請求響應模式，同步轉非同步，以 Request, Response 為中心，擴充套件介面為 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer。
l Transport 網路傳輸層：抽象 mina 和 netty 為統一介面，以 Message 為中心，擴充套件介面為 Channel, Transporter, Client, Server, Codec。
l Serialize 資料序列化層：可複用的一些工具，擴充套件介面為 Serialization, ObjectInput, ObjectOutput, ThreadPool。
模組分包
各模組說明：
l dubbo-common公共邏輯模組：包括 Util 類和通用模型。
l dubbo-remoting遠端通訊模組：相當於 Dubbo 協議的實現，如果 RPC 用 RMI協議則不需要使用此包。
l dubbo-rpc遠端呼叫模組：抽象各種協議，以及動態代理，只包含一對一的呼叫，不關心叢集的管理。
l dubbo-cluster叢集模組：將多個服務提供方偽裝為一個提供方，包括：負載均衡, 容錯，路由等，叢集的地址列表可以是靜態配置的，也可以是由註冊中心下發。
l dubbo-registry註冊中心模組：基於註冊中心下發地址的叢集方式，以及對各種註冊中心的抽象。
l dubbo-monitor監控模組：統計服務呼叫次數，呼叫時間的，呼叫鏈跟蹤的服務。
l dubbo-config配置模組：是 Dubbo 對外的 API，使用者通過 Config 使用D ubbo，隱藏 Dubbo 所有細節。
l dubbo-container容器模組：是一個 Standlone 的容器，以簡單的 Main 載入 Spring 啟動，因為服務通常不需要 Tomcat/JBoss 等 Web 容器的特性，沒必要用 Web 容器去載入服務。
協議支援
l Dubbo協議（預設協議）
l Hessian協議
l HTTP協議
l RMI協議
l WebService協議
l Thrift協議
l Memcached協議
l Redis協議
註冊中心
（1）Multicast註冊中心：
Multicast註冊中心不需要啟動任何中心節點，只要廣播地址一樣，就可以互相發現。組播受網路結構限制，只適合小規模應用或開發階段使用。組播地址段: 224.0.0.0 - 239.255.255.255。
（2）Zookeeper註冊中心（推薦）：
Zookeeper是Apacahe子專案，是一個樹型的目錄服務，支援變更推送，適合作為Dubbo服務的註冊中心，可用於生產環境。
對上圖流程說明如下：
1. 服務提供者（Provider）啟動時，向/dubbo/com.foo.BarService/providers目錄下寫入URL。
2. 服務消費者（Consumer）啟動時，訂閱/dubbo/com.foo.BarService/providers目錄下的URL，向/dubbo/com.foo.BarService/consumers目錄下寫入自己的URL。
3. 監控中心（Monitor）啟動時，訂閱/dubbo/com.foo.BarService目錄下的所有提供者和消費者URL。
（3）Redis註冊中心：
阿里內部並沒有採用Redis做為註冊中心，而是使用自己實現的基於資料庫的註冊中心，即：Redis註冊中心並沒有在阿里內部長時間執行的可靠性保障，此Redis橋接實現只為開源版本提供，其可靠性依賴於Redis本身的可靠性。
（4）Simple註冊中心：
Simple註冊中心本身就是一個普通的Dubbo服務，可以減少第三方依賴，使整體通訊方式一致。只是簡單實現，不支援叢集，可作為自定義註冊中心的參考，但不適合直接用於生產環境。
遠端通訊與資訊交換
遠端通訊需要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語義的基礎上，還要保證高效、穩定的訊息傳輸。Dubbo繼承了當前主流的網路通訊框架，主要包括如下幾個：
l Mina
l Netty（預設）
l Grizzly
停止維護
從2012年10月23日Dubbo 2.5.3釋出後，在Dubbo開源將滿一週年之際，阿里基本停止了對Dubbo的主要升級。只在之後的2013年和2014年更新過2次對Dubbo 2.4的維護版本，然後停止了所有維護工作。Dubbo對Srping的支援也停留在了Spring 2.5.6版本上。
分支出現
在阿里停止維護和升級Dubbo期間，噹噹網開始維護自己的Dubbo分支版本Dubbox，支援了新版本的Spring，並對外開源了Dubbox。同時，網易考拉也維護了自己的獨立分支Dubbok，可惜並未對外開源。
重獲新生
經過多年漫長的等待，隨著微服務的火熱興起，在國內外開發者對阿里不再升級維護Dubbo的吐槽聲中，阿里終於開始重新對Dubbo的升級和維護工作。在2017年9月7日，阿里釋出了Dubbo的2.5.4版本，距離上一個版本2.5.3釋出已經接近快5年時間了。在隨後的幾個月中，阿里Dubbo開發團隊以差不多每月一版本的速度開始快速升級迭代，修補了Dubbo老版本多年來存在的諸多bug，並對Spring等元件的支援進行了全面升級。
分支合併
在2018年1月8日，Dubbo 2.6.0版本釋出，新版本將之前噹噹網開源的Dubbo分支Dubbox進行了合併，實現了Dubbo版本的統一整合。
Dubbo與Spring Cloud
阿里巴巴負責主導了Dubbo重啟維護的研發工程師劉軍在接受採訪時表示：當前由於RPC協議、註冊中心元資料不匹配等問題，在面臨微服務基礎框架選型時Dubbo與Spring Cloud是隻能二選一，這也是為什麼大家總是拿Dubbo和Spring Cloud做對比的原因之一。Dubbo之後會積極尋求適配到Spring Cloud生態，比如作為Spring Cloud的二進位制通訊方案來發揮Dubbo的效能優勢，或者Dubbo通過模組化以及對http的支援適配到Spring Cloud。
未來展望
2018年1月8日，Dubbo創始人之一樑飛在Dubbo交流群裡透露了Dubbo 3.0正在動工的訊息。Dubbo 3.0核心與Dubbo 2.0完全不同，但相容Dubbo 2.0。Dubbo 3.0將以Streaming為核心，不再是Dubbo 時代的RPC，但是RPC會在Dubbo 3.0中變成遠端Streaming對接的一種可選形態。Dubbo 3.0將支援可選Service Mesh，多加一層IPC，這主要是為了相容老系統，而內部則會優先嚐試內嵌模式。代理模式Ops可獨立升級框架，減少業務侵入，而內嵌模式可以帶業務測試、部署節點少、穩定性檢測方便。同時，可以將 Dubbo 3.0 啟動為獨立程序，由dubbo-mesh進行IPC，路由、負載均衡和熔斷機制將由獨立程序控制。
總結
從Dubbo新版本的路線規劃上可以看出，新版本的Dubbo在原有服務治理的功能基礎上，將全面擁抱微服務和Service Mesh。同時，考慮到在阿里雲已經有了Dubbo的商業版本，在未來一段時間內，Dubbo的更新與維護應該不會再長時間中斷。在我們進行服務治理以及微服務架構設計時，新版本Dubbo對我們廣大開發者來說都將會是一個不錯的選擇。
--------------------------------二--------------------------
引言
作為本系列文章的第二篇，本文主要為大家介紹下微服務概念中非常火熱的Spring Cloud開發框架。由於網上關於Spring Cloud的文章多如牛毛，為了讓大家閱讀後能有不一樣的收穫，因此本文將用一個相對輕鬆的敘述方式來為大家講解一下Spring Cloud框架和微服務。雖然不可能通過一篇文章讓大家對Spring Cloud做到從“入門到精通到放棄”，但是希望大家通過閱讀本文能對Spring Cloud和微服務有一個更加清晰的認識和了解，為後面學習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最常用的幾個元件做一個簡單的介紹：
l Eureka：服務註冊中心，一個基於REST的服務，用於定位服務，以實現微服務架構中服務發現和故障轉移。
l Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
l Turbine：Turbine是聚合伺服器傳送事件流資料的一個工具，用來監控叢集下Hystrix的Metrics情況。
l Zuul：API閘道器，Zuul是在微服務中提供動態路由、監控、彈性、安全等邊緣服務的框架。
l Ribbon：提供微服務中的負載均衡功能，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。
l Feign：Feign是一種宣告式、模板化的HTTP客戶端。
l Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠端伺服器，集中化管理叢集配置，目前支援本地儲存、Git以及Subversion。
l Spring Cloud Security：基於Spring Security的安全工具包，為微服務的應用程式新增安全控制。
l Spring Cloud Sleuth：日誌收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為SpringCloud應用實現了一種分散式追蹤解決方案。
除了上面介紹的基礎元件外，常見的Spring Cloud元件還有非常多種，涉及到了微服務以及應用開發的方方面面：
l Spring Cloud Starters：Spring Boot式的啟動專案，為Spring Cloud提供開箱即用的依賴管理。
l Archaius：配置管理API，包含一系列配置管理API，提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回撥機制等功能。
l Consul：封裝了Consul操作，Consul是一個服務發現與配置工具，與Docker容器可以無縫整合。
l Spring Cloud Stream：資料流操作開發包，封裝了與Redis,Rabbit、Kafka等傳送接收訊息。
l Spring Cloud CLI：基於 Spring Boot CLI，可以讓你以命令列方式快速建立雲元件。
l Spring Cloud Task：提供雲端計劃任務管理、任務排程。
l Spring Cloud Bus：事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
l Spring Cloud Data Flow：大資料操作工具，作為Spring XD的替代產品，它是一個混合計算模型，結合了流資料與批量資料的處理方式。
l Spring Cloud Zookeeper：操作Zookeeper的工具包，用於使用zookeeper方式的服務發現和配置管理。
l Spring Cloud Connectors：便於雲端應用程式在各種PaaS平臺連線到後端，如：資料庫和訊息代理服務。
Spring Cloud 之“精通”
Spring Cloud雖然集成了眾多元件，可以構建一個完整的微服務應用，但是其中的各個元件卻並非完美無缺，很多元件在實際應用中都存在諸多不足和缺陷。因此，需要我們對其中的一些元件進行替換和修改，方能構建一個強大、靈活、健壯的微服務架構應用。
l 配置中心：
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等多種場景的應用。
l 註冊中心
作為Spring Cloud的服務註冊中心，從分散式CAP理論來看，Eureka採用是AP型設計，強調的是註冊中心的高可用性。和Dubbo常用的服務註冊中心Zookeeper相比，Zookeeper則是採用的CP型設計，強調的是註冊中心資料的一致性。
Eureka的設計確實簡單易用，但是預設沒有實現對註冊中心資料的持久化。同時，在極端場景下，也會出現多個Eureka註冊中心節點資料不一致，甚至服務註冊資料丟失的情況。當然，從分散式CAP理論來看，理論上是沒辦法做到同時兼顧CAP三點的。目前也有一些網際網路公司對Eureka進行了改造，支援了資料的持久化，但是尚不能完整的支援CAP的全部要求。
l API閘道器
API閘道器可以說是微服務需求最多，也是最有難點的一個元件。Spring Cloud中整合的Zuul應該說更多的是實現了服務的路由功能，對於負載均衡等其他功能，需要結合Ribbon等元件來實現。對於很多個性化的需求，需要開發者自己來進行編碼實現。
和大部分基於Java的Web應用類似，Zuul也採用了Servlet架構，因此Zuul處理每個請求的方式是針對每個請求是用一個執行緒來處理。同時，由於Zuul是基於JVM的實現，因此效能也會在高併發訪問場景下成為瓶頸。雖然網上一些文章評測Zuul和Nginx效能接近，但是在效能要求較高的場景下，JVM的記憶體管理和垃圾回收問題，仍然是一個很大的問題。所以在實際的應用場景中，通常會採用在多個Zuul幾點前面再新增一層Nginx或者OpenResty來進行代理。
為了解決Zuul的效能問題，Netflix將自己的閘道器服務Zuul進行了升級，新的Zuul 2將HTTP請求的處理方式從同步變成了非同步，並且新增諸如HTTP/2、websocket等功能。但是遺憾的是，開源版本的Zuul 2一直處於難產狀態中，始終沒有和大家正式見面。
l 熔斷器
微服務中對於服務的限流、降級、熔斷的需求是多種多樣的，需要在API閘道器和各個具體服務介面中分別進行控制，才能滿足複雜場景下微服務架構的應用需求。
單獨使用Spring Cloud中的Hystrix無法完整的滿足上述的複雜需求，需要結合API閘道器，並通過Kubernetes對資源、程序和名稱空間來提供隔離，並通過部分自定義編碼方能實現對全部服務的限流、降級、熔斷等需求。
l 監控系統
無論是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 |
Spring Cloud |
|
|
註冊中心 |
Zookeeper |
Spring Cloud Eureka |
|
服務呼叫方式 |
RPC |
Restful API |
|
服務閘道器 |
無 |
Spring Cloud Zuul |
|
降級與熔斷 |
只有降級，沒有熔斷 |
Spring Cloud Hystrix |
|
配置中心 |
無 |
Spring Cloud Config |
|
服務跟蹤 |
Dubbo-admin & Dubbo-monitor |
Spring Cloud Sleuth |
|
訊息匯流排 |
無 |
Spring Cloud Bus |
|
資料流 |
無 |
Spring Cloud Stream |
|
批量任務 |
無 |
Spring Cloud Task |
實際上，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在微服務架構中的一些基礎功能上的對比。
|
Kubernetes |
Spring Cloud |
|
|
註冊中心 |
Kubernetes Service & Ingress Resource |
Spring Cloud Eureka |
|
配置中心 |
Kubernetes ConfigMap & Secrets |
Spring Cloud Config |
|
服務閘道器 |
Kubernetes Service & Ingress Resource |
Spring Cloud Zuul |
|
降級與熔斷 |
Kubernetes Health Check & Resource Isolation |
Spring Cloud Hystrix |
|
負載均衡 |
Kubernetes Service |
Spring Cloud Ribbon |
|
服務跟蹤 |
OpenTracing |
Spring Cloud Sleuth |
|
服務安全 |
無 |
Spring Cloud Security |
|
打包部署 |
Kubernetes Scheduler & Deployment |
Spring Boot |
|
任務工作管理 |
Kubernetes Jobs & Scheduled Jobs |
Spring Batch |
通過對比可以看出，Spring Cloud和Kubernetes確實存在一些功能上的重合，但是二者的定位其實差別很大。Spring Cloud是一個基於Java語言的微服務開發框架，而Kubernetes是一個針對容器應用的自動化部署、伸縮和管理的開源系統，它相容多種語言且提供了建立、執行、伸縮以及管理分散式系統的原語。Spring Cloud更多的是面向有Spring開發經驗的Java語言開發者，而Kubernetes不是一個針對開發者的平臺，它的目的是供有DevOps思想的IT人員使用。
為了區分Spring Cloud和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等都是需要學習和掌握的內容。同時，由於採用微服務架構後帶來了分散式的相關問題，對於分散式系統理論也必須有一定的瞭解。當然，最重要的還是對系統業務的深入理解，對整體業務進行合理的規劃和拆分，才能真正行之有效的應用微服務架構，構建高效、健壯、靈活、可擴充套件的微服務應用。
----------------------三-----------------------------
引言
作為本系列文章的第三篇，本文主要為大家介紹下當前非常火熱的Service Mesh概念，最後也會簡單介紹一下目前同樣非常熱門的Serverless概念。Service Mesh目前比較多的翻譯為“服務網格”，也有翻譯為“服務齧合”。很多人將之稱為下一代微服務，或直接稱之為微服務2.0。前兩篇文章中介紹的Dubbo和Spring Cloud實際上距離真正意義上的微服務還有一定的距離，本文將帶你瞭解在微服務2.0時代，Service Mesh方式是如何實現下一代微服務標準的，並介紹當前比較常見的幾種Service Mesh實現方案。
微服務1.0時代
Dubbo本質上只能算是一個服務治理框架，而不能算是一個微服務框架。雖然在未來的Dubbo 3.0中會提供對Spring Cloud，以及對Service Mesh的支援，但是單憑Dubbo仍然是無法搭建一個完整的微服務體系結構。
Spring Cloud則是通過整合眾多的元件的形式實現了相對完整的微服務技術棧，但是Spring Cloud的實現方式程式碼侵入性較強，而且只支援Java語言，無法支援其他語言開發的系統。Spring Cloud全家桶包括的內容較多，學習成本也相對較高，對老系統而言，框架升級或者替換的成本較高，導致一些開發團隊不願意擔負技術和時間上的風險與成本，使得微服務方案在落地時遇到了諸多的困難。
總結一下，微服務1.0時代的主要問題主要包括如下三方面：
- 技術門檻高：開發團隊在實施微服務的過程中，除了基礎的服務發現、配置中心和鑑權管理之外，團隊在服務治理層面面臨了諸多的挑戰，包括負載均衡、熔斷降級、灰度釋出、故障切換、分散式跟蹤等，這對開發團隊提出了非常高的技術要求。
- 多語言支援不足：對於網際網路公司，尤其是快速發展的網際網路創業公司，多語言的技術棧、跨語言的服務呼叫也是常態，但目前開源社群上並沒有一套統一的、跨語言的微服務技術棧，而跨語言呼叫恰恰是微服務概念誕生之初的要實現的一個重要特性之一。
- 程式碼侵入性強：Spring Cloud、Dubbo等主流的微服務框架都對業務程式碼有一定的侵入性，技術升級替換成本高，導致開發團隊配合意願低，微服務落地困難。
微服務2.0時代
為了解決微服務1.0時代的諸多問題，Service Mesh概念開始走入了開發者的視線中。
在介紹Service Mesh概念之前，我們先來了解一下Sidecar。Sidecar是以第一次世界大戰時活躍在戰場上的軍用邊斗車命名（也是我們在抗日神劇中最常見的道具之一）。Sidecar是Service Mesh中的重要組成部分，Sidecar在軟體系統架構中特指邊斗車模式，這個模式的精髓在於實現了資料面（業務邏輯）和控制面的解耦。
在Service Mesh架構中，給每一個微服務例項部署一個Sidecar Proxy。該Sidecar Proxy負責接管對應服務的入流量和出流量，並將微服務架構中的服務訂閱、服務發現、熔斷、限流、降級、分散式跟蹤等功能從服務中抽離到該Proxy中。
Sidecar以一個獨立的程序啟動，可以每臺宿主機共用同一個Sidecar程序，也可以每個應用獨佔一個Sidecar程序。所有的服務治理功能，都由Sidecar接管，應用的對外訪問僅需要訪問Sidecar即可。當該Sidecar在微服務中大量部署時，這些Sidecar節點自然就形成了一個服務網格。
微服務的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念則是在2016年左右提出，Service Mesh至今也經歷了第二代的發展。
第一代Service Mesh的代表為Linkerd和Envoy。Linkerd基於Twitter的Fingle，使用Scala編寫，是業界第一個開源的Service Mesh方案，在長期的實際生產環境中獲得驗證。Envoy底層基於C++，效能上優於使用Scala的Linkrd。同時，Envoy社群成熟度較高，商用穩定版本面世時間也較長。這兩個開源實現都是以Sidecar為核心，絕大部分關注點都是如何做好Proxy，並完成一些通用控制面的功能。但是當你在容器中大量部署Sidecar以後，如何管理和控制這些Sidecar本身就是一個不小的挑戰。
第二代Service Mesh主要改進集中在更加強大的控制面功能（與之對應的Sidecar Proxy被稱之為資料面），典型代表有Istio和Conduit。Istio是Google、IBM和Lyft合作的開源專案，是目前最主流的Service Mesh方案，也是事實上的第二代Service Mesh標準。在Istio中，直接把Envoy作為Sidecar。除了Sidecar，Istio中的控制面元件都是使用Go語言編寫。
Istio簡介
根據Istio官方文件的介紹，Istio在服務網路中主要提供了以下關鍵功能：
- 流量管理：控制服務之間的流量和API呼叫的流向，使得呼叫更可靠，並使網路在惡劣情況下更加健壯。
- 可觀察性：瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。
- 策略執行：將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是通過配置網格而不是修改應用程式程式碼。
- 服務身份和安全：為網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其可以在不同可信度的網路上流轉。
- 平臺支援：Istio旨在在各種環境中執行，包括跨雲、Kubernetes、Mesos等。最初專注於Kubernetes，但很快將支援其他環境。
- 整合和定製：策略執行元件可以擴充套件和定製，以便與現有的ACL、日誌、監控、配額、稽核等解決方案整合。
Istio針對可擴充套件性進行了設計，以滿足不同的部署需要。這些功能極大的減少了應用程式程式碼、底層平臺和策略之間的耦合，使得微服務更加容易實現。
下圖為Istio的架構設計圖，主要包括了Envoy、Pilot、Mixer和Istio-Auth等。
- Envoy: 扮演Sidecar的功能，協調服務網格中所有服務的出入站流量，並提供服務發現、負載均衡、限流熔斷等能力，還可以收集與流量相關的效能指標。
- Pilot: 負責部署在Service Mesh中的Envoy例項的生命週期管理。本質上是負責流量管理和控制，將流量和基礎設施擴充套件解耦，這是Istio的核心。可以把Pilot看做是管理Sidecar的Sidecar, 但是這個特殊的Sidacar並不承載任何業務流量。Pilot讓運維人員通過Pilot指定它們希望流量遵循什麼規則，而不是哪些特定的pod/VM應該接收流量。有了Pilot這個元件，我們可以非常容易的實現 A/B 測試和金絲雀Canary測試。
- Mixer: Mixer在應用程式程式碼和基礎架構後端之間提供通用中介層。它的設計將策略決策移出應用層，用運維人員能夠控制的配置取而代之。應用程式程式碼不再將應用程式程式碼與特定後端整合在一起，而是與Mixer進行相當簡單的整合，然後Mixer負責與後端系統連線。Mixer可以認為是其他後端基礎設施（如資料庫、監控、日誌、配額等）的Sidecar Proxy。
- Istio-Auth: 提供強大的服務間認證和終端使用者認證，使用互動TLS，內建身份和證書管理。可以升級服務網格中的未加密流量，併為運維人員提供基於服務身份而不是網路控制來執行策略的能力。Istio的未來版本將增加細粒度的訪問控制和審計，以使用各種訪問控制機制（包括基於屬性和角色的訪問控制以及授權鉤子）來控制和監視訪問服務、API或資源的訪問者。
Istio的設計理念先進，功能也比較強大，加之Google、IBM的影響力讓Istio迅速傳播，讓廣大開發者認識到了Istio專案在Service Mesh領域的重要性。但是Istio目前版本也存在了一些不足：
- 目前的Istio大部分能力與Kubernetes是強關聯的。而我們在構建微服務的時候往往是希望服務層與容器層是解耦的，服務層在設計上需要能夠對接多種容器層平臺。
- Istio至今未有穩定版本，截至本文編寫時為止，Istio的最新版本為0.8版本，預計在2018年內會發布1.0版本。
Conduit簡介
我們再來看一下Conduit的實現，下圖是Conduit的架構設計圖，其中重點由Conduit Data Plane和Conduit Control Plane兩部分組成：
Conduit各方面的設計理念與Istio非常類似，作者使用Rust語言重新編寫了Sidecar, 叫做Conduit Data Plane, 控制面則由Go語言編寫的Conduit Control Plane接管。從Conduit的架構看，作者號稱Conduit吸取了很多Linkerd的教訓，比Linkerd更快、更輕、更簡單，控制面功能更強。與Istio比較，Conduit的架構一方面比較簡單，另一方面對於要解決的問題足夠聚焦。
Serverless簡介
Serverless被翻譯為“無伺服器架構”，這個概念在2012年時便已經存在，比微服務和Service Mesh的概念出現都要早，但是直到微服務概念大紅大紫之後，Serverless才重新又被人們所關注。
Serverless（無伺服器架構）並不意味著沒有任何伺服器去執行程式碼，Serverless是無需管理伺服器，只需要關注程式碼，而提供者將處理其餘部分工作。“無伺服器架構”也可以指部分伺服器端邏輯依然由應用程式開發者來編寫的應用程式，但與傳統架構的不同之處在於，這些邏輯執行在完全由第三方管理，由事件觸發的無狀態（Stateless）暫存於計算容器內。
對於開發者來說，Serverless架構可以將其伺服器端應用程式分解成多個執行不同任務的函式，整個應用分為幾個獨立、鬆散耦合的元件，這些元件可以在任何規模上執行。
下圖為一種常見的Serverless架構圖，所有的服務都以FaaS（函式即服務）的方式對外進行提供。在語言和環境方面，FaaS 函式就是常規的應用程式，例如使用JavaScript、Python以及 Java等語言實現。
Serverless架構優勢
- 縮短交付時間：Serverless架構允許開發人員在極短時間內（幾小時、幾天）交付新的應用程式，而不是像以前一樣需要幾個星期或幾個月。在新的應用程式中，依賴於第三方API提供服務的例子很多，如認證(OAuth)、社交、地圖、人工智慧等。
- 增強可伸縮性：所有人都希望自己開發的應用能夠快速獲取大量的新增使用者，但是當活躍使用者快速增長的時候，伺服器的壓力也會激增。使用Serverless架構的體系不再有上述擔憂，可以及時、靈活進行擴充套件來應對快速增長的活躍使用者帶來的訪問壓力。
- 降低成本：Serverless架構模式可以降低計算能力和人力資源方面的成本，如果不需要伺服器，就不用花費時間重新造輪子、風險監測、影象處理，以及基礎設施管理，操作成本會直線下降。
- 改善使用者體驗：使用者通常不太關心基礎設施，而更注重於功能和使用者體驗。Serverless架構允許團隊將資源集中在使用者體驗上。
- 減少延遲及優化地理位置資訊：應用規模能力取決於三個方面：使用者數量、所在位置及網路延遲。當應用要面向全國甚至全球使用者的時候，通常會產生較高的延遲，從而降低使用者體驗。在Serverless架構下，供應商在每個使用者附近都有節點，大幅度降低了訪問延遲，因此所有使用者的體驗都可以得到提升。
總結
對於大規模部署微服務，內部服務異構程度高的場景，使用Service Mesh方案是一個不錯的選擇。Service Mesh實現了業務邏輯和控制的解耦，但是也帶來了額外的開銷，由於網路中多了一跳，增加了效能的損耗和訪問的延遲。同時，由於每個服務都需要部署Sidecar, 這也會使本來就具有一定複雜度的分散式系統變得更加複雜。尤其是在實施初期，對Service Mesh的管理和運維會是一個棘手的問題。因此，當我們選擇使用Service Mesh架構的時候，需要對具體的Service Mesh實現方案（例如：Istio）做好充分的技術準備和經驗積累工作，方能確保方案的順利實施。
在微服務與容器技術火熱之後，Serverless（無伺服器架構）成為新的熱點，無伺服器雲函式可以讓使用者無需關心伺服器的部署運營，只需開發最核心的業務邏輯，即可實現上線運營，具備分佈容災能力，可以依據負載自動擴縮容，並按照實際呼叫次數與時長計費。
使用Serverless架構可以免除所有運維性操作，開發人員可以更加專注於核心業務的開發，實現快速上線和迭代，把握業務發展的節奏。Serverless架構可以認為是對微服務和容器化的一種補充，為使用者提供了一種新的選擇，來應對複雜多變的需求，尤其適合快速發展的初創型公司。