RPC

遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call，RPC）框架作為架構(gòu)微服務(wù)化的基礎(chǔ)組件，能大大降低架構(gòu)微服務(wù)化的成本，提高服務(wù)調(diào)用方與服務(wù)提供方的開(kāi)發(fā)效率，屏蔽跨進(jìn)程調(diào)用函數(shù)（服務(wù)）的各類(lèi)復(fù)雜細(xì)節(jié)，其調(diào)用原理如圖6-13所示。讓服務(wù)提供方像實(shí)現(xiàn)本地函數(shù)一樣來(lái)實(shí)現(xiàn)分布式服務(wù)，開(kāi)發(fā)人員不用考慮底層通信協(xié)議；讓服務(wù)調(diào)用方像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端函數(shù)，多數(shù)RPC框架以面向接口的方式提供遠(yuǎn)程方法的調(diào)用，對(duì)開(kāi)發(fā)人員非常友好。

客戶(hù)端存根（client stub）用于存放服務(wù)器端地址信息，將客戶(hù)端的請(qǐng)求參數(shù)數(shù)據(jù)信息打包成網(wǎng)絡(luò)消息，再通過(guò)網(wǎng)絡(luò)傳輸發(fā)送給服務(wù)器端。服務(wù)器端存根接收客戶(hù)端發(fā)送過(guò)來(lái)的請(qǐng)求消息并進(jìn)行解包，再調(diào)用本地服務(wù)進(jìn)行處理。

RPC的原理與我們平時(shí)打電話的過(guò)程非常相似。服務(wù)消費(fèi)者叫作客戶(hù)端，服務(wù)提供者叫作服務(wù)器端，兩者通常位于網(wǎng)絡(luò)上兩個(gè)不同的地址，要完成一次RPC調(diào)用，就必須先建立網(wǎng)絡(luò)連接。建立連接后，雙方必須按照某種約定的協(xié)議進(jìn)行網(wǎng)絡(luò)通信，這個(gè)協(xié)議就是通信協(xié)議。雙方能夠正常通信后，服務(wù)器端接收到請(qǐng)求時(shí)，需要以某種方式進(jìn)行處理，處理成功后，把請(qǐng)求結(jié)果返回給客戶(hù)端。為了減少傳輸?shù)臄?shù)據(jù)大小，要對(duì)數(shù)據(jù)進(jìn)行壓縮，也就是對(duì)數(shù)據(jù)進(jìn)行序列化。為了實(shí)現(xiàn)遠(yuǎn)程服務(wù)的調(diào)用，RPC框架要做到如下最基本的4件事。

▲圖6-13　RPC框架調(diào)用原理

1．客戶(hù)端如何找到服務(wù)器端地址

要完成一次服務(wù)調(diào)用，首先要解決的問(wèn)題是服務(wù)調(diào)用方如何得到服務(wù)提供方的地址，其中注冊(cè)中心扮演了關(guān)鍵角色，服務(wù)提供方把自己所提供的服務(wù)列表以及當(dāng)前節(jié)點(diǎn)地址登記到注冊(cè)中心，服務(wù)調(diào)用方就可以查詢(xún)注冊(cè)中心以得到服務(wù)提供方的地址。為了實(shí)現(xiàn)去中心化設(shè)計(jì)，多數(shù)RPC產(chǎn)品采用本地負(fù)載均衡策略，即調(diào)用方啟動(dòng)時(shí)從注冊(cè)中心拉取服務(wù)地址信息后，在本地緩存，運(yùn)行過(guò)程中真正發(fā)起調(diào)用時(shí)，直接從本地緩存讀取服務(wù)地址信息，根據(jù)一定的負(fù)載均衡算法選取某一個(gè)地址，發(fā)起點(diǎn)對(duì)點(diǎn)的直接調(diào)用。這樣就避免了中心化的服務(wù)總線進(jìn)行服務(wù)路由，運(yùn)行效率更高，彈性伸縮更方便。當(dāng)服務(wù)器端地址信息發(fā)生變更時(shí)（如節(jié)點(diǎn)上下線），由注冊(cè)中心實(shí)時(shí)推送變更信息到所有的調(diào)用方同步更新。

