本文將和大家推薦一個我所在團隊開源的本機多進程通訊 IPC 庫，此 IPC 支持使用 JSON 格式進行直接路由通訊，具有使用方便，穩定性高，性能好的優點
這是我所在的團隊在 GitHub 上使用最友好的 MIT 協議完全開源的項目：https://github.com/dotnet-campus/dotnetCampus.Ipc
這個開源項目開源的是一個 IPC 庫，而本文將要介紹的是這個 IPC 庫其中的一個功能：使用 Json 格式進行直接路由通訊
接下來我將一步步告訴大家如何使用這個功能實現本機多進程通訊
按照 dotnet 的慣例，先安裝 NuGet 庫。可以通過右擊項目進入 NuGet 管理器，搜 dotnetCampus.Ipc 進行安裝，也可以編輯 csproj 項目文件進行快速安裝，如添加以下代碼到你的 csproj 項目文件裏面
<PackageReference Include="dotnetCampus.Ipc" Version="2.0.0-alpha405" />
原本的這個 IPC 庫設計上是 P2P 的方式，也就是沒有明確的客戶端和服務端。只是在使用直接路由方式進行通訊的時候，在概念上有服務端和客戶端。在本文接下來的描述裏面會明確說明客戶端和服務端的邏輯，但底層上依然是 P2P 模式，不存在讓某個進程作爲本質的服務端或客戶端，每個進程都可以既是客戶端又是服務端
先編寫創建服務端的代碼邏輯。服務端需要給一個服務名，客戶端可以通過此服務名連接上服務端，從設計上只允許客戶端主動連接服務端。服務名從底層上將會作爲管道名，請使用符合管道命名規則的方式進行命名，一般都是英文字符大小寫加上數字下劃線
// 初始化服務端
var serverName = "JsonIpcDirectRoutedProviderTest_Request_1";
var serverProvider = new JsonIpcDirectRoutedProvider(serverName);
這個 JsonIpcDirectRoutedProvider 類型只是一個 JSON 直接路由的 IPC 提供器，構造函數可選傳入 IPC 配置，比如配置注入日誌設置日誌輸出等級
在服務端上可以定義響應和通知的處理邏輯，以下代碼定義的是對名爲 “Foo1” 的直接路由的請求的處理邏輯
serverProvider.AddRequestHandler("Foo1", (FakeArgument arg) =>
{
return new FakeResult("Ok");
});
請求處理也就是客戶端發起一個請求給到服務端進行處理，服務端處理完成之後返回響應內容給到客戶端。以上的 FakeArgument 類型參數就是由客戶端發送給到服務端的參數內容，客戶端發送到服務端的參數內容將會見過 Json 的序列化和反序列化的過程。接下來服務端的 FakeResult 返回值將作爲響應，通過 IPC 傳輸給到客戶端，也會經過序列化和反序列化的過程
服務端定義通知的處理邏輯例子如下，通知只有從客戶端發過來的參數，不需要返回任何對象給到客戶端，即客戶端只是發過來一條通知給到服務端
var routedPath = "FooPath";
serverProvider.AddNotifyHandler(routedPath, (FakeArgument arg) =>
{
});
同理，通知的 FakeArgument 參數也會經過序列化和反序列化的過程
服務端完成了路由事件的定義之後，即可通過 StartServer 方法進行啓動
serverProvider.StartServer();
從 IPC 的設計上，要求在 StartServer 啓動服務之前完成所有對路由事件的定義。在 StartServer 之後，禁止再 AddRequestHandler 或 AddNotifyHandler 添加處理邏輯。此設計是爲了保證消息不丟失，防止存在消息在路由事件定義完成之前收到而丟失
以上連在一起的服務端的定義和啓動代碼如下
// 初始化服務端
var serverName = "JsonIpcDirectRoutedProviderTest_Request_1";
var serverProvider = new JsonIpcDirectRoutedProvider(serverName);
serverProvider.AddRequestHandler("Foo1", (FakeArgument arg) =>
{
return new FakeResult("Ok");
});
serverProvider.AddRequestHandler("Foo2", (FakeArgument2 arg) =>
{
return new FakeResult2("Ok");
});
serverProvider.AddRequestHandler("Foo3", (FakeArgument3 arg) =>
{
return new FakeResult3("Ok");
});
var routedPath = "FooPath";
serverProvider.AddNotifyHandler(routedPath, (FakeArgument arg) =>
{
});
serverProvider.AddNotifyHandler("FooPath1", (FakeArgument1 arg) =>
{
});
serverProvider.AddNotifyHandler("FooPath2", (FakeArgument2 arg) =>
{
});
serverProvider.StartServer();
從業務實現上，可以將注入處理的邏輯分到多個不同的模塊裏面，通過傳入 JsonIpcDirectRoutedProvider 給到多個模塊，讓多個模塊在依賴註冊階段進行添加處理。完成之後再調用 StartServer 啓動服務
以上完成了服務端部分代碼的編寫，接下來看看客戶端部分的代碼編寫
本質上的 JsonIpcDirectRouted 依然是 P2P 的方式，而不是 客戶端-服務端 的方式。客戶端的創建也需要從 JsonIpcDirectRoutedProvider 獲取到
// 創建客戶端
// 允許無參數，如果只是做客戶端使用的話
JsonIpcDirectRoutedProvider clientProvider = new();
// 對於 clientProvider 來說，可選調用 StartServer 方法
var clientProxy = await clientProvider.GetAndConnectClientAsync(serverName);
由於客戶端不需要被服務端連接，客戶端可以省略構造函數的參數
獲取客戶端時，需要調用 GetAndConnectClientAsync 方法傳入服務端的服務名。如果此時的服務端還沒啓動，將會在 await 裏面異步等待服務端啓動且連接上服務端
獲取到客戶端對象之後，即可對服務器發起請求獲取響應，也可以單向給服務端發送通知。以下是對服務端發起請求獲取響應的例子
var argument = new FakeArgument("TestName", 1);
FakeResult result = await clientProxy.GetResponseAsync<FakeResult>("Foo1", argument);
以上代碼的 GetResponseAsync 第一個參數表示的是所請求的路由地址，第二個參數是一個對象，將會被 Json 序列化然後發送給服務端。返回值的 FakeResult 是服務端處理的返回值
以下是發送通知給服務端的例子
var argument = new FakeArgument("TestName", 1);
await clientProxy.NotifyAsync("FooPath", argument);
發送通知時 await 返回只代表服務端收到了通知，不代表服務端處理通知完成
連在一起的客戶端創建和通訊的代碼如下
// 創建客戶端
// 允許無參數，如果只是做客戶端使用的話
JsonIpcDirectRoutedProvider clientProvider = new();
// 對於 clientProvider 來說，可選調用 StartServer 方法
var clientProxy = await clientProvider.GetAndConnectClientAsync(serverName);
var result = await clientProxy.GetResponseAsync<FakeResult>("Foo1", argument);
await clientProxy.NotifyAsync("Foo1", argument);
以上就是此 IPC 庫的使用 Json 直接路由事件方式進行通訊的簡單例子
此 IPC 庫不僅提供了本文介紹的 Json 直接路由通訊方式，還可以使用 IPC 對象通訊方式，就如同 .NET Remoting 的用法差不多，詳細請看 dotnet 6 推薦一個可代替 .NET Remoting 的 IPC 庫