一：微服務架構簡紹學習目標

1.技術架構的演變，怎麼一步步到微服務的；2.什麼是微服務，優點與缺點 ；3.SOA（面向服務）與MicroServices（微服務）的區別 ；4.Dubbo 與Spring Cloud ；5.微服務的設計原則（a：AKF拆分原則，前後端分離原則，無狀態服務，Restful通訊風格）

二：架構演變

1.單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。 此時，用於簡化增刪改查工作量的 資料訪問框架(ORM) 是關鍵。 缺點：隨著應用功能的增多，程式碼量越來越大，越來越難維護，那怎麼解決程式碼一體化的問題？ 2.垂直應用架構 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效 率。 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。 缺點：垂直架構中相同邏輯程式碼需要不斷的複製，不能複用。每個垂直模組都相當於一個獨立的系統。 3.RPC分散式服務架構 當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的 服務中心，使前端應用能更快速的響應多變的市場需求。 此時，用於提高業務複用及整合的 分散式服務框架(RPC) 是關鍵。 缺點：服務越來越多，需要管理每個服務的地址，呼叫關係錯綜複雜，難以理清依賴關係，服務狀態難以 管理，無法根據服務情況動態管理。 4.SOA流動計算架構 資源的排程，負載均衡，動態服務建立，服務治理 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓 力實時管理叢集容量，提高叢集利用率。 此時，用於提高機器利用率的 資源排程和治理中心(SOA) 是關鍵。 缺點：服務間會有依賴關係，一旦某個環節出錯會影響較大，服務關係複雜，運維、測試部署困難，不符 合DevOps思想。 5.微服務架構： 單一職責：微服務中每一個服務都對應唯一的業務能力，做到單一職責 微：微服務的服務拆分粒度很小，例如一個使用者管理就可以作為一個服務。每個服務雖小，但“五臟俱 全”。 面向服務：面向服務是說每個服務都要對外暴露服務介面API。並不關心服務的技術實現，做到與平臺和語言無 關，也不限定用什麼技術實現，只要提供 Rest 的介面即可。 自治：自治是說服務間互相獨立，互不干擾 團隊獨立：每個服務都是一個獨立的開發團隊，人數不能過多。 技術獨立：因為是面向服務，提供 Rest 介面，使用什麼技術沒有別人干涉。 前後端分離：採用前後端分離開發，提供統一 Rest 介面，後端不用再為 PC、移動端開發不同介面。 資料庫分離：每個服務都使用自己的資料來源 部署獨立，服務間雖然有呼叫，但要做到服務重啟不影響其它服務。有利於持續整合和持續交付。每 個服務都是獨立的元件，可複用，可替換，降低耦合，易維護 Docker 部署服務 三：什麼是微服務 簡而言之，微服務架構風格是一種將單個應用程式作為一套小型服務開發的方法，每種應用程式都在自己 的程序中執行，並與輕量級機制（通常是HTTP資源API）進行通訊。 這些服務是圍繞業務功能構建的，可以通 過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的程式語言編寫，並使用不同的資料儲存 技術。
微服務就是將一個單體架構的應用按業務劃分為一個個的獨立執行的程式即服務，它們之間通過 HTTP 協議進行 通訊（也可以採用訊息佇列來通訊，如 RabbitMQ，Kafaka 等），可以採用不同的程式語言，使用不同的儲存技 術，自動化部署（如 Jenkins）減少人為控制，降低出錯概率。服務數量越多，管理起來越複雜，因此採用集中化管 理。例如 Eureka，Zookeeper 等都是比較常見的服務集中化管理框架。 微服務是一種架構風格。一個大型的複雜軟體應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部 署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好的完成該任務。 優點： 測試容易 可伸縮性強 可靠性強 跨語言 協同開發 方便系統迭代 缺點：運維成本高，部署專案多 介面相容版本問題 分散式系統的複雜性 分散式事務 四：SOA與MIcroServices（微服務）的區別
面向服務架構（SOA）是一種用於設計軟體的偉大原則。在 SOA 中，所有元件都是獨立自主的，並能為其他組 件提供服務。大體上，SOA與微服務架構是非常相像的。那麼它們之間的區別到底是什麼呢？微服務是細粒度的 SOA 元件。換句話說，某單個 SOA 元件可以被拆成多個微服務，而這些微服務通過分工協作，可以提供與原 SOA 元件相 同級別的功能。 微服務是細粒度的SOA元件，它們是關注點更窄的輕量級服務。微服務推崇執行的標準（例如HTTP）是人們廣 泛了解並共同使用的。我們可以通過選擇合適的語言或工具來構建某個元件（微服務），除了技術棧與服務規模之 外，在SOA與微服務之間還有一個更大的區別：領域模型。在一個基於微服務的軟體中，每個微服務應該在本地儲存 自身管理的資料，並將領域模型分別隔離到單個服務中。而在面向 SOA 的軟體中，資料往往儲存在單個大型的資料 庫中，服務之間會共享領域模型。

