springCloud學習

第一章微服務架構介紹

 

（Spring Cloud 初級）

 

 

1、 單體架構

 

單體架構也稱之爲單體系統或者是單體應用。就是一種把系統中全部的功能、模塊耦合

在一個應用中的架構方式。

 

1 單體架構特色

 

1.1打包成一個獨立的單元(導成一個惟一的 jar 包或者是 war 包)

1.2會一個進程的方式來運行

 

 

 

 

 

 

 

2 單體架構的優勢、缺點

 

2.1優勢

 

　　2.1.1項目易於管理

　　2.1.2部署簡單

 

2.2缺點

 

2.2.1測試成本高

• 全部的功能都在一個項目中，好比項目要被迭代，功能要被改變，因爲是一個總體，一個部分發送改變，全部部分都要進行測試。不敢保證此次跟新會不會對總體形成影響。

2.2.2可伸縮性差

• 單體架構項目是以一個單進程來運行的，很具有侷限性，水平擴展不容易。好比如今對整個系統進行擴展，好比其中一個模塊，如商品模塊，訪問需求量過大，咱們要對她進行集羣部署，進行水平擴展。單體架構很難作到，咱們只能對整個項目進行集羣部署。

2.2.3可靠性差

• 當前系統，某個模塊出現bug，致使整個系統不可用。

2.2.4迭代困難

• 因爲全部的模塊都在一個項目中，會致使平常迭代很是困難，好比說互聯網項目，每月都會進行一次迭代。單體架構會致使分支過多，分支過多在合併代碼的時候，會很是痛苦。

2.2.5跨語言程度差

• 因爲咱們如今系統的體系愈來愈龐大，需求愈來愈大。這時候單依靠java一門語言，顯得有些力不從心。這時候咱們可能還會依靠其餘的語言來對項目進行支持。單體架構這時候想加入其餘語言就比較難，由於單體架構是耦合在一塊兒的。

2.2.6團隊協做難

• 整個系統是由一個團隊來開發的。單體架構，裏面的內容變得很是的龐大的時候，咱們每一個成員就要進行大量的代碼。整個團隊之間，進行溝通和協做就很困難。不像分佈式架構，每一個團隊只負責一個模塊，不像單體架構溝通那麼困難。

 

2、 微服務架構

 

1 什麼是微服務

 

　　微服務是一種架構風格。一個大型的複雜軟件應用，由一個或多個微服務組成。系統中

的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任

務並很好的完成該任務。

 

2 架構風格

 

　　項目的一種設計模式。

 

2.1常見的架構風格

 

• 2.1.1客戶端與服務端的

 

• 2.1.2基於組件模型的架構（EJB）

 

• 2.1.3分層架構(MVC)

 

• 2.1.4面向服務架構(SOA)

 

3 微服務特色：

 

 

　　3.1系統是由多個服務構成

 

　　3.2每一個服務能夠單獨獨立部署

 

　　3.3每一個服務之間是鬆耦合的。服務內部是高內聚的，外部是低耦

合的。高內聚就是每一個服務只關注完成一個功能。

 

4 微服務的優勢、缺點

 

4.1優勢

 

4.1.1測試容易

• 每一個服務的組件都是靈活的，能獨立部署，因此說測試起來的時候，對哪一個服務進行了迭代，就能夠徵對性取進行測試。

 

4.1.2可伸縮性強

 

•  內部高內聚，外部鬆耦合。每一個服務都能進行相應擴展。

 

4.1.3可靠性強

• 以前講單體架構也說過，一單項目某個模塊出現問題，受影響的是整個項目。可是微服務則否則，並不會由於某個bug而致使整個服務所有宕機。受影響的是某個服務，而不是整個項目。

 

4.1.4跨語言程度會更加靈活

 

• 微服務的架構跟語言無關，咱們能夠根據本身的選擇或者項目的特色去選擇不一樣的語言和工具，高效的去完成這個項目。

 

 

4.1.5團隊協做容易

• 只作本身某一塊的服務，並不須要去關注其餘的服務。下降了程序員的學習成本和溝通成本。

 

4.1.6系統迭代容易

 

• 每一個微服務能夠根據每一個團隊進行相應的獨立開發。系統迭代只正對當前的服務就能夠了。

 

4.2缺點

 

4.2.1運維成本太高，部署數量較多

 

• 不像單體架構，只有一個項目，咱們只要放入tomcat中運行就能夠了。如今把一個項目拆分紅多個服務，服務越多，運維的成本就越高。

 

4.2.2接口兼容多版本