2．服務(wù)器端如何處理請(qǐng)求

當(dāng)使用基于RPC的進(jìn)程間通信時(shí)，客戶(hù)端向服務(wù)器端發(fā)起請(qǐng)求，服務(wù)器端處理該請(qǐng)求并發(fā)回響應(yīng)。有些客戶(hù)端可能處在阻塞狀態(tài)直到得到響應(yīng)，而有些客戶(hù)端可能會(huì)有一個(gè)響應(yīng)式的非阻塞架構(gòu)。與使用消息機(jī)制的完全異步化架構(gòu)不同，RPC客戶(hù)端都假定響應(yīng)會(huì)及時(shí)到達(dá)。

在遠(yuǎn)程調(diào)用中，客戶(hù)端和服務(wù)器端已經(jīng)建立了網(wǎng)絡(luò)連接，服務(wù)器端又該如何處理客戶(hù)端的請(qǐng)求呢？通常來(lái)講，服務(wù)器端I/O的方式通常分為3種處理方式：同步阻塞（Blocking I/O，BIO）方式、同步非阻塞（Non-blocking I/O，NIO）方式、異步非阻塞（Asynchronous I/O，AIO）方式。

（1）同步阻塞方式。

客戶(hù)端每發(fā)一次請(qǐng)求，服務(wù)器端就生成一個(gè)線程去處理。當(dāng)客戶(hù)端同時(shí)發(fā)起很多請(qǐng)求時(shí)，服務(wù)器端需要?jiǎng)?chuàng)建很多線程去處理每一個(gè)請(qǐng)求，如果達(dá)到了系統(tǒng)最大的線程數(shù)，新的請(qǐng)求就沒(méi)法處理了。

（2）同步非阻塞方式。

NIO本身是基于事件驅(qū)動(dòng)思想來(lái)完成的，其主要解決的是BIO的高并發(fā)問(wèn)題：在使用同步I/O的網(wǎng)絡(luò)應(yīng)用中，如果要同時(shí)處理多個(gè)客戶(hù)端請(qǐng)求或是在客戶(hù)端同時(shí)和多個(gè)服務(wù)器進(jìn)行通信，就必須使用多線程來(lái)處理。也就是說(shuō)，將每一個(gè)客戶(hù)端請(qǐng)求分配給一個(gè)線程來(lái)單獨(dú)處理。這樣做雖然可以達(dá)到我們的要求，但同時(shí)又會(huì)帶來(lái)另一個(gè)問(wèn)題。由于每創(chuàng)建一個(gè)線程，就要為這個(gè)線程分配一定的內(nèi)存空間（也叫工作存儲(chǔ)器），而且操作系統(tǒng)本身對(duì)線程的總數(shù)有一定的限制。如果客戶(hù)端的請(qǐng)求過(guò)多，服務(wù)器端程序可能會(huì)因?yàn)椴豢爸刎?fù)而拒絕客戶(hù)端的請(qǐng)求，甚至服務(wù)器可能因此而癱瘓。

NIO基于reactor，當(dāng)socket有流可讀或可寫(xiě)入socket時(shí)，操作系統(tǒng)會(huì)相應(yīng)地通知應(yīng)用程序進(jìn)行處理，應(yīng)用程序再將流讀取到緩沖區(qū)或?qū)懭氩僮飨到y(tǒng)。也就是說(shuō)，這時(shí)已經(jīng)不是一個(gè)連接就要對(duì)應(yīng)一個(gè)處理線程了，而是有效的請(qǐng)求對(duì)應(yīng)一個(gè)線程。當(dāng)連接沒(méi)有數(shù)據(jù)時(shí)，是沒(méi)有工作線程來(lái)處理的。BIO與NIO的一個(gè)比較重要的不同之處在于，我們使用BIO時(shí)往往會(huì)引入多線程，每個(gè)連接對(duì)應(yīng)一個(gè)單獨(dú)的線程。而NIO使用單線程或者只使用少量的多線程，多個(gè)連接共用一個(gè)線程。

