關(guān)于dotnet?替換?ASP.NET?Core?的底層通訊為命名管道的?IPC?庫(kù)的問(wèn)題

更新時(shí)間：2022年02月11日 11:18:06 作者：lindexi

這篇文章主要介紹了dotnet?替換?ASP.NET?Core?的底層通訊為命名管道的?IPC?庫(kù),本文給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

這是一個(gè)用于本機(jī)多進(jìn)程進(jìn)行 IPC 通訊的庫(kù)，此庫(kù)的頂層 API 是采用 ASP.NET Core 的 MVC 框架，其底層通訊不是傳統(tǒng)的走網(wǎng)絡(luò)的方式，而是通過(guò) dotnetCampus.Ipc 開(kāi)源項(xiàng)目提供的基于 NamedPipeStream 命名管道的方式進(jìn)行通訊。相當(dāng)于替換掉 ASP.NET Core 的底層通訊方式，從走網(wǎng)絡(luò)換成命名管道的方式。本庫(kù)的優(yōu)勢(shì)是可以使用設(shè)計(jì)非常好的 ASP.NET Core 的 MVC 框架作為頂層調(diào)用 API 層，底層通訊采用可提升傳輸性能的命名管道，如此可以做到不走網(wǎng)絡(luò)通訊從而極大減少網(wǎng)絡(luò)端口占用問(wèn)題和減少用戶端網(wǎng)絡(luò)環(huán)境帶來(lái)的問(wèn)題

背景

本機(jī)內(nèi)多進(jìn)程通訊 IPC 不同于跨設(shè)備系統(tǒng)的 RPC 通訊方式，大多數(shù)的 IPC 通訊都需要處理復(fù)雜的用戶端環(huán)境問(wèn)題。對(duì)于 RPC 通訊來(lái)說(shuō)，大部分時(shí)候，服務(wù)端都在開(kāi)發(fā)者完全管控的環(huán)境下運(yùn)行。但 IPC 通訊則無(wú)論是服務(wù)端還是客戶端都可能是在用戶端運(yùn)行的。然而用戶端上，無(wú)論是系統(tǒng)還是其他環(huán)境都是十分復(fù)雜的，特別是在國(guó)內(nèi)的，魔改的系統(tǒng)，兇狠的殺毒軟件，這些都會(huì)讓 IPC 通訊受到非預(yù)期的打斷

傳統(tǒng)的 dotnet 系的 IPC 手段有很多個(gè)，提供給開(kāi)發(fā)使用的頂層框架也有很多，如 .NET Remoting 和 WCF 等。但是在遷移到 dotnet core 時(shí)，由于底層運(yùn)行時(shí)機(jī)制的變更，如透明代理不再支持類對(duì)象只能支持接口的行為變更，就讓 .NET Remoting 從機(jī)制性不受支持。為了方便將應(yīng)用遷移到 dotnet core 框架上，可采用 dotnet campus 組織基于最友好的 MIT 協(xié)議開(kāi)源的 dotnetCampus.Ipc 開(kāi)源庫(kù)進(jìn)行本機(jī)內(nèi)多進(jìn)程通訊

此 dotnetCampus.Ipc 開(kāi)源庫(kù)底層可基于命名管道進(jìn)行通訊，經(jīng)過(guò)了約 600 萬(wàn)臺(tái)設(shè)備近半年的測(cè)試，發(fā)現(xiàn)通過(guò)此方式的通訊穩(wěn)定性極高。開(kāi)源倉(cāng)庫(kù)地址：https://github.com/dotnet-campus/dotnetCampus.Ipc

無(wú)論是 RPC 還是 IPC 通訊，其頂層提供給開(kāi)發(fā)者使用的 API 層，主流上有兩個(gè)設(shè)計(jì)陣營(yíng)。一個(gè)是如 .NET Remoting 一樣的傳輸類對(duì)象的方式，此方法可以極大隱藏 RPC 或 IPC 的細(xì)節(jié)，調(diào)用遠(yuǎn)程進(jìn)程的對(duì)象就和調(diào)用本機(jī)進(jìn)程一樣。另一個(gè)陣營(yíng)是本文的主角，如 ASP.NET Core 的 MVC 模式，通過(guò)路由配合參數(shù)傳遞，進(jìn)行控制器處理的模式，此方式的優(yōu)良設(shè)計(jì)已被 ASP.NET Core 所證明，本文也就不多說(shuō)了

默認(rèn)下，如此妙的 ASP.NET Core 的 MVC 層框架是僅提供網(wǎng)絡(luò)傳輸?shù)姆绞健Ｈ欢谠幃惖挠脩舳谁h(huán)境下，將有層出不窮的網(wǎng)絡(luò)通訊問(wèn)題，如端口被占用，特殊的軟件阻止上網(wǎng)等等。讓 ASP.NET Core 從走網(wǎng)絡(luò)的方式，替換為走命名管道的方式，可以極大提升在用戶端的穩(wěn)定性

再次表?yè)P(yáng) ASP.NET Core 的優(yōu)秀設(shè)計(jì)，在 ASP.NET Core 里，各個(gè)模塊分層明確，這也就讓更換 ASP.NET Core 里的“通訊傳輸”（其實(shí)本意是 IServer 層）這個(gè)工作十分簡(jiǎn)單

