頭圖.png

作者 | 陳曦（良名） Spring Cloud Alibaba 專案成員，start.aliyun.com 負責人。

導讀：本文整理自作者於 2020 年雲原生微服務大會上的分享《進擊的 Spring Cloud Alibaba —— 框架與服務》，主要闡述了雲原生環境下，Spring Cloud Alibaba 如何幫助開發者實現微服務；以及在提供 SCA 開發框架基礎之上，如何配合更豐富的服務來幫助開發者在阿里雲上實現微服務。

阿里巴巴雲原生公眾號後臺回覆 818 即可獲取直播回看地址和大會 PPT 合集。

Spring Cloud Alibaba 微服務框架

1. Spring Based Framework 已經成為事實標準

根據 Jakarta 2019 年的調研報告，Spring Boot 擁有非常高的佔比。熟悉 Java 語言的同學，應該對 Spring 框架都不會陌生。其倡導的依賴倒置、面向切面程式設計等特性已經形成了 Java 語言的事實標準，幾乎所有三方框架都會提供對 Spring 框架的支援。

根據 JetBrings 2019 年的調研報告，61% 的使用者會選擇 Spring Boot 來代替傳統的應用伺服器。

這裡有一個很有意思的點，為什麼要“代替應用伺服器”呢？回顧前面雲原生的特點，我們要彈性，要自包含，要獨立程式等等。如果此時部署應用還需需要啟動應用伺服器會將整個依賴層級複雜化。同時，雲原生的各種彈性與排程能力，都同傳統的應用伺服器存在重疊。直接使用 Spring Boot 作為應用啟動入口就成為更加“雲原生”的選擇。

回到微服務&雲原生這個場景的下，Spring 提供用來支援開發工作的框架就是 Spring Cloud。

2. Spring Cloud 以微服務為核心的分散式系統構建標準

同樣，還是先看下 Spring 是如何定義 Spring Cloud 這套框架的：

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.

這裡提到了兩個關重要特徵：

分散式系統中的常見模式
任何分散式環境

“分散式系統中的常見模式”給了 Spring Cloud 一個清晰的定位，即“模式”。也就是說 Spring Cloud 是針對分散式系統開發所做的通用抽象，是標準模式的實現。這個定義非常抽象，看完之後並不能知道 Spring Cloud 具體包含什麼內容。再來看一下 Spring 官方給出的一個 High Light 的架構圖，就可以對這套模式有更清晰的認識：

可以看到這個圖中間就是各個 Microservice，也就是我們的這個微服務的實現，周邊周圍的話就是去圍繞這個微服務來去做各種輔助的資訊事情。例如分散式追蹤、服務註冊、配置服務等，都繞微服務執行時所依賴的必不可少的的支援性功能。我們可以得出這樣一個結論：Spring Cloud 是以微服務為核心的分散式系統的一個構建標準。

3. Spring Cloud Alibaba 的定位

既然說 Spring Cloud 是標準，那麼自然少不了針對標準的實現。這裡，為大家介紹下 Spring Cloud Alibaba 這套實現。先給出下面這張圖幫助大家理解 Spring Cloud Alibaba 的定位：

這裡給大家這麼一個公式，這個叫做：“3 加 2”。

3 指的就是圖中深色的部分，其實它就是 Spring Cloud 標準，一共有 3 層。中間顏色最深的部分就是及整個微服務最核心的內容，包括了“ RPC 呼叫”以及“服務註冊與發現”。第二層，也就是圍繞著核心的這一圈，是一些輔助微服務更好的工作功能，包括了負載均衡、路由、閘道器、斷路器，還有就是追蹤等等這些內容。再外層的話，主要是一些分散式雲環境裡通用能力。

“3 加 2”中的“2”，指的就是上圖中最外面這一圈。這一部分就是這個我們 Spring Cloud Alibaba 的一個定義，它其實包含兩個部分的內容：

右上部分是對於 Spring Cloud 標準的實現。例如，我們通過 Dubbo 實現了 RPC 呼叫功能，通過 Nacos 實現了“服務註冊與發現”、“分散式配置”，通過 Sentinel 實現了斷路器等等，這裡就不一一列舉了。

左下部分是我們 Spring Cloud Alibaba 對阿里雲各種服務的整合。可能很多同學會有這樣的一個問題：為什麼要加上這一部分呢？此時回頭審視一下 Spring Cloud ，它僅僅是一個微服務的一個框架。但是在實際生產過程中，單獨使用微服務框架其實並不足以支撐我們去構建一個完整的系統。所以這部分是用阿里幫助開發者完成微服務以外的雲產品整合的功能。