（3）異步非阻塞方式。

與NIO不同，當(dāng)進(jìn)行讀寫(xiě)操作時(shí)，AIO只需直接調(diào)用API的read或write方法。這兩種方法均為異步的，對(duì)讀操作而言，當(dāng)有流可讀取時(shí)，操作系統(tǒng)會(huì)將可讀的流傳入read方法的緩沖區(qū)，并通知應(yīng)用程序；對(duì)寫(xiě)操作而言，當(dāng)操作系統(tǒng)將write方法傳遞的流寫(xiě)入完畢時(shí)，操作系統(tǒng)主動(dòng)通知應(yīng)用程序。可以理解為，read/write方法都是異步的，完成后會(huì)主動(dòng)調(diào)用回調(diào)函數(shù)。

客戶(hù)端只需要發(fā)起一個(gè) I/O 操作后立即返回，等 I/O 操作真正完成以后，客戶(hù)端會(huì)得到 I/O 操作完成的通知。此時(shí)客戶(hù)端只需要對(duì)數(shù)據(jù)進(jìn)行處理就可以了，而不需要進(jìn)行實(shí)際的 I/O 讀寫(xiě)操作，因?yàn)檎嬲?I/O 讀取或者寫(xiě)入操作已經(jīng)由內(nèi)核完成了。這種方式的優(yōu)勢(shì)是客戶(hù)端無(wú)須等待，不存在阻塞等待問(wèn)題。

3．如何進(jìn)行序列化和反序列化

客戶(hù)端和服務(wù)器端交互時(shí)將參數(shù)或結(jié)果轉(zhuǎn)化為字節(jié)流在網(wǎng)絡(luò)中傳輸，那么將數(shù)據(jù)轉(zhuǎn)化為字節(jié)流或者將字節(jié)流轉(zhuǎn)換成能讀取的固定格式時(shí)，就需要進(jìn)行序列化（數(shù)據(jù)編碼）和反序列化（數(shù)據(jù)解碼），序列化和反序列化的速度也會(huì)影響遠(yuǎn)程調(diào)用的效率。

常用的序列化方式分為兩類(lèi)：文本類(lèi)（如XML、json等）、二進(jìn)制類(lèi)（如Hessian、Thrift等）。而具體采用哪種序列化方式，主要取決于3個(gè)方面的因素。

（1）支持?jǐn)?shù)據(jù)結(jié)構(gòu)種類(lèi)的豐富度。數(shù)據(jù)結(jié)構(gòu)種類(lèi)支持得越多越好，這樣對(duì)使用者來(lái)說(shuō)在編程時(shí)更加友好，有些序列化框架如Hessian 2.0還支持復(fù)雜的數(shù)據(jù)結(jié)構(gòu)（比如Map、List等）。

（2）跨語(yǔ)言支持。序列化方式是否支持跨語(yǔ)言也是一個(gè)很重要的因素，否則使用的場(chǎng)景就比較局限，比如JAVA序列化只支持Java語(yǔ)言，所以不能用于跨語(yǔ)言的服務(wù)調(diào)用。

（3）性能。主要看兩點(diǎn)，一是序列化后的壓縮比，二是序列化的速度。以常用的 protobuf序列化和json序列化協(xié)議為例來(lái)對(duì)比分析，protobuf序列化的壓縮比和速度都要比 json 序列化高很多，所以對(duì)性能和存儲(chǔ)空間要求比較高的系統(tǒng)選用protobuf序列化更合適；而 json 序列化雖然性能要差一些，但可讀性更好，更適合對(duì)外部提供服務(wù)。

4．如何進(jìn)行網(wǎng)絡(luò)傳輸（選擇何種網(wǎng)絡(luò)協(xié)議）

多數(shù)RPC框架會(huì)選擇TCP作為傳輸協(xié)議，也有部分會(huì)選擇HTTP（如gRPC使用HTTP/2）。不同的協(xié)議各有利弊，TCP更加高效，而HTTP在實(shí)際應(yīng)用中更加靈活。