• 咱們須要考慮到接口兼容多版本的問題。面向服務開發就是面向接口開發，服務的提供方式就是經過接口來提供的。接口的變動必然會致使多個客戶端跟着改，這樣就必須作接口的多版本開發。以便於適用於接口的變動。

 

4.2.3分佈式系統的複雜性

• 原本是一個系統，如今把他拆分紅多個服務。因爲網絡的延遲性，網絡的不穩定，服務的容錯性，服務的負載均衡等等，都是咱們咱們在作微服務架構須要考慮到的一個問題。

 

4.2.4分佈式事務

• 咱們在作微服務開發的時候，最大的難題就是對分佈事務的處理。

 

3、 MVC、RPC、SOA、微服務架構之間的區別

 

 

• 1 MVC 架構

 

其實 MVC 架構就是一個單體架構。

表明技術：Struts二、SpringMVC、Spring、Mybatis 等等。

 

• 2 RPC 架構

 

RPC(Remote Procedure Call)：遠程過程調用。他一種經過網絡從遠程計算機程序上請求

服務，而不須要了解底層網絡技術的協議。

表明技術：Thrift、Hessian 等等

 

• 3 SOA 架構

 

SOA(Service oriented Architecture):面向服務架構

 

ESB(Enterparise Servce Bus):企業服務總線，服務中介。主要是提供了一個服務於服務之間的交互。

 

ESB 包含的功能如：負載均衡，流量控制，加密處理，服務的監控，異常處理，監控告急等等。

 

表明技術：Mule(不開源)、WSO2(開源,免費)

 

 

• 4 微服務架構

 

微服務就是一個輕量級的服務治理方案。

 

註冊中心:比ESB更輕量一些。

 

表明技術：SpringCloud、dubbo 等等

 

 

 

4、 如何設計微服務以及設計原則

 

1) AKF 拆分原則

 

2) 先後端分離原則

 

3) 無狀態服務

 

4) RestFul 的通訊風格

 

1 AKF 拆分原則

 

業界對於可擴展的系統架構設計有一個樸素的理念,就是：

經過加機器就能夠解決容量和可用性問題。(若是一臺不行那就兩臺)。

我是個段子：（世界上沒有什麼事是一頓燒烤不能解決的。若是有，那就兩

頓。）

這一理念在「雲計算」概念瘋狂流行的今天，獲得了普遍的承認！對於一個規模

迅速增加的系統而言，容量和性能問題固然是首當其衝的。可是隨着時間的向前，

系統規模的增加，除了面對性能與容量的問題外，還須要面對功能與模塊數量上

的增加帶來的系統複雜性問題以及業務的變化帶來的提供差別化服務問題。而許

多系統，在架構設計時並未充分考慮到這些問題，致使系統的重構成爲常態，從

而影響業務交付能力，還浪費人力財力！對此，《可擴展的藝術》一書提出了一

個更加系統的可擴展模型—— AKF 可擴展立方 （Scalability Cube）。這個立方

體中沿着三個座標軸設置分別爲：X、Y、Z。 

 

 

 

 

Y 軸(功能) —— 關注應用中功能劃分，基於不一樣的業務拆分

X 軸(水平擴展) —— 關注水平擴展，也就是」加機器解決問題」

Z 軸(數據分區) —— 關注服務和數據的優先級劃分，如按地域劃分

 

 

1.1 Y 軸(功能)

 

Y 軸擴展會將龐大的總體應用拆分爲多個服務。每一個服務實現一組相關的功

能，如訂單管理、客戶管理等。在工程上常見的方案是 服務化架構(SOA) 。比

如對於一個電子商務平臺，咱們能夠拆分紅不一樣的服務，組成下面這樣的架構：

 

 

 

但經過觀察上圖容易發現，當服務數量增多時，服務調用關係變得複雜。爲

系統添加一個新功能，要調用的服務數也變得不可控，由此引起了服務管理上的

混亂。因此，通常狀況下，須要採用服務註冊的機制造成服務網關來進行服務治

理。系統的架構將變成下圖所示：

 

 

 

1.2 X 軸(水平擴展)

 

X 軸擴展與咱們前面樸素理念是一致的，經過絕對平等地複製服務與數據，

以解決容量和可用性的問題。其實就是將微服務運行多個實例，作集羣加負載均

衡的模式。

爲了提高單個服務的可用性和容量， 對每個服務進行 X 軸擴展劃分 。

 

 

 

1.3 Z 軸(數據分區)

 

Z 軸擴展一般是指基於請求者或用戶獨特的需求，進行系統劃分，並使得劃

分出來的子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司

