SpringCloudAlibaba，中國Javaer的福音，為微服務續上18年

Java 界最近發生了一件大事，Spring Cloud 官方宣佈阿里開源 Spring Cloud Alibaba，並推出首個預覽版。

據介紹，Spring Cloud Alibaba 由阿里開源元件和阿里雲產品元件兩部分組成，其致力於提供微服務一站式解決方案，方便開發者通過 Spring Cloud 程式設計模型輕鬆開發微服務應用。

開源的訊息引起了巨大的反響，Spring Cloud Alibaba 的到來，不僅引起了 Java 開發者的高度關注，也讓人們將目光聚集到了專案背後當下最炙手可熱的微服務架構領域。

目前使用 Spring Cloud 的第一選擇是 Spring Cloud Netflix，它的領先地位不可撼動，而此次阿里開源的“原生國產”環境下的這一專案，是不是會對此帶來變革？而隨著越來越多的落地實踐，微服務架構的弊端已逐漸顯露，此時阿里加碼該領域的這一大動作，背後有什麼考量呢？

此外還有開發者關注度相當高的專案後期維護、Dubbo 是否又一次被拋棄等問題……我們第一時間採訪了阿里巴巴中介軟體高階技術專家姬望，希望能讓大家對 Spring Cloud Alibaba 這個專案、對相關領域的發展與趨勢有更多的瞭解。

本文內容較長，這裡先提取幾個要點：

 ●  再也不會不明白 Spring XXXXXX 到底是什麼
 ●  中國 Java 開發者的福音
 ●  微服務架構領域變天
 ●  Dubbo 沒有被拋棄
 ●  下一代架構不是流式架構，而是 Serverless
 ●  雲端計算終將統治整個服務端架構
 ●  明年 2 月 GA

Spring？Spring Boot？Spring Framework？Spring Cloud？Spring Cloud Alibaba？Spring 全家桶在 Java 開發中是不得不提的，雖然知名度很高、使用度高，但是其實許多人就只是使用著框架，甚至對於什麼是 Spring Cloud 都不甚瞭解，對上邊這些術語傻傻分不清楚。借這個機會，請您給大家仔細地介紹一下吧。

在國內 Javaer 界，單說 Spring 這個詞，其實並不具體指什麼，它只是一個代號，具體代表的含義，是要看語境的。比如我說 Spring 那幫大神，那這時候 Spring 指的就是 Spring 公司；再比如我說你們平時開發用 Spring 嗎，這時 Spring 一般指的其實是 Spring IOC，而且大部分情況下，我們說 Spring 指的都是 Spring IOC。

Spring IOC 是什麼這裡就不多解釋了，相信大家都不陌生，而且，這應該是最火的面試題之一吧。Spring Framework 圍繞著 Spring IOC 與核心的 Spring AOP 功能，還實現了與諸多 J2EE 開發框架的整合，大大降低了企業級應用開發的難度，提高了效率。

幾年前很火的 SSH 框架就是一個典型的 Spring Framework 整合 Hibernate 和 Struts2 的例子。當時，學會 SSH 整合，那可是一門手藝，那複雜的配置檔案、層出不窮的 Jar 包，絕對可以讓你眼花繚亂、欲罷不能。所以，現在的 Javaer 是幸福的，因為 Spring Boot 解決了這個問題。

Spring Boot 讓你可以引入一個 POM 依賴就實現所有 Jar 包的管理，也可以讓你一個配置檔案、幾行簡單的配置就解決所有複雜的配置問題。Spring Boot 的宗旨就是讓使用者可以更簡單地開發基於 Spring Framework 搭建的應用，不得不說，Spring Boot 完美地實現了它的宗旨。

至於 Spring Cloud，它是在 Spring Boot 的基礎上，增加了一堆微服務相關的規範，並對應用上下文（Application Context）進行了功能增強。

既然 Spring Cloud 是規範，那麼就需要去實現，Spring Cloud Alibaba 就是 Spring Cloud 微服務規範的一套實現。

總結起來就是：

 ●  Spring 通常指 Spring IOC。
 ●  Spring Framework 包含了 Spring IOC，同時包含了 Spring AOP，並實現與其它 J2EE 框架的整合。
 ●  Spring Boot 是對 Spring Framework 的補充，讓框架的整合變得更簡單，致力於快速開發 獨立的 Spring 應用。
 ●  Spring Cloud 是基於 Spring Boot 設計的一套微服務規範，並增強了應用上下文。
 ●  Spring Cloud Alibaba 採用阿里中介軟體作為原料，實現了 Spring Cloud 的微服務規範。

