文檔目錄
- Spring Cloud Alibaba七天訓練營（一）基礎知識篇
- Spring Cloud Alibaba七天訓練營（二）分布式配置
- Spring Cloud Alibaba七天訓練營（三）服務注冊與發現
- Spring Cloud Alibaba七天訓練營（四）分布式服務調用
- Spring Cloud Alibaba七天訓練營（五）服務熔斷和限流
- Spring Cloud Alibaba七天訓練營（六）分布式消息（事件）驅動
- Spring Cloud Alibaba 七天訓練營（七）分布式事務
前言
近些年随着雲技術的發展，越來越多的使用者選擇使用雲技術來代替将傳統的 IT 基礎設施。在雲技術發展的早期，業界的關注點集中在虛拟化、分布式、存儲等 Iaas 方面的技術。但是随着“雲原生”概念的提出，大家的注意力開始轉移到如何建構更加适合雲環境運作的應用上來。
“什麼樣的架構才是适合在雲環境中運作”是一個非常大的問題，在此先不展開讨論，而是到 CNCF 對雲原生的定義中尋找答案：
雲原生技術有利于各組織在公有雲、私有雲和混合雲等新型動态環境中，建構和運作可彈性擴充的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠建構容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
從上文的定義中可以發現“微服務”在雲原生技術中占有這非常重要的位置。在 jakarta.ee 2019 年的調研報告中也印證了這一點，超過40%公司選擇采用微服務架構來建構雲上系統：
讓我們繼續把視角聚焦到 Java 語言下。Pivotal 依托于 Spring 這個 Java 語言下程式設計模型的事實标準，結合大量業界經驗，為廣大 Java 開發者帶來了
Spring Cloud架構。該架構是對雲環境下微服務開發中需要解決的各種問題的标準化，以幫助開發者快速實作分布式系統中的某些常見模式（例如，配置管理，服務發現，斷路器等）。
同時，基于 Pivotal 強大的标準制定能力與影響力，Spring Cloud 擁有一個強大的國際化社群，阿裡巴巴作為設個社群裡重要的成員，也貢獻出了 Spring Cloud Alibaba 這套優秀的實作，這也是目前整個 Spring Cloud 體系下最完善并且在持續更新的實作方案。
學習目标
通過本次課的學習，你應該了解或掌握如下知識點：
- 微服務的發展曆程
- 微服務的基本形式
- Spring 、Spring Boot 、Spring Cloud 的職責與關系
- Spring Cloud Alibaba 的功能與定位
- Java 工程腳手架的使用方法
- Sandbox 沙箱環境的使用發方法
理論篇
俗話說，沒有最好的架構，隻有最合适的架構。微服務架構也是随着資訊産業的發展而出現的最有普遍适用性的一套架構模式。通常來說，我們認為架構發展曆史經曆了這樣一個過程：單體架構 -> SOA 面向服務架構 -> 微服務架構。
單體架構
在我們還是學生的年代，我們建立的絕大部分應用都屬于單體應用。那個時候，我們幾乎都是一個人在開發導師布置下來的各種實驗。我們會把資料庫連接配接、業務邏輯處理、展示邏輯等放在一起，甚至會在處理使用者請求的地方直接連接配接資料庫（多麼美好的回憶啊 ^_^ ）。
後來，我們會學習到MVC架構以及由此衍生出來各種多層架構，由此便開啟了應用的拆分之旅。多層架構的本質，是按照技術職責将應用做水準拆分，每一層解決的技術問題相對集中，層與層之間做單向依賴。這樣做可以幫助我們更好的管理我們的代碼，大大提升了後期的維護效率。但是，此時應用還是一個應用，部署時也是按照一個整體運作。我們看到的應用架構應該類似下面的樣子：
在程式規模不大，開發人員很少的時候，下面的有點是非常顯著的：
- 開發簡單。單體應用的結構，天然決定了所有代碼都集中在一起，開發者不需要在多個應用之間來回跳轉來尋找其中的調用邏輯。
- 測試簡單。所有代碼都在一個應用裡，測試人員可以很友善的做到端到端的測試（當然，很多時候測試人員就是開發者自己）。
- 部署簡單。因為一個應用就是産品功能的全集，是以在部署的時候，隻需要不是一款應用即可。即使是叢集部署，也不會增加多少複雜度：隻需要将應用部署多份即可。
- 開發迅速。上面的各種簡單，帶來的就是軟體功能可以快速實作。很多時候，實作需求的速度是項目成功與否的決定性因素。
是以，在開發簡單&獨立的産品時，單體架構依然是第一優先選擇。
如果故事可以一直這麼簡單就好了。
随着功能的持續增加、團隊規模的不斷擴大，我們很快就會發現單體應用的弊端：
- 應用膨脹。所有代碼都在一個應用裡，導緻應用的代碼量迅速上升，對于開發者來說，經常需要在海量的代碼裡找到自己需要維護的哪一行，這種體驗往往是令人崩潰的。同時，對于IDE來說，一個應用内大量代碼也會嚴重拖慢其運作效率。
- 團隊合作沖突。這種沖突會展現在多個方面：開發階段，很容易由于修改相同的代碼導緻代碼沖突。部署階段，又會因為“運作環境裡跑的是誰的分支”而造成新的沖突。所有的這些沖突将會嚴重影響到團隊的合作效率。
- 運作效率&穩定性。單體應用，由于邏輯都集中在一起，啟動時需要完成所有的初始化工作；同時單一功能的問題也會因為運作在一個程序内，進而導緻整個應用當機。
單體架構原有的迅速、簡單的優點，随着規模的擴大（功能、團隊），會變得蕩然無存。
為了能解決這些問題，我們自然而然就會想到分而治之的辦法，即将原來的單體應用拆分開來。但是應用該怎麼拆分？拆分後又會有哪些新的問題産生？如何解決這些新的問題？就留給下面的 SOA 架構來解答。
SOA 架構
SOA 是 Service-Oriented Architecture 的簡寫，直譯為“面向服務的架構”，從命名上就可以看出“服務”是 SOA 架構裡是非常重要的概念。SOA 的核心思想是“将系統的功能解構為一系列服務”：
面向服務的架構（SOA）是一個元件模型，它将應用程式的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和協定聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得構件在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
與單體架構按照技術職責進行水準拆分不同，SOA 會按照業務領域對應用進行粗粒度的垂直拆分，至于拆分到什麼程度，哪些領域可以放在一起等類似問題，可以參考一下康威定理。
應用從單體應用做了垂直拆分以後，就會變成一些相對獨立的應用。此時，應用間的依賴、調用等相關問題自然而然的就會浮現出來。此時就需要下面這些技術方案來解決這些問題：
- XML - 一種标記語言，用于以文檔格式描述消息中的資料。
- SOAP（Simple Object Access Protocol） - 在計算機網絡上交換基于XML的消息的協定，通常是用HTTP。
- WSDL（Web Services Description Language，Web服務描述語言） - 基于XML的描述語言，用于描述與服務互動所需的服務的公共接口，協定綁定，消息格式。
- UDDI（Universal Description, Discovery, and Integration，是統一描述、發現和內建） - 基于XML的注冊協定，用于釋出WSDL并允許第三方發現這些服務。
- ESB（Enterprise Service Bus, 企業服務總線）- 支援異構環境中的服務、消息，以及基于事件的互動，并且具有适當的服務級别和可管理性。
一個典型的 SOA 架構模式如下圖：
SOA 看似解決了單體架構的所有問題，世界似乎都變得更加美好了 ^_^
但是….
SOA 并不完美，他也有很多問題的或者說是場景下的不适應。首先就是對 SOA 的解釋缺乏統一标準，上文的引用的定義也隻是衆多解釋中使用的較為通用的一種。甚至可以這麼說：一千個人眼中，有一千種 SOA 。基于此，很多廠商便借用 SOA 的大旗來推廣自己的産品和标準，這又進一步加劇了問題的嚴重性。
除此之外，SOA 還有很多其他的問題或不足：
- 高門檻。ESB 本身就是一套非常複雜的系統，通過 ESB 落地 SOA ，對開發人員的要求很高。甚至還會需要廠商參與；
- 廠商綁定。由于缺乏統一保準，不同廠商的解決方案之間很難做切換。
- 不适應雲環境。在如今的網際網路時代，速度就是一切。由此誕生了靈活開發、持續內建等在不同節點提升業務上線速度的辦法。但是方向是不一緻的。
- 中心化。雖然應用本身實作了分布式與水準擴充，但是 ESB 卻成了系統的中樞神經。
微服務架構
對于微服務架構，一直有一種說法，認為它是 SOA 架構的一種變體，或者是 SOA 的子集。關于這個問題，我們不去讨論他的對錯（其實也沒有對錯之分），我們直接從這兩者的差別入手來了解到底什麼是微服務：
| 傳統SOA | 微服務 | |
|---|---|---|
| 通信方式 | 基于ESB，SOAP、WSDL等重協定 | 點對點通信，開放式協定，如 RESTful、gRPC、或者是輕量級的二進制協定。 |
| 資料管理 | 全局資料模型以及共享存儲 | 每個服務獨立模型和存儲 |
| 服務粒度 | 較粗 | 較細 |
| 誕生的背景 | 企業級應用 | 網際網路 |
| 解決的問題 | 面向企業内，系統內建 | 面向最終産品，解決擴充，維護的問題 |
通信手段、資料等的不同隻是表象，其本質差別還是由于兩者誕生于不同曆史時期，需要解決的問題域不同。SOA 解決的核心問題是複用，而微服務解決的核心問題是擴充。
關于什麼是微服務，Martin Fowler 有如下的定義（更多 MartinFowler 關于微服務的内容，可以參考
連結）：
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.?
這裡提到幾個重要的概念：
- 一套小服務
- 獨立程序
- 輕量級通信協定
- 可獨立部署
- 多語言&不同儲技術
這個定義對微服務做了一個比較具象化較為易于了解的描述，通常來說我們看到的為服務架構如下圖所示：
但是事實上，在實際生産環境中，微服務的架構要考慮的問題遠比上面的示意圖複雜的多，主要包括但不限于如下問題：
- 通過服務實作元件化
- 根據業務組織系統
- 做産品而不是做項目
- 簡單高效的通信協定
- 自動化基礎設施
- 面向失敗的設計
- 具備進化能力的設計
縱然有 Martin Fowler 這樣的大神在前面引路，但是我們依然認為“微服務”不是一個被設計出來的架構，而是在不斷是嘗試中總結出的一套适合在網際網路行業使用的架構模式。以下的是微服務較為完整的架構圖（出自
微服務架構模式）
今天我們所說的“微服務”是一個龐大且複雜的概念集合，它既是一種架構模式，也是實作這種架構模式時所使用的技術方案的集合。
“微服務”不是銀彈
微服務并不是一勞永逸的解決了所有的問題，相反的，如果不能正确的使用微服務，則有可能被微服務自身的限制拖入另一個泥潭：
- 分布式的代價。原本在單體應用中，很多簡單的問題都會在分布式環境下被幾何級的放大。例如分布式事務、分布式鎖、遠端調用等，不光要考慮如何實作他們，相關場景的異常處理也是必須要考慮到的問題。
- 協同代價。如果你經曆過一個項目上線需要釋出十幾個應用，而這些應用又分别由多個團隊在維護。你就能深刻的體會到協同是一件多麼痛苦的事情了。
- 服務拆分需要很強的設計功力。微服務的各種優勢，其中一個重要的基礎是對服務領域的正确切分。如果使用了不合适的切分粒度，或者是錯誤的切分方法，都會讓服務不能很好的實作高内聚低耦合的要求。
架構篇
從 Spring 到 Spring Cloud
Spring
熟悉 java 語言的同學，對 Spring 架構應該都不陌生。從 2004 年 1.0 版本釋出開始，便由于其靈活易用的特性受到了整個 Java 行業的廣泛關注。經過十多年的發展，Spring 架構早已經成為 Java 語言下程式設計模型的事實标準。其所倡導的 IOC/AOP 概念也早已深入人心。
在 Spring 架構的早期，大家都喜歡稱其為“輕量化”架構（現在好像早就沒人提這個詞了^_^），“輕量”是相對于 EJB 等企業級開發架構而言的。其“輕”的特性展現在：架構本身的大小很小，早期版本的jar包不超過1MB；同時不依賴于運作容器，也是說任何容器裡都可以運作Spring架構；更加重要的是 Spring 是非侵入的，使用Spring開發的應用可以不完全依賴Spring的類；
Spring Boot
但是事情總會發生變化，随着 Spring 的不斷發展，越來越多的元件被內建到了架構中。Spring 架構也從一個小巧精簡的 IOC 容器架構變成了一套大而全的架構集合。開發者為了實作元件的整合工作，往往需要在大量的 xml 檔案、java 注解 中完成各種 bean 的配置。曾經屠龍的少年，如今也變成了惡龍。
那個時候，很多比 Spring 更加簡單小巧的 IOC 容器如雨後春筍般的出現。業界開始出現一種聲音：Spring 是不是已經不行了，或者是在走下坡路了。就在這個時候 Pivotal 推出了 Spring Boot 來徹底的解決這些問題。
使用 Spring Boot 可以大大簡化 Spring 應用的開發工作。在 Spring Boot 中無論是官方元件還是第三方架構都會提供各種“starter”來友善開發者進行依賴和內建。由于采用了“約定大于配置”的思想，開發者在引入“stater”以後隻需要做少量的配置工作就可以完成架構內建工作。往往開發者隻需要很少量的代碼就可以實作以前大量配置檔案才能做到的功能。
同時 Spring Boot 還是一套面向生産環境設計的架構。配置外化、運作情況檢查功能，可以很友善的在系統外部實作對系統的管理。同時 Spring Boot 還是一個運作時容器。通過内嵌 Tomcat 、Jetty 等使得程式的運作不在依賴傳統的應用伺服器。這一點在雲原生時代意義尤其重大。
Spring 官方對 Spring Boot 特色定義如下：
- 建立獨立的Spring應用程式
- 直接嵌入Tomcat，Jetty或Undertow（無需部署WAR檔案）
- 提供自以為是的“starter”依賴項，以簡化建構配置
- 盡可能自動配置Spring和三方類庫
- 提供可用于生産的功能，例如名額，運作狀況檢查和外部化配置
- 完全沒有代碼生成，也不需要XML配置
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 是以微服務為核心的分布式系統的一個建構标準。
Spring Cloud Alibaba
既然說 Spring Cloud 是标準，那麼自然少不了針對标準的實作。參與這個标準實作的公司有很多，例如：Google 的 Spring Cloud GCP，Netflix 的 Spring Cloud Netflix，Microsoft 的 Spring Cloud Azure 等等。當然還有我們阿裡巴巴的 Spring Cloud Alibaba。
Spring Cloud Alibaba 從 19 年初開始送出代碼就獲得了業界的廣泛關注，從下面這張圖中可以看到，在很短的時間之内，Spring Cloud Alibaba 就成為了 Spring Cloud 家族中最受關注的架構：
下面這張圖很好的說明了 Spring Cloud Alibaba 的組成以及與 Spring Cloud 的關系：
圖中深色的部分，其實它就是 Spring Cloud 标準，一共有3層。中間顔色最深的部分就是及整個微服務最核心的内容，包括了“ RPC 調用”以及“服務注冊與發現”。第二層，也就是圍繞着核心的這一圈，是一些輔助微服務更好的工作功能，包括了負載均衡、路由、網關、斷路器，還有分就是追蹤等等這些内容。再外層的話，主要是些分布式雲環境裡通用能力。
最外面這一圈，是 Spring Cloud Alibaba 對 Spring Cloud 的實作。右上部分是對于 Spring Cloud 标準的實作。例如，我們通過 Dubbo 實作了 RPC 調用功能，通過 Nacos 實作了“服務注冊與發現”、“分布式配置”，通過 Sentinel 實作了斷路器等等，這裡就不一一列舉了。左下部分是我們 Spring Cloud Alibaba 對阿裡雲各種服務的內建。可能很多同學會有這樣的一個問題：為什麼要加上這一部分呢？此時回頭審視一下 Spring Cloud ，它僅僅是一個微服務的一個架構。但是在實際生産過程中，單獨使用微服務架構其實并不足以支撐我們去建構一個完整的系統。是以這部分是用阿裡幫助開發者完成微服務以外的雲産品內建的功能。
為什麼要分成兩個部分呢，這也是為了打消大家對于使用了 Spring Cloud Alibaba 以後就會被平台綁定的擔憂。雖然在品牌商都叫做SpringCloudAlibaba，但是在代碼上，我們采用了兩個獨立的項目維護。分别是
和
Aliyun Spring Boot目前，Spring Cloud Alibaba 包含如下元件：
開源部分
- Sentinel：把流量作為切入點，從流量控制、熔斷降級、系統負載保護等多個次元保護服務的穩定性。
- Nacos：一個更易于建構雲原生應用的動态服務發現、配置管理和服務管理平台。
- RocketMQ：一款開源的分布式消息系統，基于高可用分布式叢集技術，提供低延時的、高可靠的消息釋出與訂閱服務。
- Dubbo：Apache Dubbo? 是一款高性能 Java RPC 架構。
- Seata：阿裡巴巴開源産品，一個易于使用的高性能微服務分布式事務解決方案。
平台服務部分
- Alibaba Cloud OSS: 阿裡雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿裡雲提供的海量、安全、低成本、高可靠的雲存儲服務。您可以在任何應用、任何時間、任何地點存儲和通路任意類型的資料。
- Alibaba Cloud SchedulerX: 阿裡中間件團隊開發的一款分布式任務排程産品，提供秒級、精準、高可靠、高可用的定時（基于 Cron 表達式）任務排程服務。
- Alibaba Cloud SMS: 覆寫全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。
工具篇
Java 工程腳手架
Java 工程腳手架，用于幫助開發者快速生成工程骨架。解決開發者在建立工程時的元件引入、解決版本依賴、基礎配置、查詢樣例代碼等繁瑣問題。隻需要簡單的點點滑鼠，就可以生成一套标準工程骨架。
腳手架的通路位址是
https://start.aliyun.com/bootstrap.html, 打開後頁面見下圖：
編譯架構、坐标&名稱、其他基礎資訊等，根據實際情況按需填寫。當然，很多參數預設值就可以滿足大部分需求。開發者重點關注的是下面3個部分：
元件依賴
很少有開發者會使用語言最原始的sdk來實作所有功能。通常來說，大家都會使用各種技術産品的進階封裝來實作相關的技術特性。這裡就需要做2件事情：引入對應元件的sdk、在應用中配置元件。而通過Java 工程腳手架就可以很輕易的完成這些工作。
Java 工程腳手架中提供了 2 種尋找元件的方式：根據分類浏覽&關鍵字搜尋
這裡根據元件分類尋找需要使用的元件:
也可以根據元件的關鍵字直接使用搜尋功能尋找需要使用的元件：
無論通過哪種方式，都可以通過元件右側的加好實作元件的選擇。
應用架構
在生成的工程裡，代碼需要根據其邏輯職責進行分層，進而獲得更好的代碼組織與管理效果。在這裡提供了3種應用架構供開發者選用。
- None：不做任何代碼分層。
- 分層架構：标準的4層架構。分為 WEB層、控制器層、服務層、持久化層。本架構參考了 《Java 編碼規約》 的 應用分層 章節。
- COLA：領域驅動設計（DDD）的實作架構之一。采用了标準的六邊形架構設計，并且輔之以一套靈活的擴充體系，可以有效提升複雜業務系統開發的效率。具體參考 COLA 的 GIthub工程
示例代碼
我們為元件準備了很多使用方法的參考樣例，這樣開發者就不需要選擇外元件以後，再去别的搜尋引擎尋找相關元件的使用方法了。
未選擇任何元件時，是不會給出任何示例代碼的。示例代碼是在選擇了元件依賴以後，才會出現于使用者選擇的元件相關的示例，如下圖：
由于很多案例自身也依賴其他元件，是以在選擇了某個案例以後，會多出一些案例，同時依賴的元件也會增多。
本次課程使用到的案例，都可以在這裡尋找到。
生成代碼
僅僅完成項目配置是不夠的，最終開發者需要的是項目的代碼。so, show me the code
無論是出于查閱元件用法的目的，還是出于需要工程完整代碼的目的，腳手架都可以很好的支援：
如果僅僅需要查閱代碼，而不是下載下傳完整工程，可以直接通過點選“浏覽代碼”來實作。點選該按鈕以後，會打開一個包含了完整代碼樹以及允許檢視每個檔案的内容視窗：
如果需要擷取所有代碼内容，則可以通過點選“擷取代碼”來實作：
這裡提供了2種擷取代碼的途徑：直接下載下傳代碼包 & 通過 git 指令 clone 工程。如果選擇使用Git指令來Clone工程，需要注意一下，這個倉庫位址隻能下載下傳不能上傳哦。
Sandbox 沙箱環境
Sandbox 沙箱環境，為開發者帶來一套快速上手、免除任何環境依賴、免費、便捷的開發&運作環境。允許開發者在上面檢視、修改、部署示例代碼，并且由平台提供相關運作資源。
下面來看一下産品的界面：
左邊是産品的手冊&說明部分。這裡會包含說目前項目的功能說明、應用架構，以及如何部署和通路這些應用的操作步驟等。一些項目中使用到的技術點以及這些相關知識，也都會在這裡呈現給使用者。這部分文檔的目的，就是友善使用者去學習和了解目前的案例。
右邊的部分是應用清單。一個完整的産品，可能需要多個應用協同才能工作，這裡就是用來陳列相關的應用清單，同時也是針對這些應用的操作入口。
圖檔中的案例是一個任務管理器産品，功能相對簡單。但是麻雀雖小五髒俱全。這個産品包含兩個應用：
- 服務端，的包含了這個任務管理器的所有業務邏輯，以及下層的持久化能力等。
- WEB用戶端，包含了所有前端頁面邏輯、與前端通信的控制器層。
這兩個應用通過一個注冊中心來實作服務的注冊&發現。最終實作一個完整的任務管理器産品。
這些東西都會放到這裡面。這就是一個非常典型的一個一個應用拆分的一個方式，對不對？這裡的話，其實業務應用上它有兩個行動點，一個是開發和通路點，開發之後就會打開一個 IDE。
這裡面就會有整個工程的代碼。這些其實是我們預計好的，大家打開就能直接看到。如果它完全部署以後點了部署按鈕，我也會直接通路到這個應用。
其暴露出來的這個通路接口，我們點開發之後會看到這樣一個情況。對，這個就是我們的外包 id 。
開發者可以點選“開發”按鈕，打開一個 WEB-IDE 來檢視和修改對應應用的代碼：
這個WEB-IDE 和開發者日常使用的 IDE 是一樣的，都是左側代碼樹，右側代碼編輯器的标準布局。即使是不熟悉這個産品的使用者，也可以非常快的上手，甚至不需要學習過程。
如果需要部署這個應用，隻需要在“運維”功能下，點選“部署”按鈕，此時隻需要等待部署完成即可。在部署過程會有很多的日志輸出，都可以通過“輸出”窗體浏覽：
部署完成以後，會向 WEB-IDE 傳回一個通路位址，開發者隻需要點選這和位址就可以通路這個應用。下圖是實際的通路效果。可以看到，兩個應用，一個是任務管理器的web操作頁面、一個是背景資料庫管理頁面：
通過上面的步驟，開發者可以将案例快速部署起來。先部署試用，然後去學習和修改代碼，最後再部署驗證。通過這樣的循環，可以讓開發者很快學習和了解案例的功能和相關技術點。
對文檔有任何問題，請在評論區留言！