在采用 ASP.NET Core 作為 IPC 的頂層調(diào)用時(shí)，那此時(shí)的通訊方式一定就是服務(wù)端-客戶端的形式。服務(wù)端可以采用替換 ASP.NET Core 的“通訊傳輸”為 dotnetCampus.Ipc 的基于命名管道的傳輸方式。客戶端呢？對(duì) ASP.NET Core 來(lái)說(shuō)，最期望客戶端的行為是通過(guò) HttpClient 來(lái)進(jìn)行發(fā)起調(diào)用。剛好 dotnet 下默認(rèn)的 HttpClient 是支持注入具體的消息傳輸實(shí)現(xiàn)，通過(guò)將 dotnetCampus.Ipc 封裝為 HttpClient 的消息傳輸 HttpMessageHandler 就可以讓客戶端也走 dotnetCampus.Ipc 的傳輸。如此封裝，相當(dāng)于在服務(wù)端和客戶端的底層傳輸，全部都在 dotnetCampus.Ipc 層內(nèi)，分層圖如下，通過(guò) dotnetCampus.Ipc 維持穩(wěn)定的傳輸從而隱藏具體的 IPC 細(xì)節(jié)，業(yè)務(wù)端可以完全復(fù)用原有的知識(shí)，無(wú)須引入額外的 IPC 知識(shí)

充當(dāng) IPC 里的服務(wù)端和客戶端的業(yè)務(wù)代碼將分別與 ASP.NET Core 和 HttpClient 對(duì)接。而 ASP.NET Core 和 HttpClient 又與 dotnetCampus.Ipc 層對(duì)接，一切的跨進(jìn)程通訊邏輯都在 dotnetCampus.Ipc 這一層內(nèi)完成，由 dotnetCampus.Ipc 層維持穩(wěn)定的 IPC 傳輸。下面來(lái)看看如何使用此方式開(kāi)發(fā)應(yīng)用

使用方法

接下來(lái)將使用 PipeMvcServerDemo 和 PipeMvcClientDemo 這兩個(gè)例子項(xiàng)目來(lái)演示如何使用 ASP.NET Core 的 MVC 層框架加命名管道 NamedPipeStream 做通訊傳輸?shù)谋緳C(jī)內(nèi)多進(jìn)程的跨進(jìn)程通訊 IPC 方式

按照慣例，在 dotnet 系的應(yīng)用上使用庫(kù)之前，先通過(guò) NuGet 進(jìn)行安裝。從業(yè)務(wù)上人為分為服務(wù)端和業(yè)務(wù)端的兩個(gè)項(xiàng)目，分別安裝給服務(wù)端用的 dotnetCampus.Ipc.PipeMvcServer 庫(kù)，和給客戶端用的 dotnetCampus.Ipc.PipeMvcClient 庫(kù)

新建的 PipeMvcServerDemo 和 PipeMvcClientDemo 這兩個(gè)基于 .NET 6 的例子項(xiàng)目都是先基于 WPF 的項(xiàng)目模板創(chuàng)建，從業(yè)務(wù)上人為分為服務(wù)端和業(yè)務(wù)端的兩個(gè)項(xiàng)目其實(shí)都是運(yùn)行在相同的一個(gè)計(jì)算機(jī)內(nèi)，只是為了方便敘述，強(qiáng)行將 PipeMvcServerDemo 稱為服務(wù)端項(xiàng)目，將 PipeMvcClientDemo 稱為客戶端項(xiàng)目

服務(wù)端

先從 PipeMvcServerDemo 服務(wù)端項(xiàng)目開(kāi)始寫(xiě)起，在安裝完成 dotnetCampus.Ipc.PipeMvcServer 庫(kù)之后，為了使用上 ASP.NET Core 的 MVC 框架，需要在此 WPF 應(yīng)用里面初始化 ASP.NET Core 框架

初始化的邏輯，和純放在服務(wù)器上的 ASP.NET Core 服務(wù)應(yīng)用只有一點(diǎn)點(diǎn)的差別，那就是在初始化時(shí)，需要調(diào)用 UsePipeIpcServer 擴(kuò)展方法，注入 IPC 的服務(wù)替換掉默認(rèn)的 ASP.NET Core 的“通訊傳輸”（IServer）層。代碼如下

using dotnetCampus.Ipc.PipeMvcServer;
    private static void RunMvc(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);
        // 下面一句是關(guān)鍵邏輯
        builder.WebHost.UsePipeIpcServer("PipeMvcServerDemo");
        builder.Services.AddControllers();
        var app = builder.Build();
        app.MapControllers();
        app.Run();
    }

調(diào)用 UsePipeIpcServer 擴(kuò)展方法，需要額外加上 using dotnetCampus.Ipc.PipeMvcServer; 命名空間。在 UsePipeIpcServer 方法里面需要傳入一個(gè)參數(shù)，此參數(shù)用于開(kāi)啟的 IPC 服務(wù)所使用的服務(wù)名，也就是作為命名管道的管道名。服務(wù)名的字符串要求是在當(dāng)前機(jī)器上唯一不重復(fù)，推薦采用屬性的命名法對(duì)其命名傳入。此后，客戶端的代碼即可采用此服務(wù)名連接上服務(wù)端

