架構雜談《九》

架構雜談《九》

微服務與輕量級通訊機制

　　微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間胡亮協調、互相配合，爲用戶提供最終價值。在微服務架構中，服務與服務之間通訊時，一般是經過輕量級的通訊機制，實現彼此間的互通互聯、互相協做。所謂輕量級通訊機制，一般是指與語言無關、與平臺無關的這類協議。經過輕量級通訊機制，使服務與服務之間的協做變得簡單、標準化。

一、同步通訊與異步通訊

　　1.1概述

　　微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務。所以，微服務架構本質上分佈式系統。

　　相比傳統的單機系統，因爲服務和數據分佈在不一樣的節點上，每次交互都須要跨節點與運行，這使得網絡成爲微服務架構實施考慮的必要因素之一。

　　1.2 同步通訊與異步通訊的選擇

　　　　同步通訊是指當客戶端發出請求後，在服務端處理未結束前，客戶端一直處於等待狀態，直到最終得到服務端的響應。

　　　　異步通訊則是指當客戶端發出請求後，服務端或者第三方組件會先接受消息並應答，而後在合適的時間對請求進行處理。在這中間。客戶端不須要一直處於等待狀態。

二、遠程調用RPC

　　RPC（Remote Procedure Call）又稱遠程過程調用。是一種典型的分佈式節點間同步通訊的實現方式。遠程過程調用採用客戶端/服務端的模式，請求的發起者是客戶端，提供響應的是服務器端。

　　百度百科

　　客戶端經過客戶代理存根（Stub），傳遞函數參數，向服務器端發起函數調用。服務器端經過服務器代理存根（Skeleton），接受到客戶端的請求後，對請求進行處理。並在結束後向客戶端返回響應，從而完成一次通訊。

　　2.1遠程過程調用的核心

　　　　遠程過程調用採用客戶端/服務器端模式。請求的發起者是客戶端，提供響應的是服務器端。客戶端與服務器端的交互模式圖以下：

　　　　　一、首先，客戶端調用本地代理存根，發送請求到服務器端，等待應答信息

　　　　　二、在服務器端，服務代理處於睡眠狀態，直到客戶端請求到達並將其喚醒

　　　　    三、服務代理得到請求參數後，交由服務器的服務代碼對其進行處理

　　　　　四、應用程序處理結束後，由服務代理向客戶端發送應答，等待下一次請求

　　　　　五、客戶端代理存根接收應答信息，交給客戶端的調用代碼進行處理。

　　2.2遠程方法調用

　　　　傳統的遠程過程調用框架主要包括 Sun RPC、DCE/RPC，主要基於C語言實現，以函數調用爲主。

　　　　隨着面嚮對象語言的快速發展，序列化/反序列化等特性的誕生。基於不一樣語言的遠程過程調用框架開始提供對象遠程訪問的功能，如 Thrift、protocol buffers等，同傳統的遠程過程調用框架相比，有一類框架可以容許客戶端經過面向對象的調用方式，調用遠端的實現。咱們稱這類調用爲遠程方法調用，換句話說 遠程方法調用是遠程過程調用的一種面向對象的實現。

　　2.3 RPC的弊端

　　　　　　RPC 經過 使用代理存根（Stub/Skeleton）的方式，屏蔽了通訊雙發底層的調用細節，讓客戶端沒必要顯式地區分當前代碼級別的方法調用是本地調用仍是遠程調用。所以使分佈式節點間的通訊變得簡單。可是，雖然RPC 的調用機制屏蔽了調用的細節，簡化了調用流程。但其也存在着弊端。

　　　　　　1：耦合度高

　　　　　　2：靈活性差

三、REST

　　3.1 REST 概述

　　　　REST（Representation State Transfer）（表述性狀態傳遞）是這幾年使用較普遍的分佈式節點間通訊的實現方式，REST 從語義層面將響應結果定義爲資源，並使用HTTP的標準動詞映射爲對資源的操做，造成了一種以資源爲核心、以HTTP爲操做方式的，與語言無關、平臺無關的服務間通訊機制。

　　　　百度百科

　　3.2 REST的核心

　　

　　　　資源：（Resource）是一種抽象的概念，是指對某類信息實體的抽象。實體是指服務器端須要處理的具體信息，它能夠是一段文本、一種圖片也能夠是文件系統中的一個文件、數據庫中的一張表等。與面向對象設計中的概念相似，資源一般以名詞爲核心來定義，每一個資源對應一個特色的URI做爲標識。

