RPC

遠程過程調用（Remote Procedure Call，RPC）框架作為架構微服務化的基礎組件，能大大降低架構微服務化的成本，提高服務調用方與服務提供方的開發效率，屏蔽跨進程調用函數（服務）的各類復雜細節，其調用原理如圖6-13所示。讓服務提供方像實現本地函數一樣來實現分布式服務，開發人員不用考慮底層通信協議；讓服務調用方像調用本地函數一樣調用遠端函數，多數RPC框架以面向接口的方式提供遠程方法的調用，對開發人員非常友好。

客戶端存根（client stub）用于存放服務器端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再通過網絡傳輸發送給服務器端。服務器端存根接收客戶端發送過來的請求消息并進行解包，再調用本地服務進行處理。

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

▲圖6-13　RPC框架調用原理

1．客戶端如何找到服務器端地址

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

2．服務器端如何處理請求

當使用基于RPC的進程間通信時，客戶端向服務器端發起請求，服務器端處理該請求并發回響應。有些客戶端可能處在阻塞狀態直到得到響應，而有些客戶端可能會有一個響應式的非阻塞架構。與使用消息機制的完全異步化架構不同，RPC客戶端都假定響應會及時到達。

在遠程調用中，客戶端和服務器端已經建立了網絡連接，服務器端又該如何處理客戶端的請求呢？通常來講，服務器端I/O的方式通常分為3種處理方式：同步阻塞（Blocking I/O，BIO）方式、同步非阻塞（Non-blocking I/O，NIO）方式、異步非阻塞（Asynchronous I/O，AIO）方式。

（1）同步阻塞方式。

客戶端每發一次請求，服務器端就生成一個線程去處理。當客戶端同時發起很多請求時，服務器端需要創建很多線程去處理每一個請求，如果達到了系統最大的線程數，新的請求就沒法處理了。

（2）同步非阻塞方式。

NIO本身是基于事件驅動思想來完成的，其主要解決的是BIO的高并發問題：在使用同步I/O的網絡應用中，如果要同時處理多個客戶端請求或是在客戶端同時和多個服務器進行通信，就必須使用多線程來處理。也就是說，將每一個客戶端請求分配給一個線程來單獨處理。這樣做雖然可以達到我們的要求，但同時又會帶來另一個問題。由于每創建一個線程，就要為這個線程分配一定的內存空間（也叫工作存儲器），而且操作系統本身對線程的總數有一定的限制。如果客戶端的請求過多，服務器端程序可能會因為不堪重負而拒絕客戶端的請求，甚至服務器可能因此而癱瘓。

NIO基于reactor，當socket有流可讀或可寫入socket時，操作系統會相應地通知應用程序進行處理，應用程序再將流讀取到緩沖區或寫入操作系統。也就是說，這時已經不是一個連接就要對應一個處理線程了，而是有效的請求對應一個線程。當連接沒有數據時，是沒有工作線程來處理的。BIO與NIO的一個比較重要的不同之處在于，我們使用BIO時往往會引入多線程，每個連接對應一個單獨的線程。而NIO使用單線程或者只使用少量的多線程，多個連接共用一個線程。

（3）異步非阻塞方式。

與NIO不同，當進行讀寫操作時，AIO只需直接調用API的read或write方法。這兩種方法均為異步的，對讀操作而言，當有流可讀取時，操作系統會將可讀的流傳入read方法的緩沖區，并通知應用程序；對寫操作而言，當操作系統將write方法傳遞的流寫入完畢時，操作系統主動通知應用程序。可以理解為，read/write方法都是異步的，完成后會主動調用回調函數。

客戶端只需要發起一個 I/O 操作后立即返回，等 I/O 操作真正完成以后，客戶端會得到 I/O 操作完成的通知。此時客戶端只需要對數據進行處理就可以了，而不需要進行實際的 I/O 讀寫操作，因為真正的 I/O 讀取或者寫入操作已經由內核完成了。這種方式的優勢是客戶端無須等待，不存在阻塞等待問題。

3．如何進行序列化和反序列化

客戶端和服務器端交互時將參數或結果轉化為字節流在網絡中傳輸，那么將數據轉化為字節流或者將字節流轉換成能讀取的固定格式時，就需要進行序列化（數據編碼）和反序列化（數據解碼），序列化和反序列化的速度也會影響遠程調用的效率。

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