也僅僅只需加上 UsePipeIpcServer 擴(kuò)展方法即可完成對(duì)服務(wù)端的 IPC 的所有配置

客戶端

完成服務(wù)端的配置之后，可以開(kāi)始對(duì)客戶端的配置邏輯，客戶端只需要知道服務(wù)端的服務(wù)名，即如上例子的 "PipeMvcServerDemo" 字符串，即可建立和服務(wù)端的通訊。在此庫(kù)的設(shè)計(jì)上，可以認(rèn)為服務(wù)端的服務(wù)名和傳統(tǒng)的 C/S 端應(yīng)用的服務(wù)端地址是等同的，至少需要知道服務(wù)端的地址才能連接上

在客戶端的任意代碼里，可采用 IpcPipeMvcClientProvider 提供的 CreateIpcMvcClientAsync 靜態(tài)方法傳入服務(wù)名，拿到可以和服務(wù)端通訊的 HttpClient 對(duì)象，如以下代碼

using dotnetCampus.Ipc.PipeMvcClient;
        HttpClient ipcPipeMvcClient = await IpcPipeMvcClientProvider.CreateIpcMvcClientAsync("PipeMvcServerDemo");

以上代碼拿到的 ipcPipeMvcClient 對(duì)象即可和傳統(tǒng)的邏輯一樣，進(jìn)行服務(wù)端的請(qǐng)求邏輯，如下文所演示的例子?？梢钥吹娇蛻舳说呐渲眠壿?，也只有在初始化時(shí)，獲取 HttpClient 的邏輯不同

如上面演示的代碼，可以看到，無(wú)論是客戶端還是服務(wù)端，初始化的代碼都是一句話，沒(méi)有很多的細(xì)節(jié)邏輯，方便入手

調(diào)用

下面開(kāi)始演示服務(wù)端和客戶端調(diào)用的例子。為了讓客戶端能調(diào)用到客戶端對(duì)應(yīng)的服務(wù)內(nèi)容，需要先在服務(wù)端創(chuàng)建對(duì)應(yīng)的服務(wù)邏輯。以下將演示 GET 和 POST 方法和對(duì)應(yīng)的路由和參數(shù)調(diào)用方法

在服務(wù)端 PipeMvcServerDemo 項(xiàng)目上添加一個(gè) FooController 控制器，代碼如下

[Route("api/[controller]")]
[ApiController]
public class FooController : ControllerBase
{
    public FooController(ILogger<FooController> logger)
    {
        Logger = logger;
    }
    public ILogger<FooController> Logger { get; }
}

在 FooController 添加 Get 方法，代碼如下

[HttpGet]
    public IActionResult Get()
    {
        Logger.LogInformation("FooController_Get");
        return Ok(DateTime.Now.ToString());
    }

根據(jù) ASP.NET Core 的路由知識(shí)，可以在客戶端通過(guò) api/Foo 路徑訪問(wèn)到以上的 Get 方法。接下來(lái)編寫(xiě)客戶端的邏輯，先在客戶端上的 XAML 界面上添加按鈕，代碼如下

 <Button x:Name="GetFooButton" Margin="10,10,10,10" Click="GetFooButton_Click">Get</Button>

在 GetFooButton_Click 方法里面，使用預(yù)先拿到的 HttpClient 進(jìn)行通訊，代碼如下

using System.Net.Http;

    private async void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        Log($"Start create PipeMvcClient.");
        var ipcPipeMvcClient = await IpcPipeMvcClientProvider.CreateIpcMvcClientAsync("PipeMvcServerDemo");
        _ipcPipeMvcClient = ipcPipeMvcClient;
        Log($"Finish create PipeMvcClient.");
    }
    private HttpClient? _ipcPipeMvcClient;
    private async void GetFooButton_Click(object sender, RoutedEventArgs e)
        if (_ipcPipeMvcClient is null)
        {
            return;
        }
        Log($"[Request][Get] IpcPipeMvcServer://api/Foo");
        var response = await _ipcPipeMvcClient.GetStringAsync("api/Foo");
        Log($"[Response][Get] IpcPipeMvcServer://api/Foo {response}");

以上的 Log 方法將輸出日志到界面的 TextBlock 控件

以上代碼通過(guò) await _ipcPipeMvcClient.GetStringAsync("api/Foo"); 訪問(wèn)到服務(wù)端的 Get 方法，運(yùn)行效果如下

如上圖可以看到，客戶端成功調(diào)用了服務(wù)端，從服務(wù)端拿到了返回值

接下來(lái)的例子是在 GET 請(qǐng)求帶上參數(shù)，如實(shí)現(xiàn)遠(yuǎn)程調(diào)用計(jì)算服務(wù)功能，在客戶端發(fā)送兩個(gè) int 數(shù)給服務(wù)端進(jìn)行計(jì)算相加的值。服務(wù)端的代碼如下

public class FooController : ControllerBase
{
    [HttpGet("Add")]
    public IActionResult Add(int a, int b)
    {
        Logger.LogInformation($"FooController_Add a={a};b=");
        return Ok(a + b);
    }
}

