面試造飛機系列：看架構師如何設計微服務接口

來自：后端技術學堂

本文是后端微服務架構系列的第二篇文章。在微服務設計中，服務間接口通信設計常見的有兩種方式：RPC  和 REST，關于微服務和 RPC  的更多細節(jié)，可以參考我上一篇文章 面試都在問的微服務，一文帶你徹底搞懂！

這篇文章主要介紹什么是 REST 風格設計以及 RESTful 接口。閱讀完本文你將收獲以下知識點：

• 什么是 REST 和 RESTful
• REST 接口設計規(guī)范是什么
• REST 為什么要設計成無狀態(tài)
• 接口無狀態(tài)真的是沒有狀態(tài)嗎
• RPC 和 REST 適用場景

REST和RESTful

REST（Representational State Transfer，表述性狀態(tài)轉移） 是一種軟件架構風格。REST提出了一組架構約束條件和原則，任何滿足 REST 約束條件和原則的架構，都稱為 RESTful 架構。

微服務之間需要相互通信以完成特定的業(yè)務處理，在典型的客戶端-服務端設計模型中，客戶端和服務端通通過消息請求-響應的方式交互協(xié)作，REST 就是這樣一套微服務之間交互接口的設計約束和原則規(guī)范。

乍一看 REST「表述性狀態(tài)轉移」每個字都認得，連起來不知道什么意思。

這是作者 Roy Thomas Fielding 在他的博士論文里提出的概念，論文自然都是學術用語，不過感興趣的同學可以去看看作者論文原文，地址我貼出來：https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

今天 lemon 用大白話幫你透徹理解這個概念，我們把「表述性狀態(tài)轉移」掰開來看，先搞明白什么是「表述性」，什么是「狀態(tài)轉移」。

表述性

「表述性」其實是缺少了主語的，主語是「資源」。完整的描述是「資源表述性」，也就是「資源的描述」。在網(wǎng)絡通信中用什么描述資源呢？沒錯就是 URI（Uniform Resource Identifier，統(tǒng)一資源標識符）。

這里有幾個近義詞先給大家先科普一下：

URI  是統(tǒng)一資源標識符，用來唯一的標識一個資源。

URL 是統(tǒng)一資源定位器，它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明了如何定位這個資源，URL 是 URI 的子集。

URN  統(tǒng)一資源命名，是通過名字來標識資源。URN也是 URI 的子集。

在 HTTP 協(xié)議中用 URL 標識資源，也就是瀏覽器地址欄你看到的那一串網(wǎng)址。

資源表述性

為了說明「資源描述性」接口設計的優(yōu)點，我們來做一個接口設計方法的對比，舉個栗子就清楚了。

傳統(tǒng)的接口設計

先來看下傳統(tǒng)的網(wǎng)絡通信模式是怎么樣的。假設lemon這個人物對象，在服務端的存儲形式是一個c++的class類型存儲。

下面的過程展示，客戶端發(fā)送請求服務端創(chuàng)建一個 lemon 對象的過程。

1. 服務端定義存儲結構頭文件 lemon.h

     

      

       

       

       

       

       

      
      
class lemon{ string name; string address; uint64 phone;}
     

2. 客戶端代碼引用服務端定義的lemon.h，「互相引用頭文件，增加了服務耦合性！」

3. 客戶端初始化一個 lemon 實例并序列化后通過網(wǎng)絡接口發(fā)送給服務端。

     

      

       

       

       

       

      
      
class lemon lm;lm.name = "lemon";lm.address = "Shenzhen";lm.phone = 18666666666;
     

4. 服務端接收消息，反序列化，存儲傳輸過來的 lemon 對象

資源表述性接口設計

lemon 這個服務內(nèi)部的對象，對外表現(xiàn)可以用一張圖片來表示，也可以用包含lemon 的姓名、地址、電話等信息的 xml 或 json 格式的數(shù)據(jù)表示。

{name : "lemon",address: "ShenZhen",phone : 18666666666}

<?xml version="1.0" encoding="UTF-8" ?> <name>lemon</name> <address>ShenZhen</address> <phone>18666666666</phone>

也就是說，lemon 這個「資源」在服務內(nèi)部的存放形式對外不可見，外界客戶端發(fā)起請求可以用不同的資源表述格式來獲取服務端的資源。

（如果服務器會說話，他內(nèi)心os 大概是這樣的:  客戶端你不用管我是如何保存這個對象的，只要你說的清楚想要什么對象，只管發(fā)來請求便是?。?/p>

這樣做最顯然的好處是，減少了服務之間的耦合?？蛻舳嗽L問服務資源之前不需要知道資源在服務端的具體存儲格式，只需描述資源形式即可修改、創(chuàng)建、更新、刪除服務端的資源。