SOA                                                                            微服務架構
應用程式服務的可重用性的最大化                                       專注於解耦
系統性的改變需要修改整體                                                系統性的改變是建立一個新的服務
DevOps和持續交付正在變得流行，但還不是主流                 強烈關注DevOps和持續交付
專注於業務功能重用                                                         更重視“上下文邊界”的概念
通訊使用企業服務匯流排ESB（Enterprise Service Bus）   對於通訊而言，使用較少精細和簡單的訊息系統
支援多種訊息協議                                                     使用輕量級協議，例如HTTP，REST或ThriftAPI             
對部署到它的所有服務使用通用平臺                             應用程式伺服器不是真的被使用，通常使用雲平臺
容器（如Docker）的使用不太受歡迎                                容器在微服務方面效果很好
SOA服務共享資料儲存                                                   每個微服務可以有一個獨立的資料儲存
共同的治理和標準                                                           輕鬆的治理，更加關注團隊協作和選擇自由


一句話總結：微服務是 SOA 發展出來的產物，它是一種比較現代化的細粒度的 SOA 實現方式。

四：Dubbo與Spring Cloud的區別

Spring全家桶

Dubbo很多國內的企業還在用，可以支援RestFul風格的API，呼叫遠端API像呼叫本地API一樣，同時其基於介面的方式增加了服務間的耦合。

總結 Dubbo 由於是二進位制的傳輸，佔用頻寬會更少 SpringCloud 是 http 協議傳輸，頻寬會比較多，同時使用 http 協議一般會使用 JSON 報文，消耗會更大 Dubbo 的開發難度較大，原因是 Dubbo 的 jar 包依賴問題很多大型工程無法解決 SpringCloud 的介面協議約定比較自由且鬆散，需要有強有力的行政措施來限制介面無序升級 Dubbo 的註冊中心可以選擇 ZooKeeper Redis Nacos 等多種，SpringCloud 的註冊中心可以用 Eureka Consul 等 從系統結構簡易程式：SpringCloud 的系統結構更簡單、“註冊 + SpringMvc = SpringCloud”，而 Dubbo 各種 複雜的 url，protocol，register，invocation，dubbofifilter，dubboSPI，dubbo序列化...... 從效能：Dubbo 的網路消耗小於 SpringCloud，但是在國內 95% 的公司內，網路消耗不是什麼太大問題，如 果真的成了問題，通過壓縮、二進位制、快取記憶體、分段降級等方法，很容易解決。 五：微服務設計原則

1.AKF 拆分原則

