✨ Spring Cloud:微服務基礎知識
- 一、系統架構演變
- 1. 單體應用架構
- 2. 垂直應用架構
- 3. 分布式架構
- 4. SOA架構
- 4.1 SOA概念
- 4.2 SOA
- 5.微服務架構
- 6.SOA和微服務架構的關系
- 2.分布式核心知識
- 1.分布式中的遠端調用
- 1.1RESTFUL接口
- 1.2RPC協定
- 1.3二者的差別與聯系
- 2.分布式中的CAP原理
一、系統架構演變
随着網際網路的發展，網站應用的規模不斷擴大，正常的應用架構已無法應對，分布式服務架構以及微服務架構勢在必行，亟需一個治理系統確定架構有條不紊的演進。
1. 單體應用架構
在企業發展的初期，一般公司的網站流量都比較小，隻需要一個應用，将所有的功能代碼打包成一個服務，部署到伺服器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。
比如搭建一個電商系統：客戶下訂單，商品展示，使用者管理。這種将所有功能都部署在一個web容器中運作的系統就叫做單體架構。
Web應用程式發展的早期，大部分web工程(包含前端頁面,web層代碼,service層代碼,dao層代碼)是将所有的功能子產品,打包到一起并放在一個web容器中運作。
單體架構優點
1.所有的功能內建在一個項目工程中
2.項目架構簡單，前期開發成本低，周期低，是小型項目的首選
單體架構缺點
1.所有功能內建在一個工程中，對于大型項目不容易開發、擴充和維護，如果需要修改、新增某一個功能的話，需要對整個系統進行測試，重新部署。
2.系統性能擴充隻能通過擴充叢集節點，成本高，有瓶頸
3.一個子產品出現問題，可能導緻整個系統崩潰。
4.各個子產品使⽤同⼀種技術架構，局限性太大，很難根據業務選擇最适合的技術架構。
5.多團隊同時對資料進行管理，容易産生安全漏洞。
6.子產品内容太複雜，如果員工離職，可能需要很長時間才能完成任務交接。
2. 垂直應用架構
随着企業業務的不斷發展，發現單節點的單體應用不足以支撐業務的發展，于是企業會将單體應用部署多份，分别放在不同的伺服器上。但是，此時會發現不是所有的子產品都會有比較大的通路量。如果想針對項目中的某些子產品進行優化和性能提升，此時對于單體應用來說，是做不到的。是以，垂直應用架構誕生了。
垂直應用架構，就是将原來一個項目應用進行拆分，将其拆分為互不想幹的幾個應用，以此來提升系統的整體性能。
我們将單體應用架構拆分為垂直應用架構之後，一旦通路量變大，我們隻需要針對通路量大的業務增加伺服器節點即可，無需針對整個項目增加伺服器節點了。
優點：
項目架構簡單，前期開發成本低，周期短，小型項目的首選。
通過垂直拆分，原來的單體項目不至于無限擴大
不同的項目可采用不同的技術。
各系統能夠分擔整體通路的流量，解決了并發問題。
一個系統發生了故障，不應用其他系統的運作情況，提高了整體的容錯率。
缺點：
拆分後的各系統之間相對比較獨立，無法進行互相調用。
各系統難免存在重疊的業務，會存在重複開發的業務，後期維護比較困難。
3. 分布式架構
我們将系統演變為垂直應用架構之後，當垂直應用越來越多，重複編寫的業務代碼就會越來越多。此時，我們需要将重複的代碼抽象出來，形成統一的服務供其他系統或者業務子產品來進行調用。此時，系統就會演變為分布式架構。
在分布式架構中，我們會将系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用，表現層則負責處理與頁面的互動操作。
優點:提高代碼的複用性
缺點:耦合度變高，調用關系變得複雜
4. SOA架構
4.1 SOA概念
如何通俗易懂地解釋什麼是SOA？ SOA 全稱為 Service-Oriented Architecture，即面向服務的架構。它可以根據需求通過網絡對松散耦合的粗粒度應用元件(服務)進行分布式部署、組合和使用。一個服務通常以獨立的形式存在于作業系統進 程中。
站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實作業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實作業務邏輯的快速複用。
通過上面的描述可以發現 SOA 有如下幾個特點：分布式、可重用、擴充靈活、松耦合
4.2 SOA
在分布式架構下，當部署的服務越來越多，重複的代碼就會越來越多，對于容量的評估，小服務資源的浪費等問題比較嚴重。此時，我們就需要增加一個統一的排程中心來對叢集進行實時管理。此時，系統就會演變為SOA（面向服務）的架構。
優點：
抽取公共的功能為服務,提高開發效率
對不同的服務進行叢集化部署解決系統壓力
基于ESB/DUBBO減少系統耦合
缺點：
抽取服務的粒度較大
服務提供方與調用方接口耦合度較高
5.微服務架構
微服務是什麼 微服務是一種架構模式，它提倡把單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務之間采用輕量級的通信機來互相協作(通常是基于HTTP協定的RESTful API)，每一個服務都圍繞在具體業務進行建構，并且能夠被獨立的部署到生産環境、類生産環境等。而且，我們應盡量避免統一的、集中式的服務管理機制，對具體的一個來說，應該要根據業務上下文，選擇合适的語言、工具來進行建構。
- 所謂“服務”，其實指的是項目中的功能子產品，它可以幫助使用者解決某一個或一組問題，在開發過程中表現為 IDE（內建開發環境，例如 Eclipse 或 IntelliJ IDEA）中的一個工程或 Moudle。
- “微小”則強調的是單個服務的大小，主要展現為以下兩個方面：
- 微服務體積小，複雜度低：一個微服務通常隻提供單個業務功能的服務，即一個微服務隻專注于做好一件事，是以微服務通常代碼較少，體積較小，複雜度也較低。
- 微服務團隊所需成員少：一般情況下，一個微服務團隊隻需要 8 到 10 名人員（開發人員 2 到 5 名）即可完成從設計、開發、測試到運維的全部工作。
- 每個服務都能夠獨立地部署到各種環境中，例如開發環境、測試環境和生産環境等，每個服務都能獨立啟動或銷毀而不會對其他服務造成影響。
優點：
- 通過服務的原子化拆分，以及微服務的獨立打包、部署和更新，小團隊的傳遞周期将縮短，運維成
本也将大幅度下降
- 微服務遵循單一原則。微服務之間采用Restful等輕量協定傳輸。
缺點：
- 微服務過多，服務治理成本高，不利于系統維護。
- 分布式系統開發的技術成本高（容錯、分布式事務等）。
- 如果某個系統的遠端調⽤出現問題，導緻微服務不可⽤，就有可能産⽣級聯反應，造成整個系統的
崩潰。
6.SOA和微服務架構的關系
2.分布式核心知識
1.分布式中的遠端調用
在微服務架構中，通常存在多個服務之間的遠端調用的需求。遠端調用通常包含兩個部分：序列化和通
信協定。常見的序列化協定包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的
遠端調用技術有基于HTTP的RESTful接口以及基于TCP的RPC協定。
1.1RESTFUL接口
REST，即Representational State Transfer的縮寫，如果一個架構符合REST原則，就稱它為RESTful架構。
資源（Resources）
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體資訊。它可以是一段文本、一張圖 片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它， 每種資源對應一個特定的URI。要擷取這個資源，通路它的URI就可以，是以URI就成了每一個資源的地
址或獨一無二的識别符。REST的名稱"表現層狀态轉化"中，省略了主語。“表現層"其實指的是"資 源”（Resources）的"表現層"。
表現層（Representation）
“資源"是一種資訊實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層”（Representation）。比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以采用二進制格式；圖檔可以用JPG格式表現，也可以用PNG格式表現。URI隻代表資源 的實體，不代表它的形式。嚴格地說，有些網址最後的".html"字尾名是不必要的，因為這個字尾名表示 格式，屬于"表現層"範疇，而URI應該隻代表"資源"的位置。
狀态轉化（State Transfer）
通路一個網站，就代表了用戶端和伺服器的一個互動過程。在這個過程中，勢必涉及到資料和狀态的變
化。網際網路通信協定HTTP協定，是一個無狀态協定。這意味着，所有的狀态都儲存在伺服器端。因 此，如果用戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀态轉化"（State Transfer）。 用戶端用到的手段，隻能是HTTP協定。具體來說，就是HTTP協定裡面，四個表示操作方式的動詞： GET、POST、PUT、DELETE。它們分别對應四種基本操作：**GET用來擷取資源，POST用來建立資源 **（也可以用于更新資源），PUT用來更新資源，DELETE用來删除資源。
綜合上面的解釋，我們總結一下什麼是RESTful架構：
- 每一個URI代表一種資源；
- 用戶端和伺服器之間，傳遞這種資源的某種表現層；
- 用戶端通過四個HTTP動詞，對伺服器端資源進行操作，實作"表現層狀态轉化"。
1.2RPC協定
RPC（Remote Procedure Call ）
一種程序間通信方式。允許像調用本地服務一樣調用遠端服務。RPC
架構的主要目标就是讓遠端服務調用更簡單、透明。RPC架構負責屏蔽底層的傳輸方式（TCP或者
UDP）、序列化方式（XML/JSON/二進制）和通信細節。開發人員在使用的時候隻需要了解誰在什麼
位置提供了什麼樣的遠端服務接口即可，并不需要關心底層通信細節和調用過程。
1.3二者的差別與聯系
1、HTTP相對更規範，更标準，更通用，無論哪種語言都支援http協定。如果你是對外開放API，例如 開放平台，外部的程式設計語言多種多樣，你無法拒絕對每種語言的支援，現在開源中間件，基本最先支援 的幾個協定都包含RESTful。
2、 RPC 架構作為架構微服務化的基礎元件，它能大大降低架構微服務化的成本，提高調用方與服務提 供方的研發效率，屏蔽跨程序調用函數（服務）的各類複雜細節。讓調用方感覺就像調用本地函數一樣 調用遠端函數、讓服務提供方感覺就像實作一個本地函數一樣來實作服務。
2.分布式中的CAP原理
分布式中的CAP原理
1.分布式系統一定是由多個節點組成的系統。其中，節點指的是計算機伺服器，而且這些節點一般不是孤立的，而是互通的。2.這些連通的節點上部署了我們的節點，并且互相的操作會有協同。Spring Cloud:微服務基礎知識
分布式系 統的最大難點，就是各個節點的狀态如何同步。CAP 定理是這方面的基本定理，也是了解分布式系統的 起點。
CAP理論由 Eric Brewer 在ACM研讨會上提出，而後CAP被奉為分布式領域的重要理論。分布式系統的
CAP理論，首先把分布式系統中的三個特性進行了如下歸納：
通過學習CAP理論，我們得知任何分布式系統隻可同時滿足二點，沒法三者兼顧，既然一個分布式系統無法同時滿足一緻性、可用性、分區容錯性三個特點，是以我們就需要抛棄一樣：