目前 Spring Cloud 規範已有 Spring Cloud Netflix 等實現，那 Alibaba 這一套的主要區別與優勢是什麼？

Spring Cloud Alibaba 的元件孵化自阿里巴巴內部自用的中介軟體產品，這些中介軟體經歷過多次雙 11 的考驗（雙 11 是目前世界上最大最複雜的電商交易場景），具備超強的抗壓能力這點毋庸置疑。此外，Spring Cloud Alibaba 完整的原生中文文件和本地化的開源服務將大大降低開發者的學習成本，提高接入速率，並降低後續的運維難度。

具體到其中的各個元件來看：

Nacos

Nacos 基於阿里內部配置管理和服務發現元件開源，經歷過多次雙 11 檢驗，支援超大規模叢集，穩定性和效能上值得信賴。後續我們還會基於這套成熟的業務模型，建設灰度釋出、環境隔離、全鏈路壓測這些更高階的特性，將更多阿里在微服務實踐方面的大殺器輸出。

Nacos Discovery

Nacos Discovery、Spring Cloud Netflix Eureka、ZooKeeper 和 Consul 都遵循了 Spring Cloud 服務發現的標準實現，也很好地適配了 Ribbon。相比之下，Nacos Discovery 有如下特點：

 ●  支援實時推送，達到秒級服務發現。
 ●  多層容災機制，儘量保證服務發現中心當機不影響應用呼叫。

Nacos Config

Nacos Config 和 Spring Cloud Config、ZooKeeper 與 Consul 一樣，都遵循了 Spring Cloud 配置標準實現，但是依賴元件更少，使用更加簡單，功能更加強大。

例如它無需 Spring Cloud Bus、MQ，直接就可以實現配置的實時推送，而且推送狀態可查。支援資料回滾、支援多種資料格式、完美支援中文，最後還依賴多重容災機制確保配置服務端的故障不影響應用本身。

RocketMQ

Spring Cloud 官方的 Spring Cloud Stream 框架遮蔽了底層訊息中介軟體的處理，使用統一的程式設計模型進行程式設計。目前官方只有 Kafka 和 RabbitMQ 的 Binder 實現。阿里巴巴的 RocketMQ 訊息中介軟體，已經成為了 Apache 的頂級專案，社群上也有很多人在諮詢什麼時候能出 RocketMQ 的 Binder，而我們也認為這是非常有必要的。

Sentinel

目前 Spring Cloud 官方推薦的斷路器是 Hystrix。Sentinel 是阿里中介軟體團隊開源的，面向分散式服務架構的輕量級高可用流量控制元件，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助使用者保護服務的穩定性。Sentinel 與 Hystrix 兩者具有一些共同特性，但底層的實現方式不一致。

相比之下 Sentinel 有以下特性：

 ●  輕量級、高效能
 ●  多樣化的流量控制策略
 ●  系統負載保護和實時監控與控制皮膚等塵燭寫 OSS 、SchedulerX 與 ARMS 的優勢

SchedulerX

SchedulerX 是一套高可靠的分散式任務排程系統，支援海量任務秒級別排程，支援 Java、指令碼、http 等多種任務型別，提供分散式程式設計模型可以進行大資料跑批，接入簡單易用。

ARMS

ARMS 是一款 APM 類的監控產品，使用者可基於 ARMS 的前端監控、應用監控或者自定義監控，快速構建實時的應用效能和業務監控能力。

OSS

OSS 是阿里雲提供的雲端儲存服務，它具有與平臺無關的 RESTful API 介面，能夠提供 99.999999999%（11 個 9）的資料可靠性和 99.99% 的服務可用性。

Spring Cloud Alibaba 入駐了 Spring Cloud 孵化器，這個訊息可以說是比較突然的，能不能介紹一下從最開始到今天進入孵化器的整個過程，以及背後的心路歷程。

去年年末的時候，我們看到 Spring Cloud 子專案中有 spring-cloud-aws 和 spring-cloud-gcp 這些元件，它們可以提升 AWS 和 GCP 使用者在使用 Spring Boot 程式設計時的效率。

那時候我們想如果把阿里雲的產品也整合到 Spring Cloud 生態中，那肯定也能增加阿里雲上 Java 使用者的幸福感，所以我們著手做了相關工作，最開始專案叫 spring-cloud-alibabacloud。