狀態(tài)轉移

搞懂了「資源描述性」接下來看下什么是「狀態(tài)轉移」？狀態(tài)轉移就是客戶端通過一系列請求動作，推動服務端的資源狀態(tài)發(fā)生變化，資源的狀態(tài)可以在「創(chuàng)建-修改-查看-刪除」之間轉移。

資源狀態(tài)的變化在宏觀上的反應就是業(yè)務流程推進。打個比方，你去銀行系統(tǒng)開戶、查余額、銷戶，這個過程你推動了你的銀行賬戶這個「資源」經(jīng)歷了不同的狀態(tài)轉移讓你完成了不同的業(yè)務操作。

REST的約束條件

協(xié)議選擇

REST 本身并沒有提到底層應該使用什么協(xié)議，日常實踐案例中最常用的是基于 HTTP 的 RESTful 實現(xiàn)。

這是因為 HTTP 協(xié)議自帶的動詞 GET/POST/PUT/DELETE 可以作為推動狀態(tài)轉移的方法，另外HTTP 的制定了規(guī)范的狀態(tài)碼。還有其他的一些 HTTP 特性，這些特性使得在HTTP 之上實現(xiàn) REST 要簡單得多，而如果使用其他協(xié)議的話，就需要自己實現(xiàn)這些特性。

請求規(guī)范

RESTful 架構中，發(fā)生狀態(tài)轉換的是「資源」，所以URI 中一般只能包含代表「資源」的名詞，并且推薦是復數(shù)，而不應該在 URI 中包對資源進行操作的動詞。

對資源執(zhí)行的CURD「增刪改查」動作應該在HTTP請求方法的GET/POST/PUT/DELETE中體現(xiàn)。

符合REST規(guī)范的寫法：

POST http://www.test.com/lemon // 創(chuàng)建Get http://www.test.com/lemon // 查詢PUT http://www.test.com/lemon // 修改DELETE http://www.test.com/lemon //刪除

不符合REST規(guī)范的寫法：

POST http://www.test.com/Createlemon // 創(chuàng)建POST http://www.test.com/Querylemon // 查詢POST http://www.test.com/Modifylemon // 修改POST http://www.test.com/Deletelemon //刪除

狀態(tài)碼

服務端消息響應攜帶狀態(tài)碼，指示客戶端進行下一步處理。符合 RESTful 規(guī)范的接口返回狀態(tài)碼都是通用的，不需要額外約定，利用HTTP Status Code 狀態(tài)碼 表示請求處理結果，降低了微服務間互操作成本。

下面是常見的HTTP狀態(tài)碼：

• 200 - 請求成功
• 301 - 資源（網(wǎng)頁等）被永久轉移到其它URL
• 404 - 請求的資源（網(wǎng)頁等）不存在
• 500 - 內(nèi)部服務器錯誤

無狀態(tài)

RESTful接口要求是「無狀態(tài)」。無狀態(tài)指的是任意一個Web請求必須完全與其他請求隔離，當客戶端發(fā)起請求時，消息本身包含了服務端識別這一請求上下文所需的全部信息。

無狀態(tài)不是真的沒有狀態(tài)

接口「無狀態(tài)」更確切的說是服務端無狀態(tài)，整個會話還是需要狀態(tài)維持的。要完成一個業(yè)務流程，一般客戶端與服務端需要多次的消息交互，我們知道HTTP 協(xié)議是「無狀態(tài)協(xié)議」，這就需要服務端能夠識別幾個獨立 HTTP 請求的「狀態(tài)信息」，從而將他們關聯(lián)到一個業(yè)務流程中。

還是舉例子銀行系統(tǒng)取款的例子：

• 用戶lemon要登錄銀行系統(tǒng)，首先需要在登錄頁面輸入用戶名和密碼，這時候產(chǎn)生一個登錄請求
• 服務端收到登錄請求，執(zhí)行登錄邏輯并返回操作結果
• lemon登錄之后點擊取款100萬，產(chǎn)生一個取款請求
• 服務端收到取款請求，執(zhí)行取款邏輯并返回操作結果

這里有個問題，服務端在不同時間點收到登錄請求和取款請求，這兩個請求都是用戶 lemon 產(chǎn)生的，如果不在技術層面做對獨立的 HTTP 請求做關聯(lián)的話，服務端就無法知道這兩個請求其實是都是用戶lemon 「取款業(yè)務」的組成部分。

技術方案

服務端要能識別請求的「狀態(tài)信息」，有兩種技術方案：

1. Session 方式。服務端保存會話狀態(tài)，客戶端每次請求攜帶session-id。

   服務端維護一個會話狀態(tài)信息列表，用session-id唯一標識一個狀態(tài)信息，session-id一般包含在HTTP響應的Set-Cookie頭部返回給客戶端，后續(xù)客戶端請求攜帶包含session-id信息的cookie頭部，服務端解析cookie取出session-id，去維護的狀態(tài)列表中取回該消息對應的狀態(tài)信息，這樣就把無狀態(tài)的HTTP變成有狀態(tài)的了。

2. Token 方式。服務端不保存會話狀態(tài)，客戶端每次請求都攜帶完整的會話狀態(tài)信息（一般是加密的）給服務端。

   Token也稱作是「令牌」或臨時證書簽名，狀態(tài)信息都被加密到token中，這樣每當服務器收到請求后解密token就能獲取該請求對應的狀態(tài)信息，也就能把不同的請求消息關聯(lián)到同一個業(yè)務流程中來，和session方式有類似的效果，只不過這次的狀態(tài)信息不保存在服務端。

以上兩種實現(xiàn)中，第一種 Session 方式是有狀態(tài)的，第二種 Token 方式是無狀態(tài)的。

如果你要實現(xiàn) RESTful 接口最好按第二種技術方案實現(xiàn)，當然要實現(xiàn)無狀態(tài)也還有其他方式，思路都是「服務端不保持會話狀態(tài)」就對了。

為什么要無狀態(tài)

為了高可用性和負載均衡需求，多個微服務通過負載均衡實現(xiàn)分布式集群化部署，集群中每個服務都是獨立和對等的。如果服務器在收到客戶端請求之時不可用或者宕機，無狀態(tài)請求可以由任何其他可用服務器處理并作出應答，這在分布式應用中非常重要。

想象一下如果服務端保存狀態(tài)，一個事務內(nèi)的每個請求都必須落到同一臺服務器去處理，這就失去了分布式的意義和優(yōu)勢。

所以， RESTful 接口要求是無狀態(tài)的，是為了更好的適應分布式業(yè)務場景，發(fā)揮微服務集群優(yōu)勢。

REST 和 RPC

這兩個概念經(jīng)常出現(xiàn)在微服務架構設計中，REST 是一種軟件架構接口設計風格，RPC 是一種計算機通信協(xié)議，看起來是兩個不同的概念，沒法比較。

但是有些書中把它們放在一起比較，真要比較的話，我個人傾向于把 REST 具體化為一種基于HTTP 并按照 REST 約束設計的通信協(xié)議，這樣兩個通信協(xié)議才有比較性。

回顧下RPC

RPC (Remote Procedure Call)遠程過程調用是一個計算機通信協(xié)議。我們一般的程序調用是本地程序內(nèi)部的調用，RPC允許你像調用本地函數(shù)一樣去調用另一個程序的函數(shù)，這中間會涉及網(wǎng)絡通信和進程間通信，但你無需知道實現(xiàn)細節(jié)，RPC框架為你屏蔽了底層實現(xiàn)。

RPC 是一種服務器-客戶端Client/Server模式，經(jīng)典實現(xiàn)是一個通過發(fā)送請求-接受回應進行信息交互的系統(tǒng)。

適用場景

很多 RPC 框架提供的消息傳輸都是基于二進制的，比如Thrift、Protocol buffers。這樣做的好處是消息結構比較緊湊，對于頻繁調用或者大流量、低時延要求的應用場景，能夠顯著減少網(wǎng)絡開銷；另一個約束是某些 RPC 框架有很強的技術耦合性，比如 Dubbo 只能用于 java 技術棧。綜上，RPC 「更加適用于系統(tǒng)內(nèi)部微服務之間的高效通信」

RESTful接口由于提供了統(tǒng)一的基于 HTTP的 REST 設計標準，只需 web 框架支持 HTTP 協(xié)議，并設計RESTful 風格的接口即可，極大的方便了第三方服務接入調用，「適合用于微服務系統(tǒng)對外暴露的接口設計標準」

寫在最后

本文是微服務架構設計中接口選型的一個小方面，很多人會覺得現(xiàn)在工作面試，不管是大廠還是小公司，都是面試造飛機，工作擰螺絲。個人認為即使你在入職之后接觸不到架構方面的工作，也要有一顆架構的心，高度決定認知，如果只盯著手上的那顆螺絲那和咸魚有什么區(qū)別？

老規(guī)矩。感謝各位的閱讀，文章的目的是分享對知識的理解，技術類文章我都會反復求證以求最大程度保證準確性，若文中出現(xiàn)明顯紕漏也歡迎指出，我們一起在探討中學習。

今天的技術分享就到這里，本文是后端開發(fā)微服務設計系列的第二篇，這個系列應該還會繼續(xù)更新，我想到了再寫，我們下期再見。