RESTful

REST全稱(chēng)是Representational State Transfer，中文意思是表述性狀態(tài)轉(zhuǎn)移。它首次出現(xiàn)在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規(guī)范的主要編寫(xiě)者之一。他在論文中提到：“我寫(xiě)作這篇文章的目的，就是想在符合架構(gòu)原理的前提下，理解和評(píng)估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計(jì)，得到一個(gè)功能強(qiáng)、性能好、適宜通信的架構(gòu)。REST指的是一組架構(gòu)約束條件和原則。”如果一個(gè)架構(gòu)符合REST的約束條件和原則，我們就稱(chēng)它為REST風(fēng)格的（RESTful）架構(gòu)。

REST提供了一系列架構(gòu)約束，當(dāng)作為整體使用時(shí)，它強(qiáng)調(diào)組件交互的可擴(kuò)展性、接口的通用性、組件的獨(dú)立部署，以及那些能減少交互延遲的中間件。它強(qiáng)化了安全性，也能封裝遺留系統(tǒng)。

——Roy Fielding

REST中一個(gè)關(guān)鍵概念是“資源”，它把一切程序能夠訪問(wèn)到的業(yè)務(wù)對(duì)象或者處理過(guò)程統(tǒng)一定義為資源。REST使用HTTP動(dòng)詞來(lái)操作這些資源，并采用特定的語(yǔ)義規(guī)范，使用URL引用這些資源。例如，GET請(qǐng)求返回資源的表示形式，該資源通常采用XML或者json的格式表示，但也可以使用其他格式（如二進(jìn)制）。POST請(qǐng)求創(chuàng)建新資源，PUT更新資源，DELETE刪除資源。

RESTful是一種網(wǎng)絡(luò)應(yīng)用程序API的設(shè)計(jì)風(fēng)格和開(kāi)發(fā)方式，基于HTTP，可以使用XML格式定義或json格式定義。最常用的數(shù)據(jù)格式是json。由于json能直接被JavaScript讀取，因此以json格式編寫(xiě)的REST風(fēng)格的API具有簡(jiǎn)單、易讀、易用的特點(diǎn)，如圖6-14所示。相比于RPC協(xié)議，HTTP更規(guī)范、更標(biāo)準(zhǔn)、更通用，無(wú)論哪種語(yǔ)言都支持HTTP。如果你想對(duì)外開(kāi)放API，開(kāi)放平臺(tái)外部的編程語(yǔ)言多種多樣，你無(wú)法拒絕對(duì)每種語(yǔ)言的支持，現(xiàn)在開(kāi)源中間件，基本最先支持的幾個(gè)協(xié)議都包含HTTP RESTful。

▲圖6-14　REST風(fēng)格的服務(wù)提供方

前后端分離架構(gòu)、微服務(wù)架構(gòu)都有一個(gè)共同的愿景：使不同的團(tuán)隊(duì)之間實(shí)現(xiàn)松耦合，各自能獨(dú)立地開(kāi)發(fā)和部署。這背后需要依靠一套設(shè)計(jì)良好的API，它必須更加輕量、可靠、跨平臺(tái)，因此RESTful API脫穎而出。系統(tǒng)應(yīng)用提供RESTful API有什么好處呢？由于API就是把Web App的功能全部封裝，因此通過(guò)API操作數(shù)據(jù)可以把前端和后端的代碼隔離，使得后端代碼易于測(cè)試，前端代碼編寫(xiě)更簡(jiǎn)單。REST風(fēng)格協(xié)議的特點(diǎn)如下。

（1）每個(gè)統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifier，URI）代表一種資源。任何事物只要有被引用的必要，它就是一個(gè)資源；要讓一個(gè)資源可以被識(shí)別，需要有一個(gè)唯一標(biāo)識(shí)，在Web中這個(gè)唯一標(biāo)識(shí)就是URI。