但是後來，隨著阿里中介軟體全面擁抱開源，服務發現和配置管理元件 Nacos、流量保護 Sentinel 這些重量級的中介軟體陸續開源出來，同時我們也發現開源社群在使用 Spring Cloud 已有實現的時候遇到這樣那樣的問題。這個時候，我們覺得將這些經過多次雙 11 檢驗的生產級別中介軟體接入到 Spring Cloud 生態會是一件更酷的事情。於是我們將 Spring Cloud Alibaba 單獨成項，提交到了 Spring Cloud 官方。

目前我們釋出了第一個版本，包含了 Nacos 和 Sentinel，以及阿里雲的 OSS、ACM 和 ANS。隨著阿里開源的力度不斷加大，後續會有更多元件加入。

Spring Cloud Alibaba 成為官方認證的新一套 Spring Cloud 規範的實現，從多方面來講這意味著什麼呢？

我從以下幾個方面來講一講吧。

首先是彌補 Spring Cloud 原生實現在大規模叢集場景上的侷限性。Spring Cloud 規範的實現目前有很多，比如 Netflix 有自己的一整套體系，Consul 支援服務註冊和配置管理，ZK 支援服務註冊等。每套實現或多或少都有各自的優缺點，或許大多數 Spring Cloud 使用者很難體會到原生實現的侷限性，無論是服務發現、分散式配置，還是服務呼叫和熔斷都不太適合大規模叢集場景，比如我們內部也遇到 Eureka 效能問題。因此，阿里將自身的超大規模叢集經驗與強大的 Spring Cloud 生態整合，實現強強聯合，相信對業界會產生積極的化學變化。

另一個影響是我們覺得這可以造福中國的 Javaer。我們發現目前 Spring Cloud 的第一選擇 Spring Cloud Netflix 在國內並不是有特別多的人精通，而且它們的文件都是英文的，出問題後排查也比較困難。

Spring Cloud Alibaba 是一套國產開源產品集合，後續我們會提供中文 reference 和一些原理分析文章，這對於國內的開發者是非常棒的一件事。

阿里巴巴的宗旨是“讓天下沒有難做的生意”，其實阿里的眾多 Javaer 一直以來也有一個宗旨，那就是“造福中國的 Javaer”。不論是之前的 Dubbo 也好，還是前段時間的 Java 開發手冊也好，都很好地體現了我們的宗旨，如今，我們拿出 Spring Cloud Alibaba，繼續貫徹我們的宗旨。

還有一個方面是對於微服務架構領域來說的。隨著微服務架構日益普及，這方面的知識儲備也越來越重要，越來越迫切，Spring Cloud Alibaba 的出現，可以說是恰逢其時。而對於微服務這個領域來說，Spring Cloud Alibaba 的出現，也會讓這個圈子產生不小的化學反應。前段時間，有文章表示阿里有這麼強勁的技術實力，而且又是中文環境，後續 Spring Cloud Alibaba 可能會替代掉 Spring Cloud Netflix，微服務領域要變天，我覺得這非常有可能。

有人要問，阿里這樣搞，那同樣深耕微服務領域的 Dubbo 算什麼？前陣子才為它的復出歡呼雀躍啊，扔了嗎？

其實很多人都有一個誤解，認為 Dubbo 和 Spring Cloud 是二選一，甚至對立的關係，這裡我們需要著重澄清一下。

聯絡前邊講到的內容，Spring Cloud 並不是等同於 Spring Cloud Netflix 的 Ribbon、Feign、Eureka、Hystrix 這一套元件。而是抽象了一套通用的開發模式，它的目的是通過抽象出這套通用的模式，讓開發者更快更好地開發業務。

但是這套開發模式執行時的實際載體，還是依賴於 RPC、閘道器、服務發現、配置管理、限流熔斷、分散式鏈路跟蹤等元件的具體實現。

Dubbo 與 Spring Cloud 並不是競爭關係，Dubbo 作為成熟的 RPC 框架，其易用性、擴充套件性和健壯性已得到業界的認可。未來 Dubbo 將會作為 Spring Cloud Alibaba 的 RPC 元件，並與 Spring Cloud 原生的 Feign 以及 RestTemplate 進行無縫整合，實現“零”成本遷移。

在阿里巴巴的微服務解決方案中，Dubbo、Nacos 和 Sentinel，以及後續將開源的微服務元件，都是 Dubbo EcoSystem 的一部分。我們後續也會將 Dubbo EcoSystem 整合到 Spring Cloud 的生態中。

所以總結一下就是：Spring Cloud 抽象了微服務程式設計通用模式，而 Dubbo EcoSystem 是微服務的最佳實踐。