這裡可能會很多同學會有這麼一個擔心：是不是使用了 Spring Cloud Alibaba，就會被阿里雲平臺繫結呢？在此，我們明確的告訴大家，這是不會的。為什麼這麼說呢？如上面說的，“3 加 2”中的 2 是被分為兩個部分的。其中對 Spring Cloud 的實現是完全獨立的，開發者可以只是用這部分實現執行在任何雲平臺中。當然，另一部分，由於天然是對阿里雲服務的整合，這部分是和平臺相關的。這裡給開發者充分的自由，選擇只是用其中的部分還是全部產品。當然，我們也非常歡迎開發者選擇使用阿里雲的全套服務，我們也會盡量保證使用整套產品時的連貫性與開發的便利性。

4. Spring Cloud 各套實現對比

Spring Cloud 作為一套標準，它的實現肯定不止一套，那麼各套實現都有什麼區別呢？我們來一起看一下下面這張圖：

可以發現 Spring Cloud Alibaba 是所有的實現方案中功能最齊全的。尤其是在 Netflix 停止更新了以後，Spring Cloud Alibaba 依然在持續更新和迭代。

從 18 年 7 月份 Spring Cloud Alibaba 正式提交程式碼開始，就得到了大家廣泛的關注。截止今天，Spring Cloud Alibaba 一共獲得了超過了 1.5 萬的 star 數，已經的領先於所有其他實現的總和。

根據今年 X-lab 開放實驗室剛剛釋出的《2020 年微服務領域開源數字化報告》，Spring Cloud Alibaba 已經成為最活躍的 Spring Cloud 實現。

資料來源《2020 年微服務領域開源數字化報告》，公眾號後臺回覆關鍵詞“微服務報告”獲取報告全文。

5. Spring Cloud Alibaba 生態

作為一個雲廠商，我們提供的服務是非常豐富的。可以看到除了圍繞著 Spring Cloud 的標準實現以外，還有包括的資料、資源、訊息、快取等各種型別的服務。在不同型別的服務下，也有很多具體的產品可供使用者選擇。

這裡羅列典型而非全部產品。更多的內容，可以參考阿里雲官網

6. Spring Cloud Alibaba 使用者數

截止到今天，Spring Cloud Alibaba 獲得了數超過 1.5w 的 star 數。同時在 Github 上的專案依賴，就是對 Spring Cloud Alibaba 產生依賴關係的產品，也超過了 6000。最重要的，使用 Spring Cloud Alibaba 的公司超過 1000 家。當然不只是外部的公司在使用，我們自己其實也在使用。那經過了雙十一的洗禮，其實整個這套框架它的這個穩定性可靠性都得到了印證。

從框架到服務

1. 提供開發者服務，更完整的 Java 開發體驗

作為一套框架，Spring Cloud Alibaba 為開發者提供了便捷的程式設計模型，但是從開發者完整的工作流程上看，是不是還缺點什麼？設想一下這樣一個場景：作為一個開發者，應該說都做過這樣的一個事情，就是從頭從零開始去構建一個工程，一直到功能開發這麼一個過程的一個過程：

從設計到功能開發，是一個比較長的一個週期的：先要做抽象設計，包括概要設計、架構設計等；然後是一些具象的設計，還有各種框架搭建與架構驗證等工作。

在抽象設計階段，我們要確定整體的架構模式，包括了微服務、Serverless、事件驅動等。以及在這些架構模式下各個應用的領域邊界劃分。

在具象設計階段，我們要確定諸如應用分層、分包規則的。這裡也有很多的標準可以參考：MVC 分層架構、DDD 領域驅動設計架構等等。在此之後，還有具體的業務模型與介面設計，這些暫不在本文的討論範圍之內。

在實現階段，需要引入各種框架，並通過配置將這些框架與應用整合起來，完成工程骨架的建立。

最後，還需要將這套骨架執行起來以驗證其可行性。

所有上面的工作完成以後，才可以正式的開始業務邏輯實現工作。

在上面的流程裡，Spring Cloud Alibaba 能起到的作用是有限的。作為一套框架，為開發者帶來的是程式設計模型上的便利。為了能讓開發者更加輕鬆的完成這一系列流程，我們為大家帶來兩個重要的產品：“Java 工程腳手架”和 “Sandbox 雲沙箱”。

2. Java 工程腳手架：更適合亞太區 Java 開發者的腳手架

很多開發者應該跟我一樣，都有過這樣的經歷：建立新應用時，先找一個我們最熟悉的一個老應用，把它裡邊的業務程式碼全部清理乾淨。然後相關的各種配置名稱全部改掉，最終做出一個空的一個應用模板。再把這個應用模板拿過來改個名子，就變成了一個新的應用。

當然可能有的同學會做的更多一些，例如長期維護這麼一個空白模板在那裡。下次拿過出來之後再改改個名字，就是一個新的應用。