爲了發展在中國的業務，或者利用中國的廉價勞動力，在中國創建一個完整的子

工廠，與美國工廠同樣，負責完整的汽車生產。這就是一種 Z 軸擴展。

1.3.1工程領域常見的 Z 軸擴展有如下兩種方案：

1.3.1.1 單元化架構

在分佈式服務設計領域，一個單元（Cell）就是知足某個分區全部業務操做

的自包含閉環。如上面咱們說到的 Y 軸擴展的 SOA 架構，客戶端對服務端節點

的選擇通常是隨機的，可是，若是在此加上 Z 軸擴展，那服務節點的選擇將再也不

是隨機的了，而是每一個單元自成一體。以下圖：

 

 

 

1.3.1.2 數據分區

爲了性能數據安全上的考慮，咱們將一個完整的數據集按必定的維度劃分出

不一樣的子集。 一個分區（Shard），就是是總體數據集的一個子集。好比用尾號

來劃分用戶，那一樣尾號的那部分用戶就能夠認爲是一個分區。數據分區爲通常

包括如下幾種數據劃分的方式：

數據類型（如：業務類型）

數據範圍（如：時間段，用戶 ID）

數據熱度（如：用戶活躍度，商品熱度）

按讀寫分（如：商品描述，商品庫存）

 

 

2 先後端分離原則

 

 

何爲先後端分離？先後端原本不就分離麼？

這要從尷尬的 jsp 講起。分工精細化歷來都

是蛋糕作大的原則，多個領域工程師最好在不須要接觸其餘領域知識的狀況下合做，纔可能

使效率愈來愈高，維護也會變得簡單。jsp 的模板技術融合了 html 和 java 代碼，使得傳統

MVC 開發中的先後端在這裏如膠似漆，前端作好頁面，後端轉成模板，發現問題再找前端，

前端又看不懂 java 代碼......先後端分離的目的就是將這尷尬局面打破。

先後端分離原則，簡單來說就是前端和後端的代碼分離，咱們推薦的模式是最好採用物

理分離的方式部署，進一步促使更完全的分離。若是繼續直接使用服務端模板技術，如：jsp，

把 java、js、html、css 都堆到一個頁面裏，稍微複雜一點的頁面就沒法維護了。

 

 

 

這種分離方式有幾個好處：

 

• 1) 先後端技術分離，能夠由各自的專家來對各自的領域進行優化，這樣前段的用戶體驗優化效果更好。
• 2) 分離模式下，先後端交互界面更清晰，就剩下了接口模型，後端的接口簡潔明瞭，更容易維護。
• 3) 前端多渠道集成場景更容易實現，後端服務無需變動，採用統一的數據和模型，能夠支持多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

 

 

3 無狀態服務

 

 

 

 

對於無狀態服務，首先說一下什麼是狀態：若是一個數據須要被多個服務共

享，才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個「狀態」數據的

服務被稱爲有狀態服務，反之稱爲無狀態服務。

 

那麼這個無狀態服務原則並非說在微服務架構裏就不容許存在狀態，表達

的真實意思是要把有狀態的業務服務改變爲無狀態的計算類服務，那麼狀態數據

也就相應的遷移到對應的「有狀態數據服務」中。

 

 

場景說明：例如咱們之前在本地內存中創建的數據緩存、Session 緩存，到

如今的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變

成一個無狀態的計算節點。遷移後，就能夠作到按需動態伸縮，微服務應用在運

行時動態增刪節點，就再也不須要考慮緩存數據如何同步的問題。

 

4 RestFul 的通信風格

 

 

做爲一個原則來說原本應該是個「無狀態通訊原則」，在這裏咱們直接推薦一

個實踐優選的 Restful 通訊風格 ，由於他有不少好處：

 

1) 無狀態協議 HTTP，具有先天優點，擴展能力很強。例如須要安全加密，有

現成的成熟方案 HTTPS 便可。

 

2) JSON 報文序列化，輕量簡單，人與機器都可讀，學習成本低，搜索引擎友

好。

 

 

 

第二章 SpringCloud 入門

 

 

（Spring Cloud 初級）

 

1、 什麼是 SpringCloud

 

什麼是 SpringCloud：是一個服務治理平臺，提供了一些服務框架。包含了：服務註冊

與發現、配置中心、消息中心 、負載均衡、數據監控等等。

 

1 概念定義

 

Spring Cloud 是一個微服務框架，相比 Dubbo 等 RPC 框架, Spring Cloud 提

供的全套的分佈式系統解決方案。

 

Spring Cloud 對微服務基礎框架 Netflix 的多個開源組件進行了封裝，同時又實現