（2）客戶(hù)端使用GET、POST、PUT、DELETE這4個(gè)表示操作方式的動(dòng)詞對(duì)服務(wù)器端資源進(jìn)行操作：GET用來(lái)獲取資源，POST用來(lái)新建資源（也可以用于更新資源），PUT用來(lái)更新資源，DELETE用來(lái)刪除資源。

（3）通過(guò)操作資源的表述形式來(lái)操作資源，資源在外部的具體呈現(xiàn)可以有多種表述形式（例如文本資源可以采用html、XML、json等格式，圖片可以使用PNG或JPG格式展現(xiàn)出來(lái)），在客戶(hù)端和服務(wù)器端之間傳送的也是資源的表述，而不是資源本身。

（4）客戶(hù)端與服務(wù)器端之間的交互在請(qǐng)求之間是無(wú)狀態(tài)的，從客戶(hù)端到服務(wù)器端的每個(gè)請(qǐng)求都必須包含理解請(qǐng)求所必需的信息。這里說(shuō)的無(wú)狀態(tài)通信原則，并不是說(shuō)客戶(hù)端應(yīng)用不能有狀態(tài)，而是指服務(wù)器端不應(yīng)該保存客戶(hù)端狀態(tài)。

很多開(kāi)發(fā)人員表示他們的代碼是基于HTTP的API進(jìn)行開(kāi)發(fā)的，那么用了HTTP就叫REST風(fēng)格嗎？答案是否定的。Leonard Richardson曾提出過(guò)一個(gè)RESTful成熟度模型，模型中從level 0到level 3，數(shù)字越大，表示采用RESTful的成熟度越高，如圖6-15所示。成熟度模型并不是什么工業(yè)標(biāo)準(zhǔn)，這里僅作為參考來(lái)講解RESTful思想。讀者可以對(duì)比思考自己項(xiàng)目中是如何使用RESTful API的。

▲圖6-15　Leonard Richardson提出的RESTful成熟度模型

在此簡(jiǎn)單說(shuō)明RESTful成熟度模型的4個(gè)等級(jí)。

level 0：沒(méi)有明確的資源概念，僅作為通道，只有一個(gè)URL，只使用單個(gè)HTTP方法。這個(gè)階段還稱(chēng)不上使用了RESTful，HTTP僅作為RPC的傳輸通道。想象一下，在本地調(diào)用某個(gè)方法時(shí)，它可能需要一個(gè)輸入對(duì)象，處理完成后返回另一個(gè)結(jié)果對(duì)象。這個(gè)階段的HTTP只是用在請(qǐng)求調(diào)用遠(yuǎn)程方法時(shí)，傳遞輸入對(duì)象給服務(wù)器端，并在方法執(zhí)行結(jié)束后，傳遞結(jié)果對(duì)象給客戶(hù)端。

level 1：有明確的資源概念，存在很多URL，只使用單個(gè)HTTP方法?？蛻?hù)端每次請(qǐng)求都是對(duì)服務(wù)器端某個(gè)或某一類(lèi)資源的操作。服務(wù)器端一切可被標(biāo)識(shí)的事物都可以稱(chēng)為資源，例如，一張圖片、一個(gè)訂單、一個(gè)產(chǎn)品、一個(gè)流程、最活躍的10個(gè)用戶(hù)等。每個(gè)資源都可以用URI來(lái)表示。所以從現(xiàn)在開(kāi)始，URI用來(lái)標(biāo)識(shí)一個(gè)資源。

level 2：有明確的資源操作，有很多URL，使用HTTP作為操作資源的統(tǒng)一接口。通常將對(duì)于資源的CRUD式操作分別映射到4個(gè)HTTP方法（有時(shí)也會(huì)使用新增的PATCH方法），這里的每一個(gè)動(dòng)詞都有它自身的語(yǔ)義。

