在 Kubernetes容器雲平臺於眾多企業裡遍地實施開花後，迅速結出的果實：應用微服務化當仁不讓的居於首位。眾所周知，基於容器平臺構建後端服務，可以更加迅速的實現業務微服務化，與之而來的框架選型討論也迅速火熱了起來。

微服務框架選型之爭

選項其實很多，這裡挑選一些討論火熱、或者主流的來對比，僅供參閱。

主流微服務框架：SpringCloud、Dubbo

新銳微服務框架：Istio

-1-

框架背景對比

（1）Spring Cloud，來源於 Spring Source ，具有 Spring社群的強大背書外，還有Netflix強大的後盾與技術輸出。Netflix作為一家成功實踐微服務架構的網際網路公司，在幾年前就把幾乎整個微服務框架棧開源貢獻給了社群，這些框架開源的整套微服務架構套件是 Spring Cloud的核心。

·Eureka:服務註冊發現框架；

·Zuul:服務閘道器；

·Karyon:服務端框架；

·Ribbon:客戶端框架；

·Hystrix:服務容錯元件；

·Archaius:服務配置元件；

·Servo: Metrics元件；

·Blitz4j:日誌元件。

（2）Dubbo是一個分散式服務框架，是國內網際網路公司開源做的比較不錯的阿里開放的微服務化治理框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。其核心部分包含:

·遠端通訊:提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”模式的資訊交換方式；

·叢集容錯:提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援；

·自動發現:基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo也是採用全 Spring配置方式，透明化接入應用，對應用沒有任何 API侵入，只需用 Spring載入 Dubbo的配置即可，Dubbo基於 Spring的 Schema擴充套件進行載入。當然也支援官方不推薦的 API呼叫方式。

（3）Istio作為用於微服務服務聚合層管理的新銳專案，是Google、IBM、Lyft（海外共享出行公司、Uber勁敵）首個共同聯合開源的專案，提供了統一的連線，安全，管理和監控微服務的方案。

目前首個測試版是針對Kubernetes環境的，社群宣稱在未來幾個月內會為虛擬機器和 Cloud Foundry等其他環境增加支援。 Istio將流量管理新增到微服務中，併為增值功能（如安全性，監控，路由，連線管理和策略）創造了基礎。

·HTTP、gRPC和 TCP網路流量的自動負載均衡；

·提供了豐富的路由規則，實現細粒度的網路流量行為控制；

·流量加密、服務間認證，以及強身份宣告；

·全範圍（Fleet-wide）的策略執行；

·深度遙測和報告。

-2-

開源社群活躍度對比

開源社群情況：現如今企業在採用雲端計算首選開源，而選擇一個開源框架，社群的活躍度將作為重要參考選項。

檢視下在 Github上的更新時間，截止 2017年 8月 31日：

·Spring Cloud：Spring Cloud · GitHub→所有專案均更新於『1小時』內。

·Dubbo：Dubbo · GitHub→核心專案最近更新於『一個月乃至數月』前。

·Istio：Istio · GitHub→所有專案均更新於『30分鐘』內。

可見，專案在社群活躍度上，Istio > Spring Cloud > Dubbo，結合穩定性來看，對於使用 Java系開發業務較多的企業，Spring Cloud是相對更優的選擇，對於更多企業來說，與語言幾乎無繫結的 Istio也是可以好好期待一下其在社群的發展。

總結：結合專案背景、提供功能、社群更新活躍度，SpringCloud是目前階段最為穩妥的可執行微服務框架方案，Istio作為支援對於 Kubernetes的優先支援來講，也是一個值得關注的方案。目前對比來看，Dubbo則顯得稍遜下來。