點擊右上方，關注開源中國OSC頭條號，獲取最新技術資訊
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 版本從孵化器畢業。
嘉賓介紹
姬望（彭文傑），阿里巴巴中間件高級技術專家，前微課網 CTO，前衛生部考試系統總架構師，專注於微服務領域，曾擔任 EDAS 產品開發 TL，目前負責 Spring Cloud Alibaba 開源。
Spring Cloud Alibaba 團隊包含 6 名成員。阿里中間件擁有 Apache Dubbo、Apache RocketMQ 等頂級開源項目；支持世界最大最複雜的電商交易場景——雙11；有基於每天萬億次調用的數據智能決策系統。
開源社區OSC頭條號，每日推送最新優質的技術類文章，涵蓋外文翻譯，軟件更新，技術博客等優質內容。關注開源社區OSC頭條號，每日獲取最新技術資訊，點擊“瞭解更多”閱讀原文章。
相關推薦
