微服務基礎知識

1 微服務基礎知識

1.1 系統架構的演變

隨著網際網路的發展，網站應用的規模不斷擴大，常規的應用架構已無法應對，分散式服務架構以及微服
務架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

1.1.1 單體應用架構

Web應用程式發展的早期，大部分web工程(包含前端頁面,web層程式碼,service層程式碼,dao層程式碼)是將
所有的功能模組,打包到一起並放在一個web容器中執行。

比如搭建一個電商系統：客戶下訂單，商品展示，使用者管理。這種將所有功能都部署在一個web容器中
執行的系統就叫做單體架構。
優點：
所有的功能整合在一個專案工程中
專案架構簡單，前期開發成本低，週期短，小型專案的首選。
缺點：
全部功能整合在一個工程中，對於大型專案不易開發、擴充套件及維護。
系統效能擴充套件只能通過擴充套件叢集結點，成本高、有瓶頸。
技術棧受限。

1.1.2 垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提
升效率

優點：
專案架構簡單，前期開發成本低，週期短，小型專案的首選。
通過垂直拆分，原來的單體專案不至於無限擴大
不同的專案可採用不同的技術。
缺點：
全部功能整合在一個工程中，對於大型專案不易開發、擴充套件及維護。
系統效能擴充套件只能通過擴充套件叢集結點，成本高、有瓶頸。

1.1.3 分散式SOA架構

1.1.3.1 什麼是SOA

SOA 全稱為 Service-Oriented Architecture，即面向服務的架構。它可以根據需求通過網路對鬆散耦合
的粗粒度應用元件(服務)進行分散式部署、組合和使用。一個服務通常以獨立的形式存在於作業系統進
程中。
站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生，目
的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速複用。
通過上面的描述可以發現 SOA 有如下幾個特點：分散式、可重用、擴充套件靈活、鬆耦合

1.1.3.2 SOA架構

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定
的服務
中心，使前端應用能更快速的響應多變的市場需求

優點：
抽取公共的功能為服務,提高開發效率
對不同的服務進行叢集化部署解決系統壓力
基於ESB/DUBBO減少系統耦合
缺點：
抽取服務的粒度較大
服務提供方與呼叫方介面耦合度較高

1.1.4 微服務架構

優點：
通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付週期將縮短，運維成
本也將大幅度下降
微服務遵循單一原則。微服務之間採用Restful等輕量協議傳輸。
缺點：
微服務過多，服務治理成本高，不利於系統維護。
分散式系統開發的技術成本高（容錯、分散式事務等）。

1.1.5 SOA與微服務的關係

SOA（ Service Oriented Architecture ）“面向服務的架構”:他是一種設計方法，其中包含多個服
務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在與作業系統程式
中。各個服務之間 通過網路呼叫。
微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的昇華，微服務架構強調的一個重點是“業務需
要徹底的元件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、執行的小應用。
這些小應用之間通過服務完成互動和整合。

1.2 分散式核心知識

1.2.1 分散式中的遠端呼叫

在微服務架構中，通常存在多個服務之間的遠端呼叫的需求。遠端呼叫通常包含兩個部分：序列化和通
信協議。常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的
遠端呼叫技術有基於HTTP的RESTful介面以及基於TCP的RPC協議。
（1）RESTful介面
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動詞，對伺服器端資源進行操作，實現”表現層狀態轉化”。
（2）RPC協議
RPC（Remote Procedure Call ） 一種程式間通訊方式。允許像呼叫本地服務一樣呼叫遠端服務。RPC
框架的主要目標就是讓遠端服務呼叫更簡單、透明。RPC框架負責遮蔽底層的傳輸方式（TCP或者
UDP）、序列化方式（XML/JSON/二進位制）和通訊細節。開發人員在使用的時候只需要瞭解誰在什麼
位置提供了什麼樣的遠端服務介面即可，並不需要關心底層通訊細節和呼叫過程。

1、HTTP相對更規範，更標準，更通用，無論哪種語言都支援http協議。如果你是對外開放API，例如
開放平臺，外部的程式語言多種多樣，你無法拒絕對每種語言的支援，現在開源中介軟體，基本最先支援
的幾個協議都包含RESTful。
2、 RPC 框架作為架構微服務化的基礎元件，它能大大降低架構微服務化的成本，提高呼叫方與服務提
供方的研發效率，遮蔽跨程式呼叫函式（服務）的各類複雜細節。讓呼叫方感覺就像呼叫本地函式一樣
呼叫遠端函式、讓服務提供方感覺就像實現一個本地函式一樣來實現服務。

1.2.2 分散式中的CAP原理

現如今，對於多數大型網際網路應用，分散式系統（distributed system）正變得越來越重要。分散式系
統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分散式系統的
起點。
CAP理論由Eric Brewer 在ACM研討會上提出，而後CAP被奉為分散式領域的重要理論。分散式系統的
CAP理論，首先把分散式系統中的三個特性進行了如下歸納：

Consistency（一致性）：資料一致更新，所有資料的變化都是同步的
Availability（可用性）：在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求
Partition tolerance（分割槽容忍性）：某個節點的故障，並不影響整個系統的執行
通過學習CAP理論，我們得知任何分散式系統只可同時滿足二點，沒法三者兼顧，既然一個分佈
式系統無法同時滿足一致性、可用性、分割槽容錯性三個特點，所以我們就需要拋棄一樣：

1.3 常見微服務框架

1.3.1 SpringCloud

本作品採用《CC 協議》，轉載必須註明作者和本文連結