微服務架構特別火，但是其實它也存在一些問題，最近有人就因此指出微服務架構要完蛋了，並且否定了“Service Mesh 作為下一代微服務架構”的觀點，同時說明像 Flink 這樣的流式架構將成為新主流。阿里此次通過 Spring Cloud Alibaba 加碼微服務，想必是不認同微服務架構要結束的觀點。類比一下單體、SOA、Serverless 等架構，您覺得微服務架構已經發展到了一個什麼樣的階段呢？請您具體分享一下。

【文章詳見：https://zhuanlan.zhihu.com/p/48036811】

我覺得微服務目前處在蓬勃發展的階段，Service Mesh、Serverless 其實都隸屬微服務架構的範疇。Service Mesh 是提供微服務的一種多語言、無依賴的解決方案。Serverless 是提供微服務的一種簡化開發、自動化運維、資源分時複用的解決方案。

Service Mesh 和流式程式設計架構都是很好的方向，阿里集團裡也有其它團隊在做這方面事情。

但是站在我們團隊的角度來看，這些都是尚未經過大規模生產叢集驗證的架構，而 Spring Cloud Alibaba 裡面整合的這些元件都是在阿里內部經過多年雙 11 檢驗的。

說到底，技術還是要為業務服務的，所以我們將這套技術整合到 Spring Cloud 生態，方便開發者更好更快地開發業務，業務永遠是最重要的。這是我們的想法。

具體到那篇文章中的觀點，我是這麼看的：

微服務是 SOA 的一種實現

SOA 是面向服務的架構，微服務也是面向服務架構的一種實現。如果引用微服務領域的先驅 Martin Fowler 的話，那麼“我們應該把 SOA 看作微服務的超集”。微服務是 SOA 的一種敏捷實現，之前 ESB 是 IBM 對 SOA 一種不太完美的實現，在微服務這個概念被 Martin Fowler 大神創造出來之前，阿里巴巴使用 Dubbo、HSF 實現了自己的微服務體系，其實也是 SOA 的一種實現。

微服務解決的本質問題是團隊分工

SOA 也好、微服務也好，解決的根本問題是團隊分工問題，詳見康威定律，這是大型軟體發展的必然，不因為人的喜好而改變。當你讀懂康威定律，就會發現“服務拆分粒度難以準確把握”根本不是本質問題。

你有幾個 2 pizza 團隊，最好就拆成幾個微服務。舉一個現實的例子：只有一個開發人員時，儘量就做單體應用，不要沒事找刺激拆成 10 個微服務，最終這個開發人員還會把他合成一個。微服務要求縱向的 2 pizza 團隊（無數個小團隊，包含開發、測試、運維），當然我們也實施過一些傳統大型企業，但團隊還是處在橫向結構的場景下（開發、運維、測試各是一個團隊），拆分微服務讓他們很痛苦，尤其是運維團隊。

微服務帶來挑戰是分散式下開發、測試與運維的複雜性

永遠不會有銀彈，但是我們要接受歷史的潮流，並且適應它。微服務的出現解決了團隊分工問題，同時也會引入新的問題，但是並不是“基礎設施的龐大複雜”。

EDAS 其實已經提供了大部分“基礎設施”。微服務跟開車一樣，車（基礎設施）我們可以不去造，但是學會開車（微服務理念）是對單體應用開發、測試與運維最大的挑戰。例如：單體應用開發者從來不會去想方法呼叫會失敗、會重試、要冪等；單體應用測試人員不會去想幾十個應用我怎麼一起整合測試；單體運維人員不會去想下游應用掛了對我有什麼影響。意識到分散式下開發、測試與運維的複雜性，並掌握解決這些複雜問題的方法，才是更主要的。

微服務至少還能活 18 年

當然不能因為微服務存在問題，我們就說它將死。很多人說 Java 將死，從 2000 年就聽說過這個論調，18 年過去了 Java 還活著，而且最近還搞得風生水起。

談到微服務將死，那麼這裡聯絡一下 Java，我認為微服務至少還要活 18 年，並且它也值得我做一輩子，我們會提供完善的基礎設施（車），提供完善的最佳實踐（教練），幫助開發者享受微服務（開車）帶來的好處。

下一代架構是 Serverless

此處提到的 Serverless != FaaS，Serverless 包含底層中介軟體的 Serverless 及服務本身 Serverless，而 FaaS 只是其中一種比較簡單的實現。那篇文章中提到的 Flink 跟 FaaS 實際上並無本質區別，但是本身商業化比 FaaS 差得比較大。

針對文中各個“流式架構優勢”論證點的具體分析如下：

