RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。
RPC採用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，然後等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息到達為止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答覆信息，然後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，獲得進程結果，然後調用執行繼續進行。
有多種 RPC模式和執行。最初由 Sun 公司提出。IETF ONC 憲章重新修訂了 Sun 版本，使得 ONC RPC 協議成為 IETF 標準協議。現在使用最普遍的模式和執行是開放式軟件基礎的分佈式計算環境（DCE）。
在支付系統的微服務架構中，基礎服務的構建是重中之重， 本文重點分析如何使用Apache Thrift + Google Protocol Buffer來構建基礎服務。
一、RPC vs Restful
在微服務中，使用什麼協議來構建服務體系，一直是個熱門話題。 爭論的焦點集中在兩個候選技術： (binary) RPC or Restful。
- 以Apache Thrift為代表的二進制RPC，支持多種語言（但不是所有語言），四層通訊協議，性能高，節省帶寬。相對Restful協議，使用Thrifpt RPC，在同等硬件條件下，帶寬使用率僅為前者的20%，性能卻提升一個數量級。但是這種協議最大的問題在於，無法穿透防火牆。
- 以Spring Cloud為代表所支持的Restful 協議，優勢在於能夠穿透防火牆，使用方便，語言無關，基本上可以使用各種開發語言實現的系統，都可以接受Restful 的請求。 但性能和帶寬佔用上有劣勢。
所以，業內對微服務的實現，基本是確定一個組織邊界，在該邊界內，使用RPC; 邊界外，使用Restful。這個邊界，可以是業務、部門，甚至是全公司。
二、 RPC技術選型
RPC技術選型上，原則也是選擇自己熟悉的，或者公司內部內定的框架。 如果是新業務，則現在可選的框架其實也不多，卻也足夠讓人糾結。
Apache Thrift
國外用的多，源於facebook，後捐獻給Apache基金。是Apache的頂級項目 Apache Thrift。使用者包括facebook, Evernote, Uber, Pinterest等大型互聯網公司。 而在開源界，Apache hadoop/hbase也在使用Thrift作為內部通訊協議。 這是目前最為成熟的框架，優點在於穩定、高性能。缺點在於它僅提供RPC服務，其他的功能，包括限流、熔斷、服務治理等，都需要自己實現，或者使用第三方軟件。
Dubbo
國內用的多，源於阿里公司。 性能上略遜於Apache Thrift，但自身集成了大量的微服務治理功能，使用起來相當方便。 Dubbo的問題在於，該系統目前已經很長時間沒有維護更新了。 官網顯示最近一次的更新也是8個月前。
Google Protobuf
和Apache Thrift類似，Google Protobuf也包括數據定義和服務定義兩部分。問題是，Google Protobuf一直只有數據模型的實現，沒有官方的RPC服務的實現。 直到2015年才推出gRPC，作為RPC服務的官方實現。但缺乏重量級的用戶。
以上僅做定性比較。定量的對比，網上有不少資料，可自行查閱。 此外，還有一些不錯的RPC框架，比如Zeroc ICE等，不在本文的比較範圍。
Thrift 提供多種高性能的傳輸協議，但在數據定義上，不如Protobuf強大。
- 同等格式數據， Protobuf壓縮率和序列化/反序列化性能都略高。
- Protobuf支持對數據進行自定義標註，並可以通過API來訪問這些標註，這使得Protobuf在數據操控上非常靈活。比如可以通過option來定義protobuf定義的屬性和數據庫列的映射關係，實現數據存取。
- 數據結構升級是常見的需求，Protobuf在支持數據向下兼容上做的非常不錯。只要實現上處理得當，接口在升級時，老版本的用戶不會受到影響。
而Protobuf的劣勢在於其RPC服務的實現性能不佳（gRPC）。為此，Apache Thrift + Protobuf的RPC實現，成為不少公司的選擇。
三、Apache Thrift + Protobuf
如上所述，利用Protobuf在靈活數據定義、高性能的序列化/反序列化、兼容性上的優勢，以及Thrift在傳輸上的成熟實現，將兩者結合起來使用，是不少互聯網公司的選擇。
服務定義：
service HelloService{
binary hello(1: binary hello_request);
}
協議定義：
message HelloRequest{
optional string user_name = 1; //訪問這個接口的用戶
optional string password = 2; //訪問這個接口的密碼
optional string hello_word = 3; //其他參數；
}
message HelloResponse{
optional string hello_word = 1; //訪問這個接口的用戶
}
想對於純的thrift實現，這種方式雖然看起來繁瑣，但其在可擴展性、可維護性和服務治理上，可以帶來不少便利。
四、服務註冊與發現
Spring cloud提供了服務註冊和發現功能，如果需要自己實現，可以考慮使用Apache Zookeeper作為註冊表，使用Apache Curator 來管理Zookeeper的鏈接，它實現如下功能：
- 偵聽註冊表項的變化，一旦有更新，可以重新加載註冊表。
- 管理到zookeeper的鏈接，如果出現問題，則進行重試。
Curator的重試策略是可配置的，提供如下策略：
BoundedExponentialBackoffRetry
ExponentialBackoffRetry
RetryForever
RetryNTimes
RetryOneTime
RetryUntilElapsed
一般使用指數延遲策略，比如重試時間間隔為1s，2s, 4s, 8s……指數增加，避免把服務器打死。
對服務註冊來說，註冊表結構需要詳細設計，一般註冊表結構會按照如下方式組織：
機房區域-部門-服務類型-服務名稱-服務器地址
由於在zookeeper上的註冊和發現有一定的延遲，所以在實現上也得注意，當服務啟動成功後，才能註冊到zookeeper上；當服務要下線或者重啟前，需要先斷開同zookeeper的連接，再停止服務。
五、連接池
RPC服務訪問和數據庫類似，建立鏈接是一個耗時的過程，連接池是服務調用的標配。目前還沒有成熟的開源Apache Thrift鏈接池，一般互聯網公司都會開發內部自用的鏈接池。自己實現可以基於JDBC鏈接池做改進，比如參考Apache commons DBCP鏈接池，使用Apache Pools來管理鏈接。 在接口設計上，連接池需要管理的是RPC 的Transport:
public interface TransportPool {
/**
* 獲取一個transport
* @return
* @throws TException
*/
public TTransport getTransport() throws TException;}
連接池實現的主要難點在於如何從多個服務器中選舉出來為當前調用提供服務的連接。比如目前有10臺機器在提供服務，上一次分配的是第4臺服務器，本次應該分配哪一臺？在實現上，需要收集每臺機器的QOS以及當前的負擔，分配一個最佳的連接。
六、API網關
隨著公司業務的增長，RPC服務越來越多，這也為服務調用帶來挑戰。如果有一個應用需要調用多個服務，對這個應用來說，就需要維護和多個服務器之間的鏈接。服務的重啟，都會對連接池以及客戶端的訪問帶來影響。為此，在微服務中，廣泛會使用到API網關。API網關可以認為是一系列服務集合的訪問入口。從面向對象設計的角度看，它與外觀模式類似，實現對所提供服務的封裝。
網關作用
API網關本身不提供服務的具體實現，它根據請求，將服務分發到具體的實現上。 其主要作用：
- API路由： 接受到請求時，將請求轉發到具體實現的worker機器上。避免使用方建立大量的連接。
- 協議轉換： 原API可能使用http或者其他的協議來實現的，統一封裝為rpc協議。注意，這裡的轉換，是批量轉換。也就是說，原來這一組的API是使用http實現的，現在要轉換為RPC，於是引入網關來統一處理。對於單個服務的轉換，還是單獨開發一個Adapter服務來執行。
- 封裝公共功能： 將微服務治理相關功能封裝到網關上，簡化微服務的開發，這包括熔斷、限流、身份驗證、監控、負載均衡、緩存等。
- 分流：通過控制API網關的分發策略，可以很容易實現訪問的分流，這在灰度測試和AB測試時特別有用。
解耦合
RPC API網關在實現上，難點在於如何做到服務無關。我們知道使用Nginx實現HTTP的路由網關，可以實現和服務無關。而RPC網關由於實現上的不規範，很難實現和服務無關。統一使用thrift + protobuf 來開發RPC服務可以簡化API網關的開發，避免為每個服務上線而帶來的網關的調整，使得網關和具體的服務解耦合：
- 每個服務實現的worker機器將服務註冊到zookeeper上；
- API網關接收到zookeeper的變更，更新本地的路由表，記錄服務和worker（連接池）的映射關係。
- 當請求被提交到網關上時，網關可以從rpc請求中提取出服務名稱，之後根據這個名稱，找到對應的worker機（連接池），調用該worker上的服務，接受到結果後，將結果返回給調用方。
權限和其他
Protobuf的一個重要特性是，數據的序列化和名稱無關，只和屬性類型、編號有關。 這種方式，間接實現了類的繼承關係。如下所示，我們可以通過Person類來解析Girl和Boy的反序列化流：
message Person {
optional string user_name = 1;
optional string password = 2; }message Girl {
optional string user_name = 1;
optional string password = 2;
optional string favorite_toys = 3; }message Boy {
optional string user_name = 1;
optional string password = 2;
optional int32 favorite_club_count = 3;
optional string favorite_sports = 4; }
我們只要對服務的輸入參數做合理的編排，將常用的屬性使用固定的編號來表示，既可以使用通用的基礎類來解析輸入參數。比如我們要求所有輸入的第一個和第二個元素必須是user_name和password，則我們就可以使用Person來解析這個輸入，從而可以實現對服務的統一身份驗證，並基於驗證結果來實施QPS控制等工作。
七、熔斷與限流
Netflix Hystrix提供不錯的熔斷和限流的實現，參考其在GitHub上的項目介紹。這裡簡單說下熔斷和限流實現原理。
熔斷一般採用電路熔斷器模式(Circuit Breaker Patten)。當某個服務發生錯誤，每秒錯誤次數達到閾值時，不再響應請求，直接返回服務器忙的錯誤給調用方。 延遲一段時間後，嘗試開放50%的訪問，如果錯誤還是高，則繼續熔斷；否則恢復到正常情況。
限流指按照訪問方、IP地址或者域名等方式對服務訪問進行限制，一旦超過給定額度，則禁止其訪問。 除了使用Hystrix，如果要自己實現，可以考慮使用使用Guava RateLimiter
八、服務演化
隨著服務訪問量的增加，服務的實現也會不斷演化以提升性能。主要的方法有讀寫分離、緩存等。
讀寫分離
針對實體服務，讀寫分離是提升性能的第一步。 實現讀寫分離一般有以下幾種方式：
1、在同構數據庫上使用主從複製的方式： 一般數據庫，比如MySQL、HBase、Mongodb等，都提供主從複製功能。數據寫入主庫，讀取、檢索等操作都從從庫上執行，實現讀寫分離。這種方式實現簡單，無需額外開發數據同步程序。一般來說，對寫入有事務要求的數據庫，在讀取上的性能會比較差。雖然可以通過增加從庫的方式來sharding請求，但這也會導致成本增加。
2、在異構數據庫上進行讀寫分離。發揮不同數據庫的優勢，通過消息機制或者其他方式，將數據從主庫同步到從庫。 比如使用MySQL作為主庫來寫入，數據寫入時投遞消息到消息服務器，同步程序接收到消息後，將數據更新到讀庫中。可以使用Redis，Mongodb等內存數據庫作為讀庫，用來支持根據ID來讀取；使用Elastic作為從庫，支持搜索。
3、微服務技術是程序員都離不開的話題，說到這裡，也給大家推薦一個交流學習平臺：架構交流群650385180，裡面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，以下的課程體系圖也是在群裡獲取。相信對於已經工作和遇到技術瓶頸的碼友，在這裡會有你需要的內容。
緩存使用
如果數據量大，使用從庫也會導致從庫成本非常高。對大部分數據來說，比如訂單庫，一般需要的只是一段時間，比如三個月內的數據。更長時間的數據訪問量就非常低了。 這種情況下，沒有必要將所有數據加載到成本高昂的讀庫中，即這時候，讀庫是緩存模式。 在緩存模式下，數據更新策略是一個大問題。
- 對於實時性要求不高的數據，可以考慮採用被動更新的策略。即數據加載到緩存的時候，設置過期時間。一般內存數據庫，包括Redis，couchbase等，都支持這個特性。到過期時間後，數據將失效，再次被訪問時，系統將觸發從主庫讀寫數據的流程。
- 對實時性要求高的數據，需要採用主動更新的策略，也就是接受Message後，立即更新緩存數據。
當然，在服務演化後，對原有服務的實現也會產生影響。 考慮到微服務的一個實現原則，即一個服務僅管一個存儲庫，原有的服務就被分裂成多個服務了。 為了保持使用方的穩定，原有服務被重新實現為服務網關，作為各個子服務的代理來提供服務。
以上是RPC與微服務的全部內容，以下是thrift + protobuf的實現規範的介紹。
附一、基礎服務設計規範
基礎服務是微服務的服務棧中最底層的模塊， 基礎服務直接和數據存儲打交道，提供數據增刪改查的基本操作。
附1.1 設計規範
文件規範
rpc接口文件名以 xxx_rpc_service.thrift 來命名； protobuf參數文件名以 xxx_service.proto 來命名。
這兩種文件全部使用UTF-8編碼。
命名規範
服務名稱以 “XXXXService” 的格式命名， XXXX是實體，必須是名詞。以下是合理的接口名稱。
OrderService
AccountService
附1.2 方法設計
由於基礎服務主要是解決數據讀寫問題，所以從使用的角度，對外提供的接口，可以參考數據庫操作，標準化為增、刪、改、查、統計等基本接口。接口採用 操作+實體來命名，如createOrder。 接口的輸入輸出參數採用 接口名+Request 和 接口名Response 的規範來命名。 這種方式使得接口易於使用和管理。
file: xxx_rpc_service.thrift
/**
* 這裡是版權申明
**/
namespace java com.phoenix.service
/**
* 提供關於XXX實體的增刪改查基本操作。
**/
service XXXRpcService {
/**
* 創建實體
* 輸入參數:
* 1. createXXXRequest: 創建請求，支持創建多個實體；
* 輸出參數
* createXXXResponse: 創建成功，返回創建實體的ID列表；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 必填的參數沒有提供。
**/
binary createXXX(1: binary create_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
/**
* 更新實體
* 輸入參數:
* 1. updateXXXRequest: 更新請求，支持同時更新多個實體；
* 輸出參數
* updateXXXResponse: 更新成功，返回被更行的實體的ID列表；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 該實體在服務器端沒有找到。
**/
binary updateXXX(1: binary update_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
/**
* 刪除實體
* 輸入參數:
* 1. removeXXXRequest: 刪除請求，按照id來刪除，支持一次刪除多個實體；
* 輸出參數
* removeXXXResponse: 刪除成功，返回被刪除的實體的ID列表；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 該實體在服務器端沒有找到。
**/
binary removeXXX(1: binary remove_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
/**
* 根據ID獲取實體
* 輸入參數:
* 1. getXXXRequest: 獲取請求，按照id來獲取，支持一次獲取多個實體；
* 輸出參數
* getXXXResponse: 返回對應的實體列表；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 該實體在服務器端沒有找到。
**/
binary getXXX(1: binary get_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
/**
* 查詢實體
* 輸入參數:
* 1. queryXXXRequest: 查詢條件；
* 輸出參數
* queryXXXResponse: 返回對應的實體列表；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 該實體在服務器端沒有找到。
**/
binary queryXXX(1: binary query_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
/**
* 統計符合條件的實體的數量
* 輸入參數:
* 1. countXXXRequest: 查詢條件；
* 輸出參數
* countXXXResponse: 返回對應的實體數量；
* 異常
* 1. userException:輸入的參數有誤；
* 2. systemExeption:服務器端出錯導致無法創建；
* 3. notFoundException： 該實體在服務器端沒有找到。
**/
binary countXXX(1: binary count_xxx_request) throws (1: Errors.UserException userException, 2: Errors.systemException, 3: Errors.notFoundException)
}
附1.3 參數設計
每個方法的輸入輸出參數，採用protobuf來表示。
file: xxx_service.protobuf
/**
*
* 這裡是版權申明
**/
option java_package = "com.phoenix.service";
import "entity.proto";
import "taglib.proto";
/**
* 創建實體的請求
*
**/
message CreateXXXRequest {
optional string user_name = 1; //訪問這個接口的用戶
optional string password = 2; //訪問這個接口的密碼
repeated XXXX xxx = 21; // 實體內容；
}
/**
* 創建實體的結果響應
*
**/
message CreateXXXResponse {
repeated int64 id = 11;//成功創建的實體的ID列表
}
附1.4 異常設計
RPC接口也不需要太複雜的異常，一般是定義三類異常。
file errors.thrift
/**
* 由於調用方的原因引起的錯誤， 比如參數不符合規範、缺乏必要的參數，沒有權限等。
* 這種異常一般是可以重試的。
*
**/
exception UserException {
1： required ErrorCode error_code;
2: optional string message;
}
/**
* 由於服務器端發生錯誤導致的，比如數據庫無法連接。這也包括QPS超過限額的情況，這時候rateLimit返回分配給的QPS上限；
*
**/
exception systemException {
1： required ErrorCode error_code;
2: optional string message;
3: i32 rateLimit;
}
/**
* 根據給定的ID或者其他條件無法找到對象。
*
**/
exception systemException {
1: optional string identifier;
}
附二、服務SDK
當然，RPC服務不應該直接提供給業務方使用，需要提供封裝好的客戶端。 一般來說，客戶端除了提供訪問服務端的代理外，還需要對常有功能進行封裝，這包括服務發現、RPC連接池、重試機制、QPS控制。這裡首先介紹服務SDK的設計。 直接使用Protobuf作為輸入參數和輸出參數，開發出來的代碼很繁瑣：
GetXXXRequest.Builder request = GetXXXRequest.newBuilder();
request.setUsername("username");
request.setPassword("password");
request.addId("123");
GetXXXResponse response = xxxService.getXXX(request.build());
if(response.xxx.size()==1)
XXX xxx = response.xxx.get(0);
如上，有大量的重複性代碼，使用起來不直觀也不方便。 因而需要使用客戶端SDK來做一層封裝，供業務方調用：
class XXXService {
//根據ID獲取對象
public XXX getXXX(String id){
GetXXXRequest.Builder request = GetXXXRequest.newBuilder();
request.setUsername("username");
request.setPassword("password");
request.addId("123");
GetXXXResponse response = xxxService.getXXX(request.build());
if(response.xxx.size()==1)
return response.xxx.get(0);
return null;
}
}
對所有服務器端接口提供對應的客戶端SDK，也是微服務架構最佳實踐之一。以此封裝完成後，調用方即可以像使用普通接口一樣，無需瞭解實現細節。
閱讀更多 java高級程序猿 的文章
