1、SOA與微服務的關系

可以先了解下分布式與微服務系列（一）、軟體架構的演化程序
SOA（Service Oriented Architecture） 面向服務的架構：它是一種設計方法，其中包含多個服務，服務之間通過相互依賴最終提供一系列的功能，一個服務通常以獨立的形式存在于作業系統行程中，各個服務之間通過網路來呼叫，

**微服務架構：**其實和SOA架構類似，微服務是在SOA架構上做了升華，微服務架構強調的衣蛾重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分成多個可以獨立開發的、設計、運行的小應用，這些小應用之間通過服務呼叫完成互動和集成，

SOA架構與微服務的異同點對比：

2、常見微服務架構

2.1、SpringCloud

SpringCloud是一系列框架的有序集合，它利用SpringBoot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，如服務發現與注冊、配置中心、訊息總堆疊、負載均衡、斷路器、資料監控等，都可以用SpringBoot的開發風格做到一鍵啟動和部署，SpringCloud并沒有重復制造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了復雜的配置和實作原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包，

2.2、ServiceComb

Apache ServiceComb是業界第一個Apache微服務頂級專案，是一個開源微服務解決方案，致力于幫助企業、用戶和開發者將企業應用輕松微服務化，并實作對微服務應用的高效運維管理，其提供一站式開源微服務解決方案，融合SDK框架級，0侵入ServiceMech場景并支持多語言，

2.3、ZeroC ICE

ZeroC IceGrid 是ZeroC公司的杰作，繼承了CORBA的血統，是新一代的面向物件的分布式系統中間
件，作為一種微服務架構，它基于RPC框架發展而來，具有良好的性能與分布式能力，

3、微服務中的相關概念

3.1、服務注冊與發現

• 服務注冊

  服務實體將自身服務資訊注冊到注冊中心，，這部分服務資訊，包括服務所在主機IP和提供服務的port，以及暴露服務自身的狀態以及訪問協議等資訊，

• 服務發現

  服務實體請求注冊中心獲取所依賴的服務資訊，服務實體通過注冊中心，獲取到注冊到其中的服務實體資訊，通過這些資訊去請求它們提供的服務，

3.2、負載均衡

負載均衡是高可用網路基礎架構的關鍵組件，通常用于將作業負載分布到多個服務器來提高網站、應用、資料庫或其他服務的性能和可靠性，

3.3、熔斷

熔斷這一概念來源于電子工程中的斷路器（Circuit Breaker），在互聯網系統中，當下游服務因訪問壓力過大而回應變慢或失敗，上游服務為了保護系統整體的可用性，可以暫時切斷對下游服務的呼叫，這種犧牲區域，保全整體的措施就叫做熔斷，

3.4、鏈路追蹤

隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務，互聯網應用構建在不同的軟體模塊集上，這些軟體模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實作、有可能分布到幾千臺服務器上，橫跨多個不同的資料中心，因此就需要對一次請求涉及到的多個服務鏈路進行日志記錄，性能監控即鏈路追蹤，

3.5、API網關

隨著微服務的不斷增多，不同的微服務一般會有不同的網路地址，而外部的客戶端可能需要調動多個服務的介面才能完成一個業務需求，如果讓客戶端直接與各個微服務進行通信，可能會出現以下情況：

• 客戶端需要呼叫不同的url地址，增加難度
• 在一定的場景下，存在跨域請求的問題
• 每個微服務都需要進行單獨的身份驗證

針對這些問題，API網關順勢而生，

API網關字面意思是將所有API呼叫統一接入到API網關層，由網關層統一接入和管理，一個網關的基本功能有：統一接入、安全防護、協議適配、流量管控、長短連接支持、容錯能力、有了網關之后，各個API服務提供團隊可以專注于自己的業務邏輯處理，而API網關更專注于安全、流量、路由等問題，

4、分布式核心知識

4.1、分布式中的遠程呼叫

在微服務架構中，通常存在多個服務之間的遠程呼叫的需求，遠程呼叫通產包括兩個部分：序列化和通信協議，常見的序列化協議包括json、xml、hession、protoful、thrift、text、bytes等，目前主流的遠程呼叫技術有基于HTTP的Restful介面以及基于TCP的RPC協議，