業界對於可擴充套件的系統架構設計有一個樸素的理念，就是：通過加機器可以解決容量和可用性問題（如果一臺不 行就兩臺）。 用個段子描述就是：世界上沒有什麼事是一頓燒烤解決不了的，如果有，那就兩頓。 這一理念在“雲端計算”概念瘋狂流行的今天。得到了廣泛的認可。對於一個規模迅速增長的系統而言。容量和效能 問題當然是首當其衝的。但是隨著時間的向前，系統規模的增長，除了面對效能與容量的問題外，還需要面對功能與 模組數量上增長帶來的系統複雜性問題。以及業務變化帶來的提供差異化服務問題。而許多系統在架構設計時並未充 分考慮到這些問題，導致系統的重構成為常態。從而影響業務交付能力，還浪費人力財力。對此《The Art of Scalability》一書提出了一個更加系統的可擴充套件模型——AKF 可擴充套件立方。這個立方體中沿著三個座標軸設定分別為 X，Y，Z。
一個叫 AKF 的公司的技術專家抽象總結的應用擴充套件的三個維度。理論上按照這三個擴充套件模式，可以將一個 單體系統，進行無限擴充套件。 X 軸：指的是水平復制，很好理解，就是講單體系統多執行幾個例項，成為叢集加負載均衡的模式。 Z 軸：是基於類似的資料分割槽，比如一個網際網路打車應用突然火了，使用者量激增，叢集模式撐不住了，那就按照 使用者請求的地區進行資料分割槽，北京、上海、四川等多建幾個叢集。 Y 軸：就是我們所說的微服務的拆分模式，就是基於不同的業務拆分。 場景說明：比如打車應用，一個叢集撐不住時，分了多個叢集，後來使用者激增還是不夠用，經過分析發現 是乘客和車主訪問量很大，就將打車應用拆成了三個，分別為乘客服務、車主服務、支付服務。三個服務的業 務特點各不相同，獨立維護，各自都可以再次按需擴充套件。 2.前後端分離原則
前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的使用者體驗優化效果更好。 前後端分離模式下，前後端互動介面更清晰，就剩下了介面模型，後端的介面簡潔明瞭，更容易維護。 前端多渠道整合場景更容易實現，後端服務無需變更，採用統一的資料和模型，可以支援多個前端：例如：微 信 h5 前端、PC 前端、安卓前端、IOS 前端。 3.無狀態服務 （無狀態就是請把溫度調到27度，有狀態就是+1與-1）
對於無狀態服務，首先說一下什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼這個數 據被稱為狀態。進而依賴這個“狀態”資料的服務被稱為有狀態服務，反之稱為無狀態服務。那麼這個無狀態服務原則 並不是說在微服務架構裡就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務， 那麼狀態資料也就相應的遷移到對應的“有狀態資料服務”中。場景說明：例如我們以前在本地記憶體中建立的資料緩 存、Session 快取，到現在的微服務架構中就應該把這些資料遷移到分散式快取中儲存，讓業務服務變成一個無狀態 的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在執行時動態增刪節點，就不再需要考慮快取資料如何 同步的問題。 也就是對同一個 url 請求沒有上下文關係。舉個生活中的例子： 比如空調遙控器，你按上下調整溫度時，空調溫度設定值會變化，遙控器訊號到空調是單向傳輸。現在空 調顯示溫度 20 度，遙控器 20 度。如果遙控器與空調之間是有狀態的，假設你離開空調接收範圍調整了遙控器 溫度，變成 19，那回到範圍內你按一次升高一度，基於原先溫度狀態，遙控器給空調發送一個“提高1度”的指 令，就會出現遙控器提高到 20，而空調變成21。如果要空間與空調之前是無狀態的，假設你離開空調接收範 圍調整了遙控器溫度，變成 19，那回到範圍內你按一次升高一度，遙控器給空調發送一個“設定溫度值20”，這 樣兩者最終還是相同的值。 4.RestFul通訊風格 返回的是json資料（其實RestFul就是通過RestFul風格來設計Url路徑來進行微服務的開發）
基於“無狀態通訊原則”，在這裡我們直接推薦一個實踐優選的 Restful 通訊風格 ，因為他有很多好處： 無狀態協議 HTTP，具備先天優勢，擴充套件能力很強。例如需要安全加密時，有現成的成熟方案 HTTPS 可用。 JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜尋引擎友好。 語言無關，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些 RPC 框架生態更完善。 六：什麼是SpringCloud（學習目標） 1.概念的定義，2.SpringCloud第一代 3.版本說明（單詞與數字的區別，定義規則，釋出計劃，子專案版本說明） 4.SpringCloud第二代
1.概念定義 Spring Cloud 是一個服務治理平臺，提供了一些服務框架。包含了：服務註冊與發現、配置中心、訊息中心 、 負載均衡、資料監控等等。 Spring Cloud 是一個微服務框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分散式系統解決方 案。 Spring Cloud 對微服務基礎框架 Netflflix 的多個開源元件進行了封裝，同時又實現了和雲端平臺以及 Spring Boot 框架的整合。 Spring Cloud 是一個基於 Spring Boot 實現的雲應用開發工具，它為開發中的配置管理、服務發現、斷路器、 智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等操作提供了一種簡單的開發方式。 Spring Cloud 為開發者提供了快速構建分散式系統的工具，開發者可以快速的啟動服務或構建應用、同時能夠 快速和雲平臺資源進行對接。微服務是可以獨立部署、水平擴充套件、獨立訪問（或者有獨立的資料庫）的服務單元， Spring Cloud 就是這些微服務的大管家，採用了微服務這種架構之後，專案的數量會非常多，Spring Cloud 做為大 管家需要管理好這些微服務，自然需要很多小弟來幫忙。 SpringCloud第一代