客戶端在 XAML 界面添加對(duì)應(yīng)按鈕的代碼省略，按鈕的事件里調(diào)用方法代碼如下

private async void GetFooWithArgumentButton_Click(object sender, RoutedEventArgs e)
    {
        Log($"[Request][Get] IpcPipeMvcServer://api/Foo/Add");
        var response = await _ipcPipeMvcClient.GetStringAsync("api/Foo/Add?a=1&b=1");
        Log($"[Response][Get] IpcPipeMvcServer://api/Foo/Add {response}");
    }

運(yùn)行效果如下

可以看到客戶端成功調(diào)用了服務(wù)端執(zhí)行了計(jì)算，拿到了返回值

通過(guò)以上的例子可以看到，即使底層更換為 IPC 通訊，對(duì)于上層業(yè)務(wù)代碼，調(diào)用服務(wù)端的邏輯，依然沒(méi)有引入任何新的 IPC 知識(shí)，都是對(duì) HttpClient 的調(diào)用

接下來(lái)是 POST 調(diào)用的代碼，服務(wù)端在 FooController 類上添加 Post 方法，加上 HttpPostAttribute 特性，代碼如下

[HttpPost]
    public IActionResult Post()
    {
        Logger.LogInformation("FooController_Post");
        return Ok($"POST {DateTime.Now}");
    }

客戶端編寫(xiě) PostFooButton 按鈕，在按鈕點(diǎn)擊事件添加如下代碼用于請(qǐng)求服務(wù)端

private async void PostFooButton_Click(object sender, RoutedEventArgs e)
    {
        Log($"[Request][Post] IpcPipeMvcServer://api/Foo");
        var response = await _ipcPipeMvcClient.PostAsync("api/Foo", new StringContent(""));
        var m = await response.Content.ReadAsStringAsync();
        Log($"[Response][Post] IpcPipeMvcServer://api/Foo {response.StatusCode} {m}");
    }

運(yùn)行效果如下圖

如上圖可以看到客戶端成功采用 POST 方法請(qǐng)求到服務(wù)端

接下來(lái)將采用 POST 方法帶參數(shù)方式請(qǐng)求服務(wù)端，服務(wù)端處理客戶端請(qǐng)求過(guò)來(lái)的參數(shù)執(zhí)行實(shí)際的業(yè)務(wù)邏輯，服務(wù)端的代碼依然放在 FooController 類里

 [HttpPost("PostFoo")]
    public IActionResult PostFooContent(FooContent foo)
    {
        Logger.LogInformation($"FooController_PostFooContent Foo1={foo.Foo1};Foo2={foo.Foo2 ?? "<NULL>"}");
        return Ok($"PostFooContent Foo1={foo.Foo1};Foo2={foo.Foo2 ?? "<NULL>"}");
    }

以上代碼采用 FooContent 作為參數(shù)，類型定義如下

public class FooContent
{
    public string? Foo1 { set; get; }
    public string? Foo2 { set; get; }
}

客戶端代碼如下，為了給出更多細(xì)節(jié)，我將不使用 PostAsJsonAsync 方法，而是先創(chuàng)建 FooContent 對(duì)象，將 FooContent 對(duì)象序列化為 json 字符串，再 POST 請(qǐng)求

private async void PostFooWithArgumentButton_Click(object sender, RoutedEventArgs e)
    {
        Log($"[Request][Post] IpcPipeMvcServer://api/Foo");

        var json = JsonSerializer.Serialize(new FooContent
        {
            Foo1 = "Foo PostFooWithArgumentButton",
            Foo2 = null,
        });
        StringContent content = new StringContent(json, Encoding.UTF8, "application/json");
        var response = await _ipcPipeMvcClient.PostAsync("api/Foo/PostFoo", content);
        var m = await response.Content.ReadAsStringAsync();
        Log($"[Response][Post] IpcPipeMvcServer://api/Foo/PostFoo {response.StatusCode} {m}");
    }

運(yùn)行效果如下圖

如上圖，客戶端成功將 FooContent 參數(shù)傳給服務(wù)端

以上就是 GET 和 POST 的例子，幾乎看不出來(lái)加上 IPC 前后對(duì) ASP.NET Core 應(yīng)用調(diào)用的差別，除了要求需要使用特定的 HttpClient 對(duì)象之外，其他的邏輯都相同。以上的例子項(xiàng)目，可以從本文末尾獲取

如關(guān)注此庫(kù)的實(shí)現(xiàn)原理，請(qǐng)繼續(xù)閱讀下文

原理

先從客戶端方向開(kāi)始，在客戶端里使用的 HttpClient 是被注入了使用 IPC 底層框架通訊的 IpcNamedPipeClientHandler 對(duì)象，此 IpcNamedPipeClientHandler 對(duì)象是一個(gè)繼承 HttpMessageHandler 類型的對(duì)象

