遠程過程調用(RPC)
在第二個教程中，我們學會了如何使用工作隊列將耗時的任務分發給多個工作者。
但假如我們想調用遠程電腦上的一個函數（或方法）并等待函數執行的結果，這時候該怎么辦呢？好吧，這是一個不同的故事。這種模式通常稱為遠程過程調用RPC（Remote Procedure Call）。
在今天的教程中，我們將會使用RabbitMQ來建立一個RPC系統：一個客戶端和一個可擴展的RPC服務端。因為我們沒有任何現成的耗時任務，我們將會創建一個假的RPC服務，它將返回斐波那契數（Fibonacci numbers）。
客戶端接口（Client interface）
為了演示如何使用RPC服務，我們將創建一個簡單的客戶端類。它負責暴露一個名為call的方法，該方法將發送一個RPC請求并阻塞，直到接收到回答。
FibonacciRpcClient fibonacciRpc = new FibonacciRpcClient();
String result = fibonacciRpc.call("4");
System.out.println( "fib(4) is " + result);
關于RPC
盡管在計算領域RPC這種模式很普遍，但它仍備受批評。當程序員不清楚一個方法到底是本地的還是一個在遠程機器上執行，問題就來了。此類疑惑通常給調試帶來不必要的復雜性。相比簡單的軟件，不恰當的RPC使用會導致產生不可維護的面條代碼（spaghetti code）。
</br>將上面的話記在腦子里，并考慮一下建議：
①確保讓哪個函數調用是本地調用哪個是遠程調用看起來很明顯。
②為系統寫文檔，清楚地表述組件間的依賴關系。
③處理錯誤，比如當RPC服務很久沒有反應，客戶端應該怎么辦。
</br>盡量避免RPC。如果可能，你可以使用異步管道來代替RPC，像阻塞，結果將會異步地推送到下一個計算階段。
回調隊列（Callback queue）
使用RabbitMQ來做RPC很容易?？蛻舳税l送一個請求消息，服務端以一個響應消息回應。為了可以接收到響應，需要與請求（消息）一起，發送一個回調的隊列。我們使用默認的隊列（Java獨有的）：
callbackQueueName = channel.queueDeclare().getQueue();
BasicProperties props = new BasicProperties
.Builder()
.replyTo(callbackQueueName)
.build();
channel.basicPublish("", "rpc_queue", props, message.getBytes());
// ... then code to read a response message from the callback_queue ...
消息屬性
AMPQ 0-9-1協議預定義了消息的14種屬性。大部分屬性都很少用到，除了下面的幾種：
①deliveryMode：標記一個消息是持久的（值為2）還是短暫的（2以外的任何值），你可能還記得我們的第二個教程中用到過這個屬性。
②contentType：描述編碼的mime-type（mime-type of the encoding）。比如最常使用JSON格式，就可以將該屬性設置為application/json。
③replyTo：通常用來命名一個回調隊列。
④correlationId：用來關聯RPC的響應和請求。
我們需要引入一個新的類：
import com.rabbitmq.client.AMQP.BasicProperties;
關聯標識（Correlation Id）
在上面的方法中，我們為每一個RPC請求都創建了一個新的回調隊列。這樣做顯然很低效，但幸好我們有更好的方式：讓我們為每一個客戶端創建一個回調隊列。
這樣做又引入了一個新的問題，在回調隊列中收到響應后不知道到底是屬于哪個請求的。這時候，Correlation Id就可以派上用場了。對每一個請求，我們都創建一個唯一性的值作為Correlation Id。之后，當我們從回調隊列中收到消息的時候，就可以查找這個屬性，基于這一點，我們就可以將一個響應和一個請求進行關聯。如果我們看到一個不知道的Correlation Id值，我們就可以安全地丟棄該消息，因為它不屬于我們的請求。
你可能會問，為什么要忽視回調隊列中的不知道的消息，而不是直接以一個錯誤失?。╢ailing with an error）。這是由于服務端可能存在的競爭條件。盡管不會，但這種情況仍有可能發生：RPC服務端在發給我們答案之后就掛掉了，還沒來得及為請求發送一個確認信息。如果發生這種情況，重啟后的RPC服務端將會重新處理該請求（因為沒有給RabbitMQ發送確認消息，RabbitMQ會重新發送消息給RPC服務）。這就是為什么我們要在客戶端優雅地處理重復響應，并且理想情況下，RPC服務要是冪等的。
總結
我們的RPC系統的工作流程如下：
當客戶端啟動后，它會創建一個異步的獨特的回調隊列。對于一個RPC請求，客戶端將會發送一個配置了兩個屬性的消息：一個是replyTo屬性，設置為這個回調隊列；另一個是correlation id屬性，每一個請求都會設置為一個具有唯一性的值。這個請求將會發送到rpc_queue隊列。
RPC工作者（即圖中的server）將會等待rpc_queue隊列的請求。當有請求到來時，它就會開始干活（計算斐波那契數）并將結果通過發送消息來返回，該返回消息發送到replyTo指定的隊列。
客戶端將等待回調隊列返回數據。當返回的消息到達時，它將檢查correlation id屬性。如果該屬性值和請求匹配，就將響應返回給程序。
放在一塊
計算斐波那契數的任務如下：
private static int fib(int n) {
if (n == 0) return 0;
if (n == 1) return 1;
return fib(n-1) + fib(n-2);
}
我們定義了斐波那契函數，它假設只會輸入正整數（不要期望該函數在輸入很大的數的時候可以好好工作，它可能是最慢的遞歸實現）。
RPC服務RPCServer.java的代碼如下：
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Consumer;
import com.rabbitmq.client.DefaultConsumer;
import com.rabbitmq.client.AMQP;
import com.rabbitmq.client.Envelope;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class RPCServer {
private static final String RPC_QUEUE_NAME = "rpc_queue";
//模擬的耗時任務，即計算斐波那契數
private static int fib(int n) {
if (n == 0) return 0;
if (n == 1) return 1;
return fib(n - 1) + fib(n - 2);
}
public static void main(String[] argv) {
//創建連接和通道
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
Connection connection = null;
try {
connection = factory.newConnection();
final Channel channel = connection.createChannel();
//聲明隊列
channel.queueDeclare(RPC_QUEUE_NAME, false, false, false, null);
//一次只從隊列中取出一個消息
channel.basicQos(1);
System.out.println(" [x] Awaiting RPC requests");
//監聽消息（即RPC請求）
Consumer consumer = new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
AMQP.BasicProperties replyProps = new AMQP.BasicProperties
.Builder()
.correlationId(properties.getCorrelationId())
.build();
//收到RPC請求后開始處理
String response = "";
try {
String message = new String(body, "UTF-8");
int n = Integer.parseInt(message);
System.out.println(" [.] fib(" + message + ")");
response += fib(n);
} catch (RuntimeException e) {
System.out.println(" [.] " + e.toString());
} finally {
//處理完之后，返回響應（即發布消息）
System.out.println("[server current time] : " + System.currentTimeMillis());
channel.basicPublish("", properties.getReplyTo(), replyProps, response.getBytes("UTF-8"));
channel.basicAck(envelope.getDeliveryTag(), false);
}
}
};
channel.basicConsume(RPC_QUEUE_NAME, false, consumer);
//loop to prevent reaching finally block
while (true) {
try {
Thread.sleep(100);
} catch (InterruptedException _ignore) {
}
}
} catch (IOException | TimeoutException e) {
e.printStackTrace();
} finally {
if (connection != null)
try {
connection.close();
} catch (IOException _ignore) {
}
}
}
}
RPC服務的代碼很直白：
通常我們開始先建立連接、通道并聲明隊列。
我們可能會運行多個服務進程。為了負載均衡我們通過設置prefetchCount =1將任務分發給多個服務進程。
我們使用了basicConsume來連接隊列，并通過一個DefaultConsumer對象提供回調。這個DefaultConsumer對象將進行工作并返回響應。
我們的RPC客戶端RPCClient代碼如下：
package com.maxwell.rabbitdemo;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DefaultConsumer;
import com.rabbitmq.client.AMQP;
import com.rabbitmq.client.Envelope;
import java.io.IOException;
import java.util.UUID;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeoutException;
public class RPCClient {
private Connection connection;
private Channel channel;
private String requestQueueName = "rpc_queue";
private String replyQueueName;
//定義一個RPC客戶端
public RPCClient() throws IOException, TimeoutException {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
connection = factory.newConnection();
channel = connection.createChannel();
replyQueueName = channel.queueDeclare().getQueue();
}
//真正地請求
public String call(String message) throws IOException, InterruptedException {
final String corrId = UUID.randomUUID().toString();
AMQP.BasicProperties props = new AMQP.BasicProperties
.Builder()
.correlationId(corrId)
.replyTo(replyQueueName)
.build();
channel.basicPublish("", requestQueueName, props, message.getBytes("UTF-8"));
final BlockingQueue<String> response = new ArrayBlockingQueue<String>(1);
channel.basicConsume(replyQueueName, true, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
if (properties.getCorrelationId().equals(corrId)) {
System.out.println("[client current time] : " + System.currentTimeMillis());
response.offer(new String(body, "UTF-8"));
}
}
});
return response.take();
}
//關閉連接
public void close() throws IOException {
connection.close();
}
public static void main(String[] argv) {
RPCClient fibonacciRpc = null;
String response = null;
try {
//創建一個RPC客戶端
fibonacciRpc = new RPCClient();
System.out.println(" [x] Requesting fib(30)");
//RPC客戶端發送調用請求，并等待影響，直到接收到
response = fibonacciRpc.call("30");
System.out.println(" [.] Got '" + response + "'");
} catch (IOException | TimeoutException | InterruptedException e) {
e.printStackTrace();
} finally {
if (fibonacciRpc != null) {
try {
//關閉RPC客戶的連接
fibonacciRpc.close();
} catch (IOException _ignore) {
}
}
}
}
}
客戶端代碼看起來有一些復雜：
我們建立連接和通道，并聲明了一個獨特的回調隊列。
我們訂閱這個回調隊列，所以我們可以接收RPC響應。
我們的call方法執行RPC請求。在call方法中，我們首先生成一個具有唯一性的correlationId值并存在變量corrId中。我們的DefaultConsumer中的實現方法handleDelivery會使用這個值來獲取爭取的響應。然后，我們發布了這個請求消息，并設置了replyTo和correlationId這兩個屬性。好了，現在我們可以坐下來耐心等待響應到來了。
由于我們的消費者處理（指handleDelivery方法）是在子線程進行的，因此我們需要在響應到來之前暫停主線程（否則主線程結束了，子線程接收到了影響傳給誰啊）。使用BlockingQueue是一種解決方案。在這里我們創建了一個阻塞隊列ArrayBlockingQueue并將它的容量設為1，因為我們只需要接受一個響應就可以啦。
handleDelivery方法所做的很簡單，當有響應來的時候，就檢查是不是和correlationId匹配，匹配的話就放到阻塞隊列ArrayBlockingQueue中。
同時，主線程正等待影響。
最終我們就可以將影響返回給用戶了。
現在，可以動手實驗了。
首先，執行RPC服務端，讓它等待請求的到來。
[x] Awaiting RPC requests
然后，執行RPC客戶端，即RPCClient中的main方法，發起請求：
[x] Requesting fib(30)
[client current time] : 1500474305838
[.] Got '832040'
可以看到，客戶端很快就接受到了請求，回頭看RPC服務端的時間：
[.] fib(30)
[server current time] : 1500474305835
上面這種設計并不是RPC服務端的唯一實現，但是它有以下幾個重要的優勢：
①如果RPC服務端很慢，你可以通過運行多個實例就可以實現擴展。
②在RPC客戶端，RPC要求發送和接受一個消息。非同步的方法queueDeclare是必須的。這樣，RPC客戶端只需要為一個RPC請求只進行一次網絡往返。
但我們的代碼仍然太簡單，并沒有處理更復雜但也非常重要的問題，像：
①如果沒有服務端在運行，客戶端該怎么辦
②客戶端應該為一次RPC設置超時嗎
③如果服務端發生故障并拋出異常，它還應該返回給客戶端嗎？
④在處理消息前，先通過邊界檢查、類型判斷等手段過濾掉無效的消息等
說明
①與原文略有出入，如有疑問，請參閱原文
②原文均是編譯后通過javacp命令直接運行程序，我是在IDE中進行的，相應的操作做了修改。
③添加了客戶端和服務端執行時間。