（1）支持數據結構種類的豐富度。數據結構種類支持得越多越好，這樣對使用者來說在編程時更加友好，有些序列化框架如Hessian 2.0還支持復雜的數據結構（比如Map、List等）。

（2）跨語言支持。序列化方式是否支持跨語言也是一個很重要的因素，否則使用的場景就比較局限，比如JAVA序列化只支持Java語言，所以不能用于跨語言的服務調用。

（3）性能。主要看兩點，一是序列化后的壓縮比，二是序列化的速度。以常用的 protobuf序列化和json序列化協議為例來對比分析，protobuf序列化的壓縮比和速度都要比 json 序列化高很多，所以對性能和存儲空間要求比較高的系統選用protobuf序列化更合適；而 json 序列化雖然性能要差一些，但可讀性更好，更適合對外部提供服務。

4．如何進行網絡傳輸（選擇何種網絡協議）

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

RESTful

REST全稱是Representational State Transfer，中文意思是表述性狀態轉移。它首次出現在2000年Roy Fielding的博士論文中，Roy Fielding是HTTP規范的主要編寫者之一。他在論文中提到：“我寫作這篇文章的目的，就是想在符合架構原理的前提下，理解和評估以網絡為基礎的應用軟件的架構設計，得到一個功能強、性能好、適宜通信的架構。REST指的是一組架構約束條件和原則。”如果一個架構符合REST的約束條件和原則，我們就稱它為REST風格的（RESTful）架構。

REST提供了一系列架構約束，當作為整體使用時，它強調組件交互的可擴展性、接口的通用性、組件的獨立部署，以及那些能減少交互延遲的中間件。它強化了安全性，也能封裝遺留系統。

——Roy Fielding

REST中一個關鍵概念是“資源”，它把一切程序能夠訪問到的業務對象或者處理過程統一定義為資源。REST使用HTTP動詞來操作這些資源，并采用特定的語義規范，使用URL引用這些資源。例如，GET請求返回資源的表示形式，該資源通常采用XML或者json的格式表示，但也可以使用其他格式（如二進制）。POST請求創建新資源，PUT更新資源，DELETE刪除資源。

RESTful是一種網絡應用程序API的設計風格和開發方式，基于HTTP，可以使用XML格式定義或json格式定義。最常用的數據格式是json。由于json能直接被JavaScript讀取，因此以json格式編寫的REST風格的API具有簡單、易讀、易用的特點，如圖6-14所示。相比于RPC協議，HTTP更規范、更標準、更通用，無論哪種語言都支持HTTP。如果你想對外開放API，開放平臺外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含HTTP RESTful。

▲圖6-14　REST風格的服務提供方

前后端分離架構、微服務架構都有一個共同的愿景：使不同的團隊之間實現松耦合，各自能獨立地開發和部署。這背后需要依靠一套設計良好的API，它必須更加輕量、可靠、跨平臺，因此RESTful API脫穎而出。系統應用提供RESTful API有什么好處呢？由于API就是把Web App的功能全部封裝，因此通過API操作數據可以把前端和后端的代碼隔離，使得后端代碼易于測試，前端代碼編寫更簡單。REST風格協議的特點如下。

（1）每個統一資源標識符（Uniform Resource Identifier，URI）代表一種資源。任何事物只要有被引用的必要，它就是一個資源；要讓一個資源可以被識別，需要有一個唯一標識，在Web中這個唯一標識就是URI。

（2）客戶端使用GET、POST、PUT、DELETE這4個表示操作方式的動詞對服務器端資源進行操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。

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

（4）客戶端與服務器端之間的交互在請求之間是無狀態的，從客戶端到服務器端的每個請求都必須包含理解請求所必需的信息。這里說的無狀態通信原則，并不是說客戶端應用不能有狀態，而是指服務器端不應該保存客戶端狀態。

很多開發人員表示他們的代碼是基于HTTP的API進行開發的，那么用了HTTP就叫REST風格嗎？答案是否定的。Leonard Richardson曾提出過一個RESTful成熟度模型，模型中從level 0到level 3，數字越大，表示采用RESTful的成熟度越高，如圖6-15所示。成熟度模型并不是什么工業標準，這里僅作為參考來講解RESTful思想。讀者可以對比思考自己項目中是如何使用RESTful API的。

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

在此簡單說明RESTful成熟度模型的4個等級。

level 0：沒有明確的資源概念，僅作為通道，只有一個URL，只使用單個HTTP方法。這個階段還稱不上使用了RESTful，HTTP僅作為RPC的傳輸通道。想象一下，在本地調用某個方法時，它可能需要一個輸入對象，處理完成后返回另一個結果對象。這個階段的HTTP只是用在請求調用遠程方法時，傳遞輸入對象給服務器端，并在方法執行結束后，傳遞結果對象給客戶端。

level 1：有明確的資源概念，存在很多URL，只使用單個HTTP方法。客戶端每次請求都是對服務器端某個或某一類資源的操作。服務器端一切可被標識的事物都可以稱為資源，例如，一張圖片、一個訂單、一個產品、一個流程、最活躍的10個用戶等。每個資源都可以用URI來表示。所以從現在開始，URI用來標識一個資源。

level 2：有明確的資源操作，有很多URL，使用HTTP作為操作資源的統一接口。通常將對于資源的CRUD式操作分別映射到4個HTTP方法（有時也會使用新增的PATCH方法），這里的每一個動詞都有它自身的語義。

level 3：這一階段的RESTful API具備了自描述的能力，從而實現服務自動發現。自描述是指告訴用戶當前狀態以及下一步可能的各種操作。如果將應用想象成一個大的狀態引擎，那么我們每次針對URI的操作，都是將應用從一種狀態轉變為另一種狀態。而當前狀態（可表述的）里又包含了下一步可進行的操作，一步一步地傳輸狀態，直至完成所有的操作。一般達到level 3成熟度模型的應用，使用超媒體作為應用狀態的引擎（Hypermedia as the Engine of Application State，HATEOAS）。

REST風格具有開放、標準、通用的特點，尤其在跨語言的異構環境下系統的互聯互通具有天然的優勢。對于REST風格的應用開發模式，有兩點值得注意。

（1）RESTful API并不是十全十美的。由于HTTP是應用層協議，本身比TCP慢一些；加之數據本身是自描述的文本格式，需要占用更多的帶寬，因此相比于RPC，RESTful API的速度會稍慢一些。但是，速度可以通過技術手段彌補，例如HTTP/2、CDN、七層負載均衡等。在某些對速度要求不嚴苛的場景下，RESTful API帶來的靈活性和伸縮性更具有價值。

（2）并不是所有業務場景都適合采用RESTful API。也不是在設計API時就一定要遵守所有規則，如何取舍還要看具體業務需求，適合的才是最好的，畢竟架構也是伴隨業務的發展而不斷演進的。

優缺點對比

RPC和RESTful是目前兩種主流的微服務之間的通信協議風格，兩者各有利弊，分別適用于不同的場景。表6-2是這兩種風格的主要技術指標對比。

表6-2　RPC與RESTful兩種協議風格對比

RPC主要是基于TCP/IP的，而RESTful服務主要是基于HTTP的。HTTP是在傳輸層協議（TCP）之上的，由于RPC普遍采用二進制壓縮的序列化參數，數據傳輸量方面會比REST風格的json（或者XML）小很多。所以總的來說，從運行效率來看，RPC當然是要更勝一籌。RESTful的優勢主要體現在通用、開放、標準方面。兩者的優缺點詳細說明如下，以方便讀者在實際應用項目中進行綜合分析選擇。

（1）RPC的優點。

• 對于服務器端的開發人員而言，容易設計、開發。
• 對于消費者而言，調用非常簡單。
• 便于做集中的監控。
• 基于socket的二進制RPC協議，建立連接延遲低、網絡傳輸效率高。
• 支持有狀態的長連接，可進行雙向通信，實時性好。
• 在各個企業的使用較為成熟，許多企業都有自己的RPC實踐，并已廣泛應用在生產環節。

（2）RPC的缺點。

• 緊耦合：API一旦發布，就難以再做改動。客戶端必須使用特定的框架，而且需要引入API包。
• 沒有統一的設計風格：增加了客戶端開發人員的學習成本。難以實現通用的客戶端庫，每個RPC框架都有各自的協議。通常以動詞的形式設計API，一個功能就增加一個API，設計時很少考慮領域模型。
• 掩蓋網絡的復雜性：開發人員很容易混淆遠程調用與本地調用。實際上網絡調用與本地調用是完全不同的，RPC的調用方式，讓使用者很難意識到是在進行網絡調用，忽略了針對網絡復雜性的處理。這樣會損害用戶（客戶端）可感知的性能。

（3）RESTful API的優點。

• 使用HTTP作為應用層協議（注意：不是傳輸層），沒有耦合性。
• 可以使用瀏覽器擴展（如Postman）或者curl之類的命令行來測試RESTful API。
• 客戶端使用任意支持HTTP的工具即可。使用類似Netflix Feign這樣的專門設計的工具，可以做到接近RPC的調用方式。
• 可以方便地發布到外網環境。
• HTTP對防火墻友好，可以設置各種安全策略。
• 基于資源的設計思想，強迫設計人員抽象資源，思考模型，使設計人員加深對業務模型的理解。
• 不需要中間代理，簡化了系統架構。

（4）RESTful API的缺點。

傳統的觀念認為RESTful API不具備RPC的很多特性，不能作為企業級應用廣泛使用的API管理方式。實際上只要能夠正確實施，RESTful API也可以具備RPC 框架的許多特性。

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

基于“服務發現”和“API網關”，RESTful API服務也可以實現統一的服務注冊、服務發現，“API網關”可作為服務的統一出口，反向代理全部的底層服務，實現統一的安全控制和權限管理。

• 誤解2：RESTful API 不便于客戶端調用。

RESTful API直接使用HTTP作為應用層協議，實際上只要支持HTTP的任何工具都可以完成對RESTful API的調用，Web層也可以使用原生JavaScript或jQuery調用。

不可否認，傳統的HTTP操作庫一般只是支持HTTP隧道模式的調用方式，即把HTTP作為傳輸協議，針對媒體類型轉換也沒有特殊處理，只返回數據流或者文本數據，對資源的概念也沒有特別設計，如Apache Http Components、jQuery等。

但是目前已經有很多專門針對RESTful API編寫的客戶端調用工具，如Java的Netflix Feign、Sping RestTemplate。Feign使用基于注解的形式定義客戶端接口，框架會自動生成本地代理類，直接使用類似于本地方法調用的形式調用。Spring Cloud項目下的Spring Cloud Netflix Feign子項目結合了Spring Boot和Netflix Feign做了封裝，更便于使用。

再者在前端領域，現在成熟的前端框架都提供了Resource插件，專門用于RESTful 接口的操作，如Vue下的vue-resource，AngularJS的ng-resource等，針對RESTful API的調用以及資源導航都做了很優秀的設計。

相關書籍

企業級云原生架構 技術、服務與實踐

1.基于作者在阿里公司多年的大型項目架構設計實踐經驗，介紹云原生相關技術及產品

2.內容深入淺出，既有方法論詳述也有技術原理深入分析

3.理論與實踐并重，深入闡述云原生架構設計

4.緊貼技術趨勢，把握主流技術發展

《企業級云原生架構：技術、服務與實踐》較為全面、系統地介紹了云原生架構相關的方法論與技術產品，并結合作者多年的大型項目建設實施經驗，闡述了分布式環境下面向云原生的架構設計最佳實踐。本書主要分為4個部分，分別是云原生概述、云原生技術、云原生服務、云原生架構實踐。本書兼顧理論、技術與實踐，對從事相關行業的讀者具有很好的學習指導意義。

《企業級云原生架構：技術、服務與實踐》面向的讀者對象為互聯網行業的業務咨詢師、系統架構師，以及相關領域的技術開發人員。

作者簡介

劉景應，具有20年軟件開發、架構設計以及解決方案咨詢經驗，目前就職于阿里云云原生應用平臺，熟悉互聯網企業的技術棧與開發管理模式，對云原生相關技術、產品、架構有較為全面的理解，是國內云原生技術的先行者和布道者，致力于推動云原生相關理念和技術在國內IT應用中的落地實踐；具備豐富的大型實時在線應用系統的架構設計經驗，曾負責了多個部委以及行業頭部客戶的核心業務系統的架構咨詢與技術指導。