在 IpcNamedPipeClientHandler 重寫(xiě)了 HttpMessageHandler 類型的 SendAsync 方法，可以讓所有使用 HttpClient 發(fā)送的請(qǐng)求，進(jìn)入 IpcNamedPipeClientHandler 的邏輯。在此方法里面，將序列化請(qǐng)求，將請(qǐng)求通過(guò) dotnetCampus.Ipc 發(fā)送到服務(wù)端，再通過(guò) dotnetCampus.Ipc 提供的消息請(qǐng)求機(jī)制，等待收到服務(wù)端對(duì)此請(qǐng)求的返回值。等收到服務(wù)端的返回值之后，封裝成為 HttpResponseMessage 返回值，讓此返回值接入到 HttpClient 的機(jī)制框架，從而實(shí)現(xiàn)調(diào)用 HttpClient 發(fā)送的請(qǐng)求是通過(guò) dotnetCampus.Ipc 層傳輸而不是走網(wǎng)絡(luò)。進(jìn)入 dotnetCampus.Ipc 層是被設(shè)計(jì)為對(duì)等層，對(duì)客戶端來(lái)說(shuō)，進(jìn)入 dotnetCampus.Ipc 層具體是走到 ASP.NET Core 的 MVC 或者是其他框架都是不需要關(guān)注的。對(duì)客戶端來(lái)說(shuō)，只需要知道進(jìn)入 dotnetCampus.Ipc 層的請(qǐng)求，可以進(jìn)行異步等待請(qǐng)求，細(xì)節(jié)邏輯不需要關(guān)注

以下是 IpcNamedPipeClientHandler 的實(shí)現(xiàn)代碼

class IpcNamedPipeClientHandler : HttpMessageHandler
    {
        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            // 序列化請(qǐng)求消息，準(zhǔn)備通過(guò) IPC 層發(fā)送
            var message = HttpMessageSerializer.Serialize(request);

            // 創(chuàng)建 IPC 消息的 Tag 內(nèi)容，此 Tag 內(nèi)容僅用來(lái)調(diào)試和記錄日志
            var ipcMessageTag = request.RequestUri?.ToString() ?? request.Method.ToString();
            // 在 dotnetCampus.Ipc 層，采用 P2P 模型，沒(méi)有具體的服務(wù)端和客戶端
            // 但是 P2P 模型是可以模擬 C/S 模型的，只需要讓某個(gè)端（Peer）充當(dāng)服務(wù)端，另外的端充當(dāng)客戶端即可
            // 在 dotnetCampus.Ipc 庫(kù)里，采用 PeerProxy 表示某個(gè)端
            // 這里的端表示的是 IPC 的某個(gè)端，大部分時(shí)候可以認(rèn)為是一個(gè)進(jìn)程
            // 以下的 ServerProxy 就是充當(dāng)服務(wù)端的一個(gè)端，將在此框架內(nèi)被初始化創(chuàng)建
            // 通過(guò) PeerProxy 發(fā)送 IPC 請(qǐng)求，此時(shí)的 IPC 請(qǐng)求將會(huì)被 PipeMvcServer 處理
            // 在 PipeMvcServer 里面，將通過(guò) ASP.NET Core MVC 框架層進(jìn)行調(diào)度，分發(fā)到對(duì)應(yīng)的控制器處理
            // 控制器處理完成之后，將由 MVC 框架層將控制器的輸出交給 PipeMvcServer 層
            // 在 PipeMvcServer 層收到控制器的輸出之后，將通過(guò) IPC 框架，將輸出返回給 PipeMvcClient 端
            // 當(dāng) PipeMvcClient 收到輸出返回值后，以下的 await 方法將會(huì)返回
            var response = await ServerProxy.GetResponseAsync(new IpcMessage(ipcMessageTag, message));
            // 將 IPC 返回的消息反序列化為 HttpResponseMessage 用于接入 HttpClient 框架
            return HttpMessageSerializer.DeserializeToResponse(response.Body);
        }
        private PeerProxy ServerProxy { get; }
        // 忽略其他代碼
    }

這就是為什么客戶端需要通過(guò) IpcPipeMvcClientProvider 的 CreateIpcMvcClientAsync 拿到 HttpClient 的原因。在 CreateIpcMvcClientAsync 方法，不僅需要?jiǎng)?chuàng)建 HttpClient 對(duì)象，還需要先嘗試連接服務(wù)端。盡管從 HttpClient 的設(shè)計(jì)上，應(yīng)該是發(fā)起請(qǐng)求時(shí)才去連接服務(wù)端，但因?yàn)檫@是 IPC 通訊，且為了解決 IPC 初始化邏輯的多進(jìn)程資源競(jìng)爭(zhēng)，當(dāng)前版本采用在獲取 HttpClient 也就是發(fā)起具體請(qǐng)求之前，連接服務(wù)端

/// <summary>
    /// 提供給客戶端調(diào)用 MVC 的 Ipc 服務(wù)的功能
    /// </summary>
    public static class IpcPipeMvcClientProvider
    {
        /// <summary>
        /// 獲取訪問(wèn) Mvc 的 Ipc 服務(wù)的對(duì)象
        /// </summary>
        /// <param name="ipcPipeMvcServerName">對(duì)方 Ipc 服務(wù)名</param>
        /// <param name="clientIpcProvider">可選，用來(lái)進(jìn)行 Ipc 連接的本地服務(wù)。如不傳或是空，將創(chuàng)建新的 Ipc 連接服務(wù)</param>
        /// <returns></returns>
        public static async Task<HttpClient> CreateIpcMvcClientAsync(string ipcPipeMvcServerName, IpcProvider? clientIpcProvider = null)
        {
            if (clientIpcProvider == null)
            {
                clientIpcProvider = new IpcProvider();
                clientIpcProvider.StartServer();
            }
            var peer = await clientIpcProvider.GetAndConnectToPeerAsync(ipcPipeMvcServerName);
            return new HttpClient(new IpcNamedPipeClientHandler(peer, clientIpcProvider))
                BaseAddress = new Uri(IpcPipeMvcContext.BaseAddressUrl),
            };
        }
    }