SpringCloud第二代

七：SpringCloud Netflix 第一代

Netflflix是一家美國公司，在美國、加拿大提供網際網路隨選流媒體播放，定製DVD、藍光光碟線上出租業 務。該公司成立於1997年，總部位於加利福尼亞州洛斯蓋圖，1999年開始訂閱服務。2009年，該公司可提供 多達10萬部DVD電影，並有1千萬的訂戶。2007年2月25日，Netflflix宣佈已經售出第10億份DVD。HIS一份報 告中表示，2011年Netflflix網路電影銷量佔據美國使用者線上電影總銷量的45%。 針對多種 Netflflix 元件提供的開發工具包，其中包括 Eureka、Hystrix、Ribbon、Zuul、Archaius 等。 Netflix Eureka ：一個基於 Rest 服務的服務治理元件，包括服務註冊中心、服務註冊與服務發現機制的實 現，實現了雲端負載均衡和中間層伺服器的故障轉移。 Netflix Hystrix ：容錯管理工具，實現斷路器模式，通過控制服務的節點，從而對延遲和故障提供更強大的 容錯能力。 Netflix Ribbon ：客戶端負載均衡的服務呼叫元件。 Netflix Feign ：基於 Ribbon 和 Hystrix 的宣告式服務呼叫元件。 Netflix Zuul ：微服務閘道器，提供動態路由，訪問過濾等服務。 Netflix Archaius ：配置管理 API，包含一系列配置管理 API，提供動態型別化屬性、執行緒安全配置操作、輪 詢框架、回撥機制等功能。 八：SpringCloud Alibaba第二代 ①：SpringCloudNetflix的配置中心是Archaius，我們一般也用SpringCloudConfig來當配置中心（這個是SpringCloud的配置中心） Alibaba用的就是Nacos來當配置中心 ②：服務註冊 SpringCloudNetflix用的是Eureka， SpringCloudAlibaba用的是Nacos
Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案。此專案包含開發分散式應用微服務的必需組 件，方便開發者通過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。 依託 Spring Cloud Alibaba，只需要新增一些註解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解 決方案，通過阿里中介軟體來迅速搭建分散式應用系統。 Nacos ：阿里巴巴開源產品，一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。 Sentinel ：面向分散式服務架構的輕量級流量控制產品，把流量作為切入點，從流量控制、熔斷降級、系統負 載保護等多個維度保護服務的穩定性。 RocketMQ ：一款開源的分散式訊息系統，基於高可用分散式叢集技術，提供低延時的、高可靠的訊息釋出與訂 閱服務。 Dubbo ：Apache Dubbo™ 是一款高效能 Java RPC 框架。 Seata ：阿里巴巴開源產品，一個易於使用的高效能微服務分散式事務解決方案。 Alibaba Cloud ACM ：一款在分散式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。 Alibaba Cloud OSS ：阿里雲物件儲存服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、 安全、低成本、高可靠的雲端儲存服務。您可以在任何應用、任何時間、任何地點儲存和訪問任意型別的資料。 Alibaba Cloud SchedulerX ：阿里中介軟體團隊開發的一款分散式任務排程產品，提供秒級、精準、高可靠、 高可用的定時（基於 Cron 表示式）任務排程服務。 Alibaba Cloud SMS ：覆蓋全球的簡訊服務，友好、高效、智慧的互聯化通訊能力，幫助企業迅速搭建客戶觸 達通道。