原文：服務端開發人員無需再關注系統效能，Slink 叢集可以用容器動態擴容，Slink 叢集也可以動態調整某個業務的節點數量。

效能是開發人員必須關注的指標，開發人員只是不需要關注節點擴縮，FaaS 做得更好，甚至可以做到無流量時節點不駐留。

原文：服務端開發人員無需再關注系統可靠性，Slink 叢集管理每個節點，包括排程、重啟、狀態管理等。

FaaS 節點的自動故障轉移。

原文：服務端開發人員無需再考慮系統拆分，因為系統已經拆分到單條業務的粒度了，業務發展和變化，不會導致架構變化，只需要調整業務處理流圖就可以了。

理想很豐滿，現實很骨感，阿里有個團隊嘗試了 FaaS 之後，馬上退回去了，複雜業務邏輯不是拖拽那麼簡單就可以解決。單體應用的程式碼理論上也可以寫成無數個小方法，拖拽一下就可以了，目前小部分銀行系統小部分邏輯是這樣實現的，但是為什麼不能大規模推廣？這是業務複雜性或多變性導致的，所以 FaaS 也很難成功。FaaS 所謂的方法級別的拆分，本質跟微服務介面 API 定義無本質區別，所謂的編排，目前看只適合於簡單業務邏輯的控制。

原文：Slink 可以支援多個業務執行，資源可以做到最大程度的共享。

FaaS 可以做到不執行的邏輯不載入，做到分時複用，Flink（Slink） 做不到。

原文：幾乎大部分中介軟體，例如訊息佇列、全鏈路跟蹤、配置中心、降級系統等都可以去掉，Slink 平臺可以內建這些功能。

AWS FaaS 底層已經提供了 Serverless 的各種服務，目前看 Flink 並未提供。

原文：運維基本上維護 Slink 平臺即可，業務無需運維維護。

AWS FaaS 不需要維護，AWS 會幫你維護。

原文：Slink 可以支援多語言，不再要求服務端開發統一技術棧。

FaaS 可以是任意語言，已經商業化。

總結一下，實際上 Serverless 解決的本質問題是以下幾個方面：

 ●  運維複雜性
 ●  開發複雜性
 ●  資源的分時複用

Serverless 雖未完全解決開發複雜性、測試複雜性，但足以成為下一代架構。Serverless 開發基礎還是微服務，Java 開發人員還是會繼續使用 Spring Cloud，可以認為 Serverless 是微服務的有益補充。

另一方面，我認為，不管什麼架構，雲端計算終將統治整個服務端架構。

我們可以看到，現階段雲端計算已經解決了 IaaS 層的問題，現在初創公司起步的時候，都習慣在雲上直接購買機器，不會再選擇傳統的找機房租機櫃的形式，省去了一大堆煩惱，極大地提高了效率，同時經濟成本更低。

再往上層看，資料庫這個層面，比如人們已經習慣購買雲上的 RDS，開發者無需關心分庫分表，也不需要專業的 DBA 進行資料庫運維，因為 RDS 後端已經自動處理分庫分表和水平擴容，並且有專業的資料庫人員幫忙運維和保證 SLA，只需要根據使用量按量付費即可。

但是在 PaaS 層和 SaaS 層我們做的還不夠好，我們希望在不久的將來，中介軟體能力也能直接在雲上輸出，那時候微服務的開發者們無需再關心如何部署運維服務註冊中心、配置中心、訊息佇列服務，只需要使用標準的程式設計模型，開箱即用，這可以最大化地提升開發效率，快速實現業務變更和推進。

對於開發者普遍擔憂的開源專案後續維護情況，有什麼計劃？

從一開始就放在 Spring Cloud 孵化器裡已經表明我們對開源的態度，社群生態前期雖然是阿里巴巴主導，但是我們非常歡迎更多人一起參與進來，一起把這個專案建設得更好，無論是大的 feature，還是小的 bug，甚至是文件的糾正和完善，都能對這個開源專案產生很大的幫助。

接下來我們會整合開源的 Dubbo、RocketMQ，阿里雲上 ARMS、SchedulerX、SMS、VMS、SLS 等元件。隨著阿里開源力度的不斷加強，我們還會接入包含分散式事務在內的更多開源元件。

Spring Cloud Alibaba 將在明年 2 月釋出第一個 GA 版本，於 Spring Cloud H 版本從孵化器畢業。

原文釋出時間為：2018-11-28

本文來自雲棲社群合作伙伴“Java雜記”，瞭解相關資訊可以關注“Java雜記”。