在 dotnetCampus.Ipc 層是采用 P2P 方式設(shè)計(jì)的，因此客戶端也需要?jiǎng)?chuàng)建自己的 IpcProvider 對(duì)象?？蛻舳丝蛇x傳入已有的 IpcProvider 對(duì)象進(jìn)行復(fù)用，就如 HttpClient 復(fù)用邏輯一樣。但創(chuàng)建 IpcProvider 對(duì)象是很便宜的，不會(huì)占用多少資源，是否復(fù)用在性能上沒(méi)有多少影響。但是支持傳入 IpcProvider 更多是可以方便開(kāi)發(fā)者對(duì) IpcProvider 進(jìn)行的定制邏輯，例如注入自己的數(shù)組池和日志等

以上就是客戶端的邏輯。關(guān)于如何序列化請(qǐng)求消息等，這些就屬于細(xì)節(jié)了，無(wú)論采用什么方法，只需要能將請(qǐng)求和響應(yīng)與二進(jìn)制 byte 數(shù)組進(jìn)行序列化和反序列化即可。細(xì)節(jié)內(nèi)容還請(qǐng)自行在本文末尾獲取源代碼進(jìn)行閱讀

服務(wù)端的邏輯相對(duì)復(fù)雜一些，在服務(wù)端的 dotnetCampus.Ipc 層收到客戶端的請(qǐng)求后，服務(wù)端將構(gòu)建一個(gè)虛擬的訪問(wèn)請(qǐng)求，此訪問(wèn)請(qǐng)求將通過(guò) 繼承 IServer 接口的 IpcServer 對(duì)象，在 ASP.NET Core 框架內(nèi)發(fā)起請(qǐng)求，通過(guò) MVC 框架層處理之后將響應(yīng)返回到 IpcServer 對(duì)象里交給 dotnetCampus.Ipc 層傳輸給客戶端

在 IpcServer 對(duì)象的啟動(dòng)函數(shù)，也就是 StartAsync 函數(shù)里面，將會(huì)同步初始化 IpcPipeMvcServerCore 對(duì)象。在 IpcPipeMvcServerCore 對(duì)象里面將初始化創(chuàng)建 dotnetCampus.Ipc 層的通訊機(jī)制。代碼如下

public class IpcServer : IServer
    {
        public IpcServer(IServiceProvider services, IFeatureCollection featureCollection, IOptions<IpcServerOptions> optionsAccessor)
        {
        	// 忽略代碼
            var ipcCore = Services.GetRequiredService<IpcPipeMvcServerCore>();
            IpcPipeMvcServerCore = ipcCore;
        }

        Task IServer.StartAsync<TContext>(IHttpApplication<TContext> application, CancellationToken cancellationToken)
            // 忽略代碼
            IpcPipeMvcServerCore.Start();
        private IpcPipeMvcServerCore IpcPipeMvcServerCore { get; }
        // 忽略代碼
    }

而 IpcPipeMvcServerCore 和 IpcServer 對(duì)象都是在調(diào)用 builder.WebHost.UsePipeIpcServer(xxx); 被注入，如以下代碼

 public static class WebHostBuilderExtensions
    {
        /// <summary>
        /// Enables the <see cref="IpcServer" /> service. 啟用命名管道IPC服務(wù)
        /// </summary>
        /// <param name="builder">The <see cref="IWebHostBuilder"/>.</param>
        /// <param name="ipcPipeName">設(shè)置 Ipc 服務(wù)的管道名</param>
        /// <returns>The <see cref="IWebHostBuilder"/>.</returns>
        public static IWebHostBuilder UsePipeIpcServer(this IWebHostBuilder builder, string ipcPipeName)
        {
            return builder.ConfigureServices(services =>
            {
            	// 忽略代碼
                services.AddSingleton<IServer, IpcServer>();
                services.AddSingleton<IpcPipeMvcServerCore>(s => new IpcPipeMvcServerCore(s, ipcPipeName));
            });
        }
    }

依靠 ASP.NET Core 的機(jī)制，將會(huì)在主機(jī)啟動(dòng)，調(diào)用 IServer 的 StartAsync 方法。通過(guò) IpcServer 的 StartAsync 方法啟動(dòng) IpcPipeMvcServerCore 的邏輯