九：SpringCloud常用的元件

常用元件 Spring Cloud Netflix Eureka ：服務註冊中心。 Spring Cloud Netflix Ribbon ：客戶端負載均衡。 Spring Cloud Netflix Hystrix ：服務容錯保護。 Spring Cloud Netflix Feign ：宣告式服務呼叫。 Spring Cloud OpenFeign(可替代 Feign) ：OpenFeign 是 Spring Cloud 在 Feign 的基礎上支援了 Spring MVC 的註解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 註解下的介面，並通過動態代理的方式產生實現類，實現類中做負載均衡並呼叫其他服 務。 Spring Cloud Netflix Zuul ：API 閘道器服務，過濾、安全、監控、限流、路由。 Spring Cloud Gateway(可替代 Zuul) ：Spring Cloud Gateway 是 Spring 官方基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的閘道器，Spring Cloud Gateway 旨在為微服務架構提供一種簡單而有 效的統一的 API 路由管理方式。Spring Cloud Gateway 作為 Spring Cloud 生態系中的閘道器，目標是替代 Netflflix Zuul，其不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了閘道器基本的功能，例如：安全，監 控/埋點，和限流等。 Spring Cloud Config ：分散式配置中心。配置管理工具，支援使用 Git 儲存配置內容，支援應用配置的外部 化儲存，支援客戶端配置資訊重新整理、加解密配置內容等。 Spring Cloud Bus ：事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Confifig 聯合實現熱部署。 Spring Cloud Stream ：訊息驅動微服務。 Spring Cloud Sleuth ：分散式服務跟蹤。 Spring Cloud Alibaba ：阿里巴巴結合自身微服務實踐，開源的微服務全家桶。在 Spring Cloud 專案中孵 化，很可能成為Spring Cloud 第二代的標準實現。 雖然 Eureka，Hystrix 等不再繼續開發或維護，但是目前來說不影響使用， 十：SpringCloud為什麼版本號用的是單詞而不用數字
這樣設計的目的是為了更好的管理每個 Spring Cloud 的子專案的清單。避免總版本號與子專案的版本號混淆。 例如：Spring Cloud 2.2.0.RELEASE 的 Spring Cloud Netflflix 2.2.2.RELEASE 如果使用這種方式會讓開發者混淆 版本 十一：SpringCloud的版本定義和釋出詳細
定義規則 採用倫敦的地鐵站名稱來作為版本號的命名，根據首字母排序，字母順序靠後的版本號越大。
Spring 官方詳細的版本檢視介面：https://start.spring.io/actuator/info 釋出計劃 子專案版本說明 例如：Spring Cloud Alibaba 2.1.0.RELEASE 2：主版本號。當功能模組有較大更新或者整體架構發生變化時，主版本號會更新。 1：次版本號。次版本表示只是區域性的一些變動。 0：修改版本號。一般是 bug 的修復或者是小的變動。 RELEASE：希臘字母版本號。標註當前版本的軟體處於哪個開發階段
希臘字母版本說明 Base：設計階段。只有相應的設計沒有具體的功能實現。 Alpha：軟體的初級版本。存在較多的 bug。 Bate：表示相對 Alpha 有了很大的進步，消除了嚴重的 bug，還存在一些潛在的 bug。 Gamma：是 Beta 版做過一些修改，成為正式釋出的候選版本（Release Candidate） Release：該版本表示最終版。