level 3：這一階段的RESTful API具備了自描述的能力，從而實(shí)現(xiàn)服務(wù)自動(dòng)發(fā)現(xiàn)。自描述是指告訴用戶(hù)當(dāng)前狀態(tài)以及下一步可能的各種操作。如果將應(yīng)用想象成一個(gè)大的狀態(tài)引擎，那么我們每次針對(duì)URI的操作，都是將應(yīng)用從一種狀態(tài)轉(zhuǎn)變?yōu)榱硪环N狀態(tài)。而當(dāng)前狀態(tài)（可表述的）里又包含了下一步可進(jìn)行的操作，一步一步地傳輸狀態(tài)，直至完成所有的操作。一般達(dá)到level 3成熟度模型的應(yīng)用，使用超媒體作為應(yīng)用狀態(tài)的引擎（Hypermedia as the Engine of Application State，HATEOAS）。

REST風(fēng)格具有開(kāi)放、標(biāo)準(zhǔn)、通用的特點(diǎn)，尤其在跨語(yǔ)言的異構(gòu)環(huán)境下系統(tǒng)的互聯(lián)互通具有天然的優(yōu)勢(shì)。對(duì)于REST風(fēng)格的應(yīng)用開(kāi)發(fā)模式，有兩點(diǎn)值得注意。

（1）RESTful API并不是十全十美的。由于HTTP是應(yīng)用層協(xié)議，本身比TCP慢一些；加之?dāng)?shù)據(jù)本身是自描述的文本格式，需要占用更多的帶寬，因此相比于RPC，RESTful API的速度會(huì)稍慢一些。但是，速度可以通過(guò)技術(shù)手段彌補(bǔ)，例如HTTP/2、CDN、七層負(fù)載均衡等。在某些對(duì)速度要求不嚴(yán)苛的場(chǎng)景下，RESTful API帶來(lái)的靈活性和伸縮性更具有價(jià)值。

（2）并不是所有業(yè)務(wù)場(chǎng)景都適合采用RESTful API。也不是在設(shè)計(jì)API時(shí)就一定要遵守所有規(guī)則，如何取舍還要看具體業(yè)務(wù)需求，適合的才是最好的，畢竟架構(gòu)也是伴隨業(yè)務(wù)的發(fā)展而不斷演進(jìn)的。

優(yōu)缺點(diǎn)對(duì)比

RPC和RESTful是目前兩種主流的微服務(wù)之間的通信協(xié)議風(fēng)格，兩者各有利弊，分別適用于不同的場(chǎng)景。表6-2是這兩種風(fēng)格的主要技術(shù)指標(biāo)對(duì)比。

表6-2　RPC與RESTful兩種協(xié)議風(fēng)格對(duì)比

RPC主要是基于TCP/IP的，而RESTful服務(wù)主要是基于HTTP的。HTTP是在傳輸層協(xié)議（TCP）之上的，由于RPC普遍采用二進(jìn)制壓縮的序列化參數(shù)，數(shù)據(jù)傳輸量方面會(huì)比REST風(fēng)格的json（或者XML）小很多。所以總的來(lái)說(shuō)，從運(yùn)行效率來(lái)看，RPC當(dāng)然是要更勝一籌。RESTful的優(yōu)勢(shì)主要體現(xiàn)在通用、開(kāi)放、標(biāo)準(zhǔn)方面。兩者的優(yōu)缺點(diǎn)詳細(xì)說(shuō)明如下，以方便讀者在實(shí)際應(yīng)用項(xiàng)目中進(jìn)行綜合分析選擇。

（1）RPC的優(yōu)點(diǎn)。

• 對(duì)于服務(wù)器端的開(kāi)發(fā)人員而言，容易設(shè)計(jì)、開(kāi)發(fā)。
• 對(duì)于消費(fèi)者而言，調(diào)用非常簡(jiǎn)單。
• 便于做集中的監(jiān)控。
• 基于socket的二進(jìn)制RPC協(xié)議，建立連接延遲低、網(wǎng)絡(luò)傳輸效率高。
• 支持有狀態(tài)的長(zhǎng)連接，可進(jìn)行雙向通信，實(shí)時(shí)性好。
• 在各個(gè)企業(yè)的使用較為成熟，許多企業(yè)都有自己的RPC實(shí)踐，并已廣泛應(yīng)用在生產(chǎn)環(huán)節(jié)。