在 IpcPipeMvcServerCore 里，將初始化 IpcProvider 服務(wù)。這里的 IpcProvider 服務(wù)是 dotnetCampus.Ipc 提供的服務(wù)對(duì)外的接口，通過(guò) IpcProvider 可以和 dotnetCampus.Ipc 層的其他 Peer 進(jìn)行通訊。剛好在客戶端也相同的初始化 IpcProvider 服務(wù)，通過(guò) ipcPipeName 管道名可以將客戶端和服務(wù)端關(guān)聯(lián)

 class IpcPipeMvcServerCore
    {
        public IpcPipeMvcServerCore(IServiceProvider serviceProvider, string? ipcServerName)
        {
            ipcServerName ??= "IpcPipeMvcServer" + Guid.NewGuid().ToString("N");

            IpcServer = new IpcProvider(ipcServerName, new IpcConfiguration()
            {
                DefaultIpcRequestHandler = new DelegateIpcRequestHandler(async context =>
                {
                    // 核心代碼
                })
            });
        }
        public void Start() => IpcServer.StartServer();
        public IpcProvider IpcServer { set; get; }
    }

在 dotnetCampus.Ipc 層提供了請(qǐng)求響應(yīng)框架，可以通過(guò)傳入 DefaultIpcRequestHandler 對(duì)象用來(lái)接收其他端發(fā)送過(guò)來(lái)的請(qǐng)求，處理完成之后返回給對(duì)方。上面代碼的核心就是 DelegateIpcRequestHandler 的處理邏輯，在 context 里讀取客戶端的請(qǐng)求信息，反序列化為 HttpRequestMessage 對(duì)象，通過(guò)內(nèi)部邏輯進(jìn)入到 ASP.NET Core 層，再通過(guò) MVC 框架之后拿到請(qǐng)求的返回值，將返回值封裝為 IpcResponseMessageResult 返回給客戶端

 IpcServer = new IpcProvider(ipcServerName, new IpcConfiguration()
            {
                DefaultIpcRequestHandler = new DelegateIpcRequestHandler(async context =>
                {
                	// 將請(qǐng)求反序列化為 HttpRequestMessage 對(duì)象
                	// 用于傳入到 ASP.NET Core 層
                    System.Net.Http.HttpRequestMessage? requestMessage = HttpMessageSerializer.DeserializeToRequest(context.IpcBufferMessage.Body);

                    // 創(chuàng)建虛擬的請(qǐng)求，進(jìn)入到 ASP.NET Core 框架里
                    var server = (IpcServer) serviceProvider.GetRequiredService<IServer>();
                    var clientHandler = (ClientHandler) server.CreateHandler();
                    var response = await clientHandler.SendInnerAsync(requestMessage, CancellationToken.None);
                    // 拿到的返回值序列化為 IpcResponseMessageResult 放入 dotnetCampus.Ipc 層用來(lái)返回客戶端
                    var responseByteList = HttpMessageSerializer.Serialize(response);
                    return new IpcResponseMessageResult(new IpcMessage($"[Response][{requestMessage.Method}] {requestMessage.RequestUri}", responseByteList));
                })
            });

創(chuàng)建虛擬的請(qǐng)求，進(jìn)入 ASP.NET Core 框架里的邏輯是服務(wù)端最復(fù)雜的部分。在 IpcServer 的 CreateHandler 方法里面，將創(chuàng)建 ClientHandler 對(duì)象。此 ClientHandler 對(duì)象是用來(lái)構(gòu)建虛擬的請(qǐng)求，相當(dāng)于在當(dāng)前進(jìn)程內(nèi)發(fā)起請(qǐng)求而不是通過(guò)網(wǎng)絡(luò)層發(fā)起請(qǐng)求，代碼如下

public class IpcServer : IServer
    {
        /// <summary>
        /// Creates a custom <see cref="HttpMessageHandler" /> for processing HTTP requests/responses with the test server.
        /// </summary>
        public HttpMessageHandler CreateHandler()
        {
        	// 忽略代碼
            return new ClientHandler(BaseAddress, Application) { AllowSynchronousIO = AllowSynchronousIO, PreserveExecutionContext = PreserveExecutionContext };
        }
    }

在也是繼承 HttpMessageHandler 的 ClientHandler 里，也重寫(xiě)了 SendInnerAsync 方法，此方法將會(huì)負(fù)責(zé)創(chuàng)建 HttpContextBuilder 對(duì)象，由 HttpContextBuilder 執(zhí)行具體的調(diào)用 ASP.NET Core 層的邏輯

 public async Task<HttpResponseMessage> SendInnerAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
       
            // 創(chuàng)建 HttpContextBuilder 對(duì)象
            var contextBuilder = new HttpContextBuilder(_application, AllowSynchronousIO, PreserveExecutionContext);

            var requestContent = request.Content;
            if (requestContent != null)
            {
            	// 以下是對(duì) HttpContextBuilder 的初始化邏輯
                // Read content from the request HttpContent into a pipe in a background task. This will allow the request
                // delegate to start before the request HttpContent is complete. A background task allows duplex streaming scenarios.
                contextBuilder.SendRequestStream(async writer =>
                {
                    // 忽略初始化邏輯
                });
            }
            contextBuilder.Configure((context, reader) =>
                // 忽略初始化邏輯
            });
            // 忽略其他代碼
            // 執(zhí)行實(shí)際的調(diào)用 ASP.NET Core 框架邏輯
            var httpContext = await contextBuilder.SendAsync(cancellationToken);
            // 創(chuàng)建 HttpResponseMessage 對(duì)象用于返回
            var response = new HttpResponseMessage();
            // 以下是對(duì) HttpResponseMessage 的初始化邏輯，從 httpContext 里獲取返回值
            response.StatusCode = (HttpStatusCode) httpContext.Response.StatusCode;
            response.ReasonPhrase = httpContext.Features.Get<IHttpResponseFeature>()!.ReasonPhrase;
            response.RequestMessage = request;
            response.Version = request.Version;
            response.Content = new StreamContent(httpContext.Response.Body);
            return response;
        }