這樣做可能是一個相對保險的方案，但是缺點也非常明顯：

版本老舊，新特性無法享受
團隊知識無法沉澱
重複勞動

我們通過提供 Java 工程腳手架來解決這個問題。下面就是 Java 工程腳手架的頁面：

在這裡，開發者設定專案的基本資訊，例如：開發語言、Java 版本、Spring Boot 版本等內容。

除了基本資訊以外，這個平臺還提供多種架構模式可供選擇。在上圖中可以看到，第一個是分層架構，這個是一個很傳統的多層架架構模型，包括我們經常說的這種三層架構、五層架構。另一個架構選項是 COLA。COLA 其實是一個典型的一個 DDD 的架構，如果希望在自己團隊裡邊去實踐標準的六邊形 DDD 架構的話，也是可以去選擇他。未來我們可能會去做更多的例如說 MVC 架構，或者是事件驅動的架構模型，提供給大家。

最下邊是組價依賴部分，開發者可以在這裡選擇專案需要使用的元件。這裡的選擇非常豐富，到從資料庫到開發工具、訊息、web 等等，一共 100+ 的組價可供大家選擇，可以說基本上覆蓋了應用開發的所有方面。同時，這裡當然不會缺失 Spring Cloud Alibaba 提供的任何元件。

我們希望通過這個工具，儘量減少開發者在建立應用過程中各種查詢資料以及繁瑣的配置工作。只需要在平臺上做一些簡單的選擇，就可以將工程骨架生成完成。

在 Java 工程腳手架裡，除了直接在 WEB 平臺配置和下載工程，我們還提供了基於 IDE 的外掛，進一步方便使用者的使用。

經常光顧 Spring 的同學，應該對這個介面應該非常熟悉，這和 Spring 官方提供的腳手架非常相似。那麼我們的工程腳手架和 Spring 官方的實現有什麼區別呢？是不是就是對官方功能的映象呢？我們看一下下面的對比：

區別主要在如下幾個方面：

樣例程式碼 & 典型配置：Spring 官方其實是沒有這些樣例程式碼以及配置漏記的。在我們的實現裡，會新增這一部分，目前主要覆蓋了 Spring Cloud Alibaba 的元件，後面會繼續覆蓋更多的元件；
阿里雲元件支援：Spring 要保證平臺中立的特性，各廠商的元件自然是不會支援的，我們提供 Spring Cloud Alibaba 的全部開源元件和阿里雲平臺服務元件，同時也會把這些部分獨立出來，避免同其他部分的元件揉在一起，影響使用者選擇；
工具鏈：Spring 官方的實現裡，例如 IDEA 的外掛是專業版裡才有，也就是說這是收費的，我們使用 Cloud Tookits 外掛實現相關功能，並且完全免費，同時，我們的平臺 100% 支援官方外掛連結；
網路環境：Spring 官方服務部署在國外，國內訪問不穩定；
應用架構：這部分在官方實現裡是沒有的，也是我們未來會重點建設的部分，應用架構在實際生產過程中是不可或缺的。

這套本地化的腳手架也獲得了 Spring 官方佈道師 Josh Long 的推薦。我們會盡量延續 Spring initiliazr 的產品體驗，功能上我們只做增量，同時這個增量給使用者保留了充分的選擇的自由權益。就是說我們增加這個東西，你可以完全不要，此時整體上和官方提供的產品體驗是一模一樣的，這是我們整個產品的繼續發展會一直堅持的原則。

3. Sandbox 雲沙箱：免費、快速驗證雲產品

第二個服務產品，就是我們的 Sandbox 雲沙箱。我們來設想這樣一個場景：今天建立一個新的應用，在基礎骨架程式碼開發完成以後，需要去執行它，以驗證它的可行性或者是發現其中有沒有坑，此時定需要一個執行環境。我如果自己去搭建完整的後臺服務執行環境，要麼選擇從雲服務商購買，要麼自己本地搭建。這兩個選擇一個費錢、一個費力。

除了驗證新應用的架構，還有很多其他場景也會有類似的困難。例如，需要驗證一個雲服務產品的可行性，學習相關組價的使用等等。

那麼有沒有什麼更好的辦法呢？這就是 Sandbox 雲沙箱需要解決的問題。

這個產品有三個主要的特性：便捷、真實和免費。

便捷：我們為使用者準備了相關程式碼&開發環境&執行環境，只需要點點滑鼠就可以完成整個專案的建立，並部署在我們提供的隔離環境中，中間過程甚至不需要鍵盤；
真實：指的是整個產品非常貼近實際工作場景，從開發者角度看，整個專案研發流程，包括程式碼 checkout / checkin，開發工具，編譯流程、部署流程等，使用的都是真實生產流程；從執行時角度看，所有的底層服務使用的都是阿里雲提供的真實服務，沒有任何單獨定製的服務存在；
免費：所有的服務不會像使用者收取費用，甚至所有計費行為的發生，都不會跟使用者的賬號發生關聯。