4.1.1、RESTful介面

REST，即Representational State Transfer的縮寫，如果一個架構符合REST原則，就稱它為RESTful架構，

資源（Resources）

所謂“資源”，就是網路上的一個物體，或者說是網路上的一個具體資訊，它可以是一段文本、一張圖片、一首歌手、一種服務、一首歌曲、一種服務，總之就是一個具體的實在，你可以用一個URL（統一資源定位符）指向它，每種資源對應一個特定的URL，要獲取這個資源，訪問它的URL就可以，因此URL就成了每一個資源的地址或獨一無二的識別符，REST的名稱“表現層狀態轉化”中，省略了主語，“表現層”其實指的是“資源”（REsources）的“表現層”，

表現層（Representation）

資源是一種資訊物體，它可以有多中外在表現形式，我們把"資源"具體呈現出來的形式，叫做它的“表現層”（Representation），比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以采用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現，URL只代表資源的物體，不代表它的形式，嚴格地說，有些網址最后的“.html”后綴名是不必要的，因為這個后綴名表示格式，屬于“表現層”范疇，而URL應該只代表“資源”的位置，

狀態轉化（State Transfer）

訪問一個網站，就代表客戶端和服務器端的一個互動程序，在這個程序中，勢必涉及到資料和狀態的變化，互聯網通信協議HTTP協議，是一個無狀態協議，這就意味著，所有的狀態都保存再服務器端，因此如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生“狀態變化”（State Transfer），客戶端用到的手段、只能是HTTP協議，具體來說，就是HTTP協議里面，四個表示操作方式的動詞，GET、POST、PUT、DELETE，
它們分別對應四種基本操作：

• GET用來獲取資源
• POST用來新建資源（也可以用來更新資源）
• PUT用來更新資源
• DELETE用來洗掉資源

綜上所述，可以將RESTful架構總結為如下幾方面：

• 每一個URL代表一種資源
• 客戶端和服務器之間，傳遞這種資源的某種表現層
• 客戶端通過四個HTTP動詞，對服務器資源進行操作，實作“表現層狀態轉化”

4.1.2、RPC協議

**RPC（Remote Procedure Call）**一種行程間的通信方式，允許像呼叫本地服務一樣呼叫遠程服務，RPC框架的主要目標就是讓遠程服務呼叫更簡單、透明，RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二級制）和通信細節，開發人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務介面即可，并不需要關心底層通信細節和呼叫程序，

RPC作業原理圖（底層基于socket）：

4.1.3、RESTful與RPC的區別與聯系

總結：

• HTTP相對更規范，更標準，更通用，無論哪種語言都支持http協議，如果你是對外開放的API介面，eg：開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在的開源中間件，基本最先支持的幾個協議都包含RESTful，
• PRC框架作為架構微服務化的組件，它能大大降低微服務話的成本，提高呼叫方與服務提供方的研發效率，屏蔽跨行程呼叫函式（服務）的各類復雜細節，讓呼叫方感覺就像呼叫本地函式一樣呼叫遠程服務端函式、讓服務提供方感覺就像實作一個本地函式一樣來實作服務，

4.2、分布式中的CAP原理

現如今，對應多數大型互聯網應用，分布式系統（distributed system）正變得越來越重要，分布式系統的最大難點，就是各個節點的狀態如何同步，CAP定理是這方面的基本定理，也是理解分布式系統的起點，

CAP理論由Eric Brewer在ACM研討會上提出，而后CAP被奉為分布式領域的重要理論，分布式系統的CAP理論，首先把分布式系統中的三個特性進行了如下歸納：

• Consistency（一致性）：

  所有節點資料一致更新，所有資料的變化都是同步的，

• Availability（可用性）：

  在集群中一部分節點故障后，集群整體是否還能回應客戶端的讀寫請求，

• Partition tolerance（磁區容忍性）：

  某個節點的故障，并不影響整個系統的運行，是否可以將資料存放到多個地方，

通過學習CAP理論，我們得知任何分布式系統只可同時滿足兩點，沒法三者兼顧，既然一個分布式系統無法同時滿足一致性、可用性、磁區容錯性三個特點，素有我們就需要拋棄一樣：

解釋說明：