面試造飛機(jī)系列：看架構(gòu)師如何設(shè)計(jì)微服務(wù)接口

來(lái)自：后端技術(shù)學(xué)堂

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

這篇文章主要介紹什么是 REST 風(fēng)格設(shè)計(jì)以及 RESTful 接口。閱讀完本文你將收獲以下知識(shí)點(diǎn)：

• 什么是 REST 和 RESTful
• REST 接口設(shè)計(jì)規(guī)范是什么
• REST 為什么要設(shè)計(jì)成無(wú)狀態(tài)
• 接口無(wú)狀態(tài)真的是沒(méi)有狀態(tài)嗎
• RPC 和 REST 適用場(chǎng)景

REST和RESTful

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

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

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

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

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

表述性

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

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

URI  是統(tǒng)一資源標(biāo)識(shí)符，用來(lái)唯一的標(biāo)識(shí)一個(gè)資源。

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

URN  統(tǒng)一資源命名，是通過(guò)名字來(lái)標(biāo)識(shí)資源。URN也是 URI 的子集。

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

資源表述性

為了說(shuō)明「資源描述性」接口設(shè)計(jì)的優(yōu)點(diǎn)，我們來(lái)做一個(gè)接口設(shè)計(jì)方法的對(duì)比，舉個(gè)栗子就清楚了。

傳統(tǒng)的接口設(shè)計(jì)

先來(lái)看下傳統(tǒng)的網(wǎng)絡(luò)通信模式是怎么樣的。假設(shè)lemon這個(gè)人物對(duì)象，在服務(wù)端的存儲(chǔ)形式是一個(gè)c++的class類型存儲(chǔ)。

下面的過(guò)程展示，客戶端發(fā)送請(qǐng)求服務(wù)端創(chuàng)建一個(gè) lemon 對(duì)象的過(guò)程。

1. 服務(wù)端定義存儲(chǔ)結(jié)構(gòu)頭文件 lemon.h

     

      

       

       

       

       

       

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

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

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

     

      

       

       

       

       

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

4. 服務(wù)端接收消息，反序列化，存儲(chǔ)傳輸過(guò)來(lái)的 lemon 對(duì)象

資源表述性接口設(shè)計(jì)

lemon 這個(gè)服務(wù)內(nèi)部的對(duì)象，對(duì)外表現(xiàn)可以用一張圖片來(lái)表示，也可以用包含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>

也就是說(shuō)，lemon 這個(gè)「資源」在服務(wù)內(nèi)部的存放形式對(duì)外不可見(jiàn)，外界客戶端發(fā)起請(qǐng)求可以用不同的資源表述格式來(lái)獲取服務(wù)端的資源。

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

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

狀態(tài)轉(zhuǎn)移

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

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

REST的約束條件

協(xié)議選擇

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

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

請(qǐng)求規(guī)范

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

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

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

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ī)范的寫(xiě)法：

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)碼

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

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

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

無(wú)狀態(tài)

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

無(wú)狀態(tài)不是真的沒(méi)有狀態(tài)

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

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

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

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

技術(shù)方案

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

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

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

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

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

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

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

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

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

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

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

REST 和 RPC

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

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

回顧下RPC

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

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

適用場(chǎng)景

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

RESTful接口由于提供了統(tǒng)一的基于 HTTP的 REST 設(shè)計(jì)標(biāo)準(zhǔn)，只需 web 框架支持 HTTP 協(xié)議，并設(shè)計(jì)RESTful 風(fēng)格的接口即可，極大的方便了第三方服務(wù)接入調(diào)用，「適合用于微服務(wù)系統(tǒng)對(duì)外暴露的接口設(shè)計(jì)標(biāo)準(zhǔn)」

寫(xiě)在最后

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

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

今天的技術(shù)分享就到這里，本文是后端開(kāi)發(fā)微服務(wù)設(shè)計(jì)系列的第二篇，這個(gè)系列應(yīng)該還會(huì)繼續(xù)更新，我想到了再寫(xiě)，我們下期再見(jiàn)。