Spring Cloud Alibaba 開源背後的故事 | 開源中國專訪

本文系開源中國對 Spring Cloud Alibaba 項目組的專訪，首發于開源中國，阿裡巴巴中間件授權轉載。受訪嘉賓是Spring Cloud Alibaba 項目組負責人 姬望。

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

據介紹，Spring Cloud Alibaba 由阿裡開源元件和阿裡雲産品元件兩部分組成，其緻力于提供微服務一站式解決方案，友善開發者通過 Spring Cloud 程式設計模型輕松開發微服務應用。

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

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

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

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

• 中國 Java 開發者的福音
• 微服務架構領域的新選擇
• Dubbo 與 Spring Cloud 不是競争關系
• 下一代架構不是流式架構，而是 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 有以下特性：

• 輕量級、高性能
• 多樣化的流量控制政策
• 系統負載保護

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 的出現，也會讓這個圈子産生不小的化學反應。

有人要問，阿裡這樣搞，那同樣深耕微服務領域的 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 版本從孵化器畢業。

嘉賓介紹

姬望（彭文傑），阿裡巴巴中間件進階技術專家，前微課網 CTO，前衛生部考試系統總架構師，專注于微服務領域，曾擔任 EDAS 産品開發 TL，目前負責 Spring Cloud Alibaba 開源。