前言

關(guān)于分布式核心知識(shí)詳解

一、分布式中的遠(yuǎn)程調(diào)用

在微服務(wù)架構(gòu)中，通常存在多個(gè)服務(wù)之間的遠(yuǎn)程調(diào)用的需求。遠(yuǎn)程調(diào)用通常包含兩個(gè)部分：序列化和通信協(xié)議。常見(jiàn)的序列化協(xié)議包括json、xml、 hession、 protobuf、thrift、text、 bytes等，目前主流的遠(yuǎn)程調(diào)用技術(shù)有基于HTTP的RESTful接口以及基于TCP的RPC協(xié)議。

1.1RESTful接口

REST，即Representational State Transfer的縮寫(xiě)，如果一個(gè)架構(gòu)符合REST原則，就稱它為RESTful架構(gòu).

---

資源（Resources ）
所謂"資源" ，就是網(wǎng)絡(luò)上的一個(gè)實(shí)體，或者說(shuō)是網(wǎng)絡(luò)上的一個(gè)具體信息。它可以是一段文本、 一張圖片、 一首歌曲、 一種服務(wù)，總之就是一個(gè)具體的實(shí)在。你可以用一個(gè)URI（統(tǒng)一資源定位符）指向它， 每種資源對(duì)應(yīng)一個(gè)特定的URI。要獲取這個(gè)資源，訪問(wèn)它的URI就可以，因此URI就成了每一個(gè)資源的地址或獨(dú)一無(wú)二的識(shí)別符。REST的名稱"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中，省略了主語(yǔ)。 “表現(xiàn)層"其實(shí)指的是"資 源”（ Resources）的 “表現(xiàn)層”。
表現(xiàn)層（Representation）
“資源"是一種信息實(shí)體，它可以有多種外在表現(xiàn)形式。我們把"資源"具體呈現(xiàn)出來(lái)的形式，叫做它的"表現(xiàn)層”（Representation）。比如，文本可以用txt格式表現(xiàn)，也可以用HTML格式、XML格式、JSON格 式表現(xiàn)，甚至可以采用二進(jìn)制格式；圖片可以用JPG格式表現(xiàn)，也可以用PNG格式表現(xiàn)。 URI只代表資源的實(shí)體，不代表它的形式。嚴(yán)格地說(shuō)，有些網(wǎng)址最后的".html"后綴名是不必要的，因?yàn)檫@個(gè)后綴名表示 格式，屬于"表現(xiàn)層"范疇，而URI應(yīng)該只代表"資源"的位置。
狀態(tài)轉(zhuǎn)化（State Transfer ）
訪問(wèn)一個(gè)網(wǎng)站，就代表了客戶端和服務(wù)器的一個(gè)互動(dòng)過(guò)程。在這個(gè)過(guò)程中，勢(shì)必涉及到數(shù)據(jù)和狀態(tài)的變化?；ヂ?lián)網(wǎng)通信協(xié)議HTTP協(xié)議，是一個(gè)無(wú)狀態(tài)協(xié)議。這意味著，所有的狀態(tài)都保存在服務(wù)器端。因此，如果客戶端想要操作服務(wù)器，必須通過(guò)某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（ State Transfer ）。 客戶端用到的手段，只能是HTTP協(xié)議。具體來(lái)說(shuō)，就是HTTP協(xié)議里面，四個(gè)表示操作方式的動(dòng)詞：GET、 POST、 PUT、 DELETE。它們分別對(duì)應(yīng)四種基本操作：GET用來(lái)獲取資源，POST用來(lái)新建資源 （也可以用于更新資源），PUT用來(lái)更新資源，DELETE用來(lái)刪除資源。

---

總結(jié)什么是RESTful架構(gòu)：

• 每一個(gè)URI代表一種資源；
• 客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；
• 客戶端通過(guò)四個(gè)HTTP動(dòng)詞，對(duì)服務(wù)器端資源進(jìn)行操作，實(shí)現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。

1.2RPC協(xié)議

RPC（ Remote Procedure Call ）一種進(jìn)程間通信方式。允許像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)。 RPC框架的主要目標(biāo)就是讓遠(yuǎn)程服務(wù)調(diào)用更簡(jiǎn)單、透明。RPC框架負(fù)責(zé)屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進(jìn)制）和通信細(xì)節(jié)。開(kāi)發(fā)人員在使用的時(shí)候只需要了解誰(shuí)在什么位置提供了什么樣的遠(yuǎn)程服務(wù)接口即可，并不需要關(guān)心底層通信細(xì)節(jié)和調(diào)用過(guò)程。

1.3區(qū)別與聯(lián)系

1、 HTTP相對(duì)更規(guī)范，更標(biāo)準(zhǔn)，更通用，無(wú)論哪種語(yǔ)言都支持http協(xié)議。如果你是對(duì)外開(kāi)放API，例如 開(kāi)放平臺(tái)，外部的編程語(yǔ)言多種多樣，你無(wú)法拒絕對(duì)每種語(yǔ)言的支持，現(xiàn)在開(kāi)源中間件，基本最先支持 的幾個(gè)協(xié)議都包含RESTful。
2、 RPC 框架作為架構(gòu)微服務(wù)化的基礎(chǔ)組件，它能大大降低架構(gòu)微服務(wù)化的成本，提高調(diào)用方與服務(wù)提 供方的研發(fā)效率，屏蔽跨進(jìn)程調(diào)用函數(shù)（服務(wù)）的各類復(fù)雜細(xì)節(jié)。讓調(diào)用方感覺(jué)就像調(diào)用本地函數(shù)一樣 調(diào)用遠(yuǎn)端函數(shù)、讓服務(wù)提供方感覺(jué)就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣來(lái)實(shí)現(xiàn)服務(wù)。

二、分布式中的CAP原理

現(xiàn)如今，對(duì)于多數(shù)大型互聯(lián)網(wǎng)應(yīng)用，分布式系統(tǒng)（distributed system）正變得越來(lái)越重要。分布式系
統(tǒng)的最大難點(diǎn)，就是各個(gè)節(jié)點(diǎn)的狀態(tài)如何同步。 CAP 定理是這方面的基本定理，也是理解分布式系統(tǒng)的起點(diǎn)。
CAP理論由 Eric Brewer 在ACM研討會(huì)上提出，而后CAP被奉為分布式領(lǐng)域的重要理論。分布式系統(tǒng)的 CAP理
論，首先把分布式系統(tǒng)中的三個(gè)特性進(jìn)行了如下歸納：

• Consistency（一致性）：數(shù)據(jù)一致更新，所有數(shù)據(jù)的變化都是同步的
• Availability（可用性）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫(xiě)請(qǐng)求
• Partition tolerance（分區(qū)容忍性）：某個(gè)節(jié)點(diǎn)的故障，并不影響整個(gè)系統(tǒng)的運(yùn)行

---

通過(guò)學(xué)習(xí)CAP理論，我們得知任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒(méi)法三者兼顧，既然一個(gè)分布 式系統(tǒng)無(wú)法同時(shí)滿足一致性、可用性、分區(qū)容錯(cuò)性三個(gè)特點(diǎn)，所以我們就需要拋棄一樣：
文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-672197.html

到了這里，關(guān)于分布式核心知識(shí)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！