（2）RPC的缺點(diǎn)。

• 緊耦合：API一旦發(fā)布，就難以再做改動(dòng)?？蛻?hù)端必須使用特定的框架，而且需要引入API包。
• 沒(méi)有統(tǒng)一的設(shè)計(jì)風(fēng)格：增加了客戶(hù)端開(kāi)發(fā)人員的學(xué)習(xí)成本。難以實(shí)現(xiàn)通用的客戶(hù)端庫(kù)，每個(gè)RPC框架都有各自的協(xié)議。通常以動(dòng)詞的形式設(shè)計(jì)API，一個(gè)功能就增加一個(gè)API，設(shè)計(jì)時(shí)很少考慮領(lǐng)域模型。
• 掩蓋網(wǎng)絡(luò)的復(fù)雜性：開(kāi)發(fā)人員很容易混淆遠(yuǎn)程調(diào)用與本地調(diào)用。實(shí)際上網(wǎng)絡(luò)調(diào)用與本地調(diào)用是完全不同的，RPC的調(diào)用方式，讓使用者很難意識(shí)到是在進(jìn)行網(wǎng)絡(luò)調(diào)用，忽略了針對(duì)網(wǎng)絡(luò)復(fù)雜性的處理。這樣會(huì)損害用戶(hù)（客戶(hù)端）可感知的性能。

（3）RESTful API的優(yōu)點(diǎn)。

• 使用HTTP作為應(yīng)用層協(xié)議（注意：不是傳輸層），沒(méi)有耦合性。
• 可以使用瀏覽器擴(kuò)展（如Postman）或者curl之類(lèi)的命令行來(lái)測(cè)試RESTful API。
• 客戶(hù)端使用任意支持HTTP的工具即可。使用類(lèi)似Netflix Feign這樣的專(zhuān)門(mén)設(shè)計(jì)的工具，可以做到接近RPC的調(diào)用方式。
• 可以方便地發(fā)布到外網(wǎng)環(huán)境。
• HTTP對(duì)防火墻友好，可以設(shè)置各種安全策略。
• 基于資源的設(shè)計(jì)思想，強(qiáng)迫設(shè)計(jì)人員抽象資源，思考模型，使設(shè)計(jì)人員加深對(duì)業(yè)務(wù)模型的理解。
• 不需要中間代理，簡(jiǎn)化了系統(tǒng)架構(gòu)。

（4）RESTful API的缺點(diǎn)。

傳統(tǒng)的觀念認(rèn)為RESTful API不具備RPC的很多特性，不能作為企業(yè)級(jí)應(yīng)用廣泛使用的API管理方式。實(shí)際上只要能夠正確實(shí)施，RESTful API也可以具備RPC 框架的許多特性。

• 誤解1：RESTful API 不便于集中管理。

基于“服務(wù)發(fā)現(xiàn)”和“API網(wǎng)關(guān)”，RESTful API服務(wù)也可以實(shí)現(xiàn)統(tǒng)一的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)，“API網(wǎng)關(guān)”可作為服務(wù)的統(tǒng)一出口，反向代理全部的底層服務(wù)，實(shí)現(xiàn)統(tǒng)一的安全控制和權(quán)限管理。

• 誤解2：RESTful API 不便于客戶(hù)端調(diào)用。

RESTful API直接使用HTTP作為應(yīng)用層協(xié)議，實(shí)際上只要支持HTTP的任何工具都可以完成對(duì)RESTful API的調(diào)用，Web層也可以使用原生JavaScript或jQuery調(diào)用。

不可否認(rèn)，傳統(tǒng)的HTTP操作庫(kù)一般只是支持HTTP隧道模式的調(diào)用方式，即把HTTP作為傳輸協(xié)議，針對(duì)媒體類(lèi)型轉(zhuǎn)換也沒(méi)有特殊處理，只返回?cái)?shù)據(jù)流或者文本數(shù)據(jù)，對(duì)資源的概念也沒(méi)有特別設(shè)計(jì)，如Apache Http Components、jQuery等。