了和雲端平臺以及和 Spring Boot 開發框架的集成。

 

Spring Cloud 爲微服務架構開發涉及的 配置管理，服務治理，熔斷機制，智能路由，

微代理，控制總線，一次性 token，全局一致性鎖，leader 選舉，分佈式 session，集

羣狀態管理等操做提供了一種簡單的開發方式。

 

Spring Cloud 爲開發者提供了快速構建分佈式系統的工具，開發者能夠快速的啓動

服務或構建應用、同時可以快速和雲平臺資源進行對接。

 

2 Spring Cloud 的項目的位置

 

Sping Cloud 是 Spring 的一個頂級項目與 Spring Boot、Spring Data 位於同一位置。

 

3 Spring Cloud 的子項目

 

Spring Cloud 包含了不少子項目，如：

 

 

3.1Spring Cloud Config：配置管理工具，支持使用 Git 存儲配置內容，支持應

用配置的外部化存儲，支持客戶端配置信息刷新、加解密配置內容等

 

3.2 Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中

傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。

 

3.3Spring Cloud Netflix：針對多種 Netflix 組件提供的開發工具包，其中包括

Eureka、Hystrix、Zuul、Archaius 等。

 

3.3.1Netflix Eureka：一個基於 rest 服務的服務治理組件，包括服務註冊中

心、服務註冊與服務發現機制的實現，實現了雲端負載均衡和中間層服務器

的故障轉移。

 

3.3.2Netflix Hystrix：容錯管理工具，實現斷路器模式，經過控制服務的節點,

從而對延遲和故障提供更強大的容錯能力。

 

3.3.3Netflix Ribbon：客戶端負載均衡的服務調用組件。

 

3.3.4Netflix Feign：基於 Ribbon 和 Hystrix 的聲明式服務調用組件。

 

3.3.5Netflix Zuul：微服務網關，提供動態路由，訪問過濾等服務。

 

3.3.6Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供動

態類型化屬性、線程安全配置操做、輪詢框架、回調機制等功能。

 

3.4Spring Cloud for Cloud Foundry：經過 Oauth2 協議綁定服務到

CloudFoundry，CloudFoundry 是 VMware 推出的開源 PaaS 雲平臺。

 

3.5Spring Cloud Sleuth：日誌收集工具包，封裝了 Dapper,Zipkin 和 HTrace

操做。

 

3.6Spring Cloud Data Flow：大數據操做工具，經過命令行方式操做數據流。

 

3.7Spring Cloud Security：安全工具包，爲你的應用程序添加安全控制，主要

是指 OAuth2。

 

3.8Spring Cloud Consul：封裝了 Consul 操做，consul 是一個服務發現與配

置工具，與 Docker 容器能夠無縫集成。

 

3.9Spring Cloud Zookeeper ：操做 Zookeeper 的 工 具 包 ， 用 於 使 用

zookeeper 方式的服務註冊和發現。

 

3.10Spring Cloud Stream：數據流操做開發包，封裝了與 Redis,Rabbit、

Kafka 等發送接收消息。

 

3.11Spring Cloud CLI：基於 Spring Boot CLI，可讓你以命令行方式快速

創建雲組件。

 

2、 SpringCloud 與 Dubbo 的區別

 

 

 

3、 Spring Cloud 版本說明

 

1 常見版本號說明

 

軟件版本號：2.0.2.RELEASE

2：主版本號。當功能模塊有較大更新或者總體架構發生變化時，主版本號會更新

0：次版本號。次版本表示只是局部的一些變更。

2：修改版本號。通常是 bug 的修復或者是小的變更

RELEASE:希臘字母版本號。次版本號用戶標註當前版本的軟件處於哪一個開發階段

 

1.1希臘字母版本號

Base：設計階段。只有相應的設計沒有具體的功能實現。Alpha：軟件的初級版本。存在較多的 bug

Bate：表示相對 alpha 有了很大的進步，消除了嚴重的 bug，還存在一些潛在的 bug。

Release：該版本表示最終版。

 

2 Spring Cloud 版本號說明

 

2.1爲何 Spring Cloud 版本用的是單詞而不是數字？

設計的目的是爲了更好的管理每一個 Spring Cloud 的子項目的清單。避免子的版本號與子

項目的版本號混淆。

 

2.2版本號單詞的定義規則

採用倫敦的地鐵站名稱來做爲版本號的命名，根據首字母排序，字母順序靠後的版本號

越大。

 

2.3版本發佈計劃說明

 

 

3 Spring Cloud 與子項目版本兼容說明