　　　　表述：（Representation）資源的表述是對資源在某個特定時刻的狀態的描述。資源是一種信息實體，實體在客戶端與服務器端進行信息交換時，能夠有多種表現形式，如：文本能夠用TXT格式表現，也能夠用HTML格式、XML格式、JSON格式表現，甚至能夠採用二進制格式；圖片能夠用JPG格式標識也能夠用PNG格式表現。這種資源的表述格式在客戶端與服務器端經過請求-響應的協商機制來肯定。實際上，URI 僅表明資源的實體，並不表明它的表述。如：有些URL最後的.html 後綴名並屬於表述範疇，表述應該在HTTP請求的頭信息中用 Accept和Content-Type 字段來指定。這兩個字段纔是對「表述」的描述。

　　　　狀態轉移：（State Transfer）是指在客戶端同服務端交互的過程當中。客戶端可以經過資源的表述，實現操做資源的目的。當咱們使用瀏覽器訪問一個網站時，就表明了客戶端和服務器端的一個交互過程。在這個過程當中，必然會涉及數據或者狀態的變化。可是咱們知道HTTP是一個無狀態的協議。這意味着，全部的狀態都保存在服務器端。所以，若是客戶端想要操做資源，必須經過某種手段，讓服務器端發生狀態的轉移。而這種轉移是創建在資源的表述上的。因此一般將其稱爲表述層狀態轉移。

　　　　統一接口：（Uniform Interface）客戶端操做資源的方式，一般是基於HTTP的4個動詞（Verb）：GET、POST、PUT、DELETE。它們分別對應4種資源的操做方式。

　　　　　　GET：用來獲取資源

　　　　　　POST：用來新建資源

　　　　　　PUT：用來更新資源

　　　　　　DELETE：用來銷燬資源

　　　　由於客戶端是經過HTTP的這4個動詞操做資源的。也就意味着無論請求的URI是什麼，請求的資源有什麼不一樣，但操做資源的接口都是統一的。

　　3.3 REST的優點

　　　　經過資源表述、狀態轉移以及統一接口，REST 將客戶端的請求、服務器端的響應基於資源聯繫起來，逐漸造成了一種以資源爲核心、以HTTP爲操做方式的、與語言無關、平臺無關的通訊機制。同時，因爲HTTP自己的無狀態性，使用REST，可以有效保持服務/應用的無狀態性，利於未來的水平伸縮。

　　3.4 REST的不足

　　　　隨着團隊或者組織業務的不斷增加，服務器端響應內容複雜度的增長，REST的使用面臨以下的挑戰：

　　　　　　1：如何標準化資源結構

　　　　　　2：如何處理資源的相關連接

　　　　3.4.1 如何標準化資源結構

　　　　　　使用REST能夠將業務場景的具體信息定義爲資源。並基於JSON或者XML返回給客戶端，隨着業務的不斷增加，邏輯的增長，服務器端對內容的響應結構會變得愈來愈複雜（所謂響應結構，是指服務器端的響應內容結構，既資源的結構）

　　　　　　REST做爲指導性的原則，並無定義服務器端響應結構應該遵循什麼標準。這也就意味着在企業內部、不一樣的部門、不一樣的開發小組，對同一類資源所定義的結構可能不一樣，所以如何定義一套標準的資源響應結構，成爲服務數量增多後使用的REST面臨的一個挑戰。

　　　　3.4.2 如何有效處理相關資源的連接

　　　　　　大部分REST的實現，都是基於 JSON 做爲傳輸格式，但 JSON最大的遺憾在於沒有對超連接處理作內置的支持，而這部分卻偏偏是 Web 的基石，這帶來的潛在問題是，對於調用接口的客戶端而言，每次須要查看相關的接口文檔，才能瞭解如何修改資源的狀態，或者獲取相關聯資源的信息。所以，如何用有效的方式管理REST中相關資源的依賴以及連接，是否可以將這種方式標準化，成爲服務數量增多後使用REST面臨的另外一個挑戰。

　　　　3.4.3 其餘須要考慮的因素

　　　　　　性能：

　　　　　　　　因爲REST 是基於 HTTP 之上的協議，而HTTP自己是一個使用普遍的、基於TCP/IP的應用層協議，所以 REST 並非低延時通訊的最好選擇。對於服務之間對低延時要求的場景，可能須要選擇不一樣的底層協議，如UDP 來達到但願的性能，或者其餘RPC框架

　　　　　　開發成本：

　　　　　　　　使用REST，其傳輸格式是XML或者JSON的文本格式，在享受平臺無關、語言無關優點的同時，團隊須要編寫更多的代碼來解析文本格式的協議，不過目前已經有不少成熟的庫幫助咱們來作相似的事情，如 Java下解決 JSON的 JSON-lib、org.json 以及 C# 下的 Newtonsoft.Json

說明：

　　一、參考書籍：《分佈式服務架構：原理、設計與實戰》《微服務架構與實踐》

　　二、若有不合適的地方請反饋。綜合後更改。

 

原文出處：https://www.cnblogs.com/haoxiaozhang/p/11304021.html