但是目前已經(jīng)有很多專(zhuān)門(mén)針對(duì)RESTful API編寫(xiě)的客戶(hù)端調(diào)用工具，如Java的Netflix Feign、Sping RestTemplate。Feign使用基于注解的形式定義客戶(hù)端接口，框架會(huì)自動(dòng)生成本地代理類(lèi)，直接使用類(lèi)似于本地方法調(diào)用的形式調(diào)用。Spring Cloud項(xiàng)目下的Spring Cloud Netflix Feign子項(xiàng)目結(jié)合了Spring Boot和Netflix Feign做了封裝，更便于使用。

再者在前端領(lǐng)域，現(xiàn)在成熟的前端框架都提供了Resource插件，專(zhuān)門(mén)用于RESTful 接口的操作，如Vue下的vue-resource，AngularJS的ng-resource等，針對(duì)RESTful API的調(diào)用以及資源導(dǎo)航都做了很優(yōu)秀的設(shè)計(jì)。

相關(guān)書(shū)籍

企業(yè)級(jí)云原生架構(gòu) 技術(shù)、服務(wù)與實(shí)踐

1.基于作者在阿里公司多年的大型項(xiàng)目架構(gòu)設(shè)計(jì)實(shí)踐經(jīng)驗(yàn)，介紹云原生相關(guān)技術(shù)及產(chǎn)品

2.內(nèi)容深入淺出，既有方法論詳述也有技術(shù)原理深入分析

3.理論與實(shí)踐并重，深入闡述云原生架構(gòu)設(shè)計(jì)

4.緊貼技術(shù)趨勢(shì)，把握主流技術(shù)發(fā)展

《企業(yè)級(jí)云原生架構(gòu)：技術(shù)、服務(wù)與實(shí)踐》較為全面、系統(tǒng)地介紹了云原生架構(gòu)相關(guān)的方法論與技術(shù)產(chǎn)品，并結(jié)合作者多年的大型項(xiàng)目建設(shè)實(shí)施經(jīng)驗(yàn)，闡述了分布式環(huán)境下面向云原生的架構(gòu)設(shè)計(jì)最佳實(shí)踐。本書(shū)主要分為4個(gè)部分，分別是云原生概述、云原生技術(shù)、云原生服務(wù)、云原生架構(gòu)實(shí)踐。本書(shū)兼顧理論、技術(shù)與實(shí)踐，對(duì)從事相關(guān)行業(yè)的讀者具有很好的學(xué)習(xí)指導(dǎo)意義。

《企業(yè)級(jí)云原生架構(gòu)：技術(shù)、服務(wù)與實(shí)踐》面向的讀者對(duì)象為互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)咨詢(xún)師、系統(tǒng)架構(gòu)師，以及相關(guān)領(lǐng)域的技術(shù)開(kāi)發(fā)人員。

作者簡(jiǎn)介

劉景應(yīng)，具有20年軟件開(kāi)發(fā)、架構(gòu)設(shè)計(jì)以及解決方案咨詢(xún)經(jīng)驗(yàn)，目前就職于阿里云云原生應(yīng)用平臺(tái)，熟悉互聯(lián)網(wǎng)企業(yè)的技術(shù)棧與開(kāi)發(fā)管理模式，對(duì)云原生相關(guān)技術(shù)、產(chǎn)品、架構(gòu)有較為全面的理解，是國(guó)內(nèi)云原生技術(shù)的先行者和布道者，致力于推動(dòng)云原生相關(guān)理念和技術(shù)在國(guó)內(nèi)IT應(yīng)用中的落地實(shí)踐；具備豐富的大型實(shí)時(shí)在線應(yīng)用系統(tǒng)的架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，曾負(fù)責(zé)了多個(gè)部委以及行業(yè)頭部客戶(hù)的核心業(yè)務(wù)系統(tǒng)的架構(gòu)咨詢(xún)與技術(shù)指導(dǎo)。