這套產品支援完整的分散式場景。很多其他的廠商也有類似的產品，但是都只能提供基於單一容器或者主機的案例，這和實際環境中多應用的分散式環境是有差距的。而這個問題，在我們的沙箱產品裡是不用擔心的。開發者在應用部署後的專案有半小時的使用時間，同時流量&併發數等也會存在一定的限制。

下面來看一下產品的介面：

左邊是產品的手冊 & 說明部分。這裡會包含說當前專案的功能說明、應用架構，以及如何部署和訪問這些應用的操作步驟等。一些專案中使用到的技術點以及這些相關知識，也都會在這裡呈現給使用者。這部分文件的目的，就是方便使用者去學習和理解當前的案例。

右邊的部分是應用列表。在微服務場景下，一個完整的產品通常需要多個應用組成分散式的叢集協同工作。這裡就是用來陳列相關的應用列表，同時包含了針對這些應用的操作入口。

圖片中的案例是一個工作管理員產品，功能相對簡單。但是麻雀雖小五臟俱全。這個產品包含兩個應用：

一個服務端，的包含了這個工作管理員的所有業務邏輯，以及下層的持久化能力等；
一個 WEB 客戶端，包含了所有前端頁面邏輯、與前端通訊的控制器層。

這兩個應用通過一個註冊中心來實現服務的註冊&發現。最終實現一個完整的工作管理員產品。

點選“開發”按鈕，開啟一個 WEB-IDE 來檢視和修改對應應用的程式碼：

這個 WEB-IDE 和開發者日常使用的 IDE 是一樣的，都是左側程式碼樹，右側程式碼編輯器的標準佈局。即使是不熟悉這個產品的使用者，也可以非常快的上手，甚至不需要學習過程。如果需要部署這個應用，只需要在“運維”功能下，點選“部署”按鈕，此時只需要等待部署完成即可。在部署過程會有很多的日誌輸出，都可以通過“輸出”窗體瀏覽：

部署完成以後，會向 WEB-IDE 返回一個訪問地址，開發者只需要點選這和地址就可以訪問這個應用。下圖是實際的訪問效果。可以看到，兩個應用，一個是工作管理員的 web 操作頁面、一個是後臺資料庫管理頁面：

通過上面的步驟，開發者可以將案例快速部署起來。先部署試用，然後去學習和修改程式碼，最後再部署驗證。通過這樣的迴圈，可以讓開發者很快學習和理解案例的功能和相關技術點。

最後再看一下整個沙箱的系統架構流程以及一些關鍵點：

通過顏色，可以很清楚地看到，沙箱的資源被分為兩個部分。藍色的部分其實是使用者獨享的資源，包括了：私有程式碼倉庫、部署流程、執行環境等。這一部分在每個使用者間相互隔離。尤其是在右下角可以看到，完整的執行環境被隔離在獨立的專有網路中。如果是多個應用，這些應用都會連結再同一個網路裡邊。橙色的部分是公共的資源，這裡只有 2 個：案例程式碼倉庫和沙箱後臺服務。

第二組概念是：臨時資源和長期資源。

臨時資源，包括部署流程和執行流程在內。這些資源會在一段時間後會被銷燬，從而保證整個產品成本的可控，也避免部分使用者對這套產品的濫用。如果需要在資源釋放以後，繼續使用，只需要重新部署這個應用即可。長期資源的就是會長期存續的資源。可以看到，使用者的私有程式碼倉庫就是長期資源。也就是說，無論執行環境是否存續，使用者的程式碼都會一直得到保留。這部分程式碼，使用者可以隨時下載到自己本地，並在自己的環境中執行它們。

後續規劃

下面是今年，整個 Spring Cloud Alibaba 以及相關服務產品的整體規劃：

後續我們會基於 Sandbox 雲沙箱上線七天系列課程。通過這個基礎知識學習+實操來更好的掌握微服務的相關技術，尤其是對 Spring Cloud Alibaba 的使用。未來還會在沙箱中上線完整的電商商場的案例，包括具有高併發場景的秒殺案例。最後，對 Spring Cloud Alibaba 本身，也會繼續建設，整合不少於 20 種阿里雲中常用的雲產品。進一步提升開發便利性。

如果你對這個產品有進一步瞭解的興趣，或者是有什麼更好的意見或者建議，歡迎加入釘釘群（釘釘搜尋：34930571），一起來交流、吐槽。