在 HttpContextBuilder 里，將在 SendAsync 邏輯里調(diào)用 ApplicationWrapper 的 ProcessRequestAsync 方法從而調(diào)入 ASP.NET Core 框架內(nèi)。這里的 ApplicationWrapper 是對(duì) Microsoft.AspNetCore.Hosting.HostingApplication 的封裝，因?yàn)榇?HostingApplication 類型是不對(duì)外公開(kāi)的。以上這幾個(gè)類型的定義邏輯，都是現(xiàn)有的 https://github.com/dotnet/aspnetcore 開(kāi)源倉(cāng)庫(kù)的代碼

通過(guò)當(dāng)前進(jìn)程發(fā)起請(qǐng)求而不通過(guò)網(wǎng)絡(luò)層的邏輯，其實(shí)在 ASP.NET Core 開(kāi)源倉(cāng)庫(kù)里面有默認(rèn)的一個(gè)實(shí)現(xiàn)的提供。那就是為了單元測(cè)試編寫(xiě)的 TestHost 機(jī)制

在 TestHost 機(jī)制里，開(kāi)發(fā)者可以在單元測(cè)試?yán)锩骈_(kāi)啟 ASP.NET Core 主機(jī)，但是不需要監(jiān)聽(tīng)任何網(wǎng)絡(luò)的端口，所有對(duì)此主機(jī)的測(cè)試完全通過(guò) TestHost 機(jī)制走進(jìn)程內(nèi)的模擬請(qǐng)求發(fā)起。對(duì)于業(yè)務(wù)代碼來(lái)說(shuō)，大多數(shù)時(shí)候不需要關(guān)注請(qǐng)求的發(fā)起方具體是誰(shuí)，因此單元測(cè)試上可以使用 TestHost 方便進(jìn)行測(cè)試業(yè)務(wù)代碼，或者是在集成測(cè)試上測(cè)試調(diào)用邏輯。使用 TestHost 可以讓單元測(cè)試或集成測(cè)試不需要關(guān)注網(wǎng)絡(luò)的監(jiān)聽(tīng)，防止測(cè)試錯(cuò)服務(wù)，方便在 CI 里加入測(cè)試邏輯

剛好此機(jī)制的代碼也是本庫(kù)所需要的，通過(guò)拷貝了 https://github.com/dotnet/aspnetcore 開(kāi)源倉(cāng)庫(kù)的關(guān)于 TestHost 的機(jī)制代碼，即可用來(lái)實(shí)現(xiàn) IpcServer 的邏輯

也如放在 IpcServer 的 CreateHandler 函數(shù)上的代碼注釋，這就是原本的 TestHost 里對(duì)應(yīng)函數(shù)的代碼

相當(dāng)于在 TestHost 機(jī)制上再加上一層，這一層就是基于 dotnetCampus.Ipc 層做通訊，通過(guò) TestHost 層創(chuàng)建虛擬的請(qǐng)求，進(jìn)入 ASP.NET Core 框架

為了方便開(kāi)發(fā)者接入，也為了防止開(kāi)發(fā)者接入了 dotnetCampus.Ipc 層的 IpcNamedPipeStreamMvcServer 之后，再接入 TestHost 進(jìn)行單元測(cè)試的沖突，本倉(cāng)庫(kù)更改了所有從 https://github.com/dotnet/aspnetcore 開(kāi)源倉(cāng)庫(kù)的關(guān)于 TestHost 的機(jī)制代碼的命名空間，對(duì)入口調(diào)用函數(shù)和類型也進(jìn)行重命名。在每個(gè)拷貝的文件上都加上了 // Copy From: https://github.com/dotnet/aspnetcore 的注釋

代碼

本文所有代碼都放在 https://github.com/dotnet-campus/dotnetCampus.Ipc 開(kāi)源倉(cāng)庫(kù)里，歡迎訪問(wèn)

參考文檔

HttpRequestMessage C# (CSharp)代碼示例 - HotExamples

c# - How to send a Post body in the HttpClient request in Windows Phone 8? - Stack Overflow

HttpRequestOptions Class (System.Net.Http)

c# - Serialize and deserialize HttpRequestMessage objects - Stack Overflow

Byte Rot: Serialising request and response in ASP.NET Web API

Efficient post calls with HttpClient and JSON.NET

c# - NamedPipe with ASP.Net - Stack Overflow

wcf - Using "named pipes" in ASP.NET HttpModule - Stack Overflow

到此這篇關(guān)于dotnet 替換 ASP.NET Core 的底層通訊為命名管道的 IPC 庫(kù)的文章就介紹到這了,更多相關(guān)ASP.NET Core IPC 庫(kù)命名管道內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: