1 前言
之所以寫本文章，是因為在我停止維護多年前寫的NetworkSocket元件兩年多來，還是有一些開發者在關注這個專案，我希望有類似需求的開發者明白為什麼要停止更新，可以使用什麼更好的方式來替換(其實很大原因是我把時間花在開發WebApiClient上面了)。那時.netcore還沒有生下來，asp.net除了蝸居在iis裡處理http，其它什麼也不能幹，而NetworkSocket是這樣定義的：
NetworkSocket是一個以中介軟體(middleware)擴充套件通訊協議，以外掛(plug)擴充套件伺服器功能的支援SSL安全傳輸的通訊框架；目前支援http、websocket、fast、flex策略與silverlight策略協議。
2 Kestrel是什麼
談到asp.netcore，人們自然就想到它的預設伺服器kestrel，在很多場景中，人們甚至認為kestrel等於Web伺服器，或者說它只能處理http和http之上的東西。本文先在此下個定義：Kestrel是一款基於中介軟體來處理tcp連線的伺服器，並內建了http(包含websocket、SignalR)解析中介軟體。也就是說，我們完全可以給kestrel新增其它中介軟體，用來處理非http的連線的業務場景，讓kestrel使用一個埠支援多種協議或多協議一個埠一種協議的要求。
2.1 Kestrel的中介軟體是什麼
在asp.netcore的Startup裡，我們使用app.UseXXX的擴充套件方法來應用各種中介軟體，比如UseRouting、UseStaticFiles等等，它本質上還是呼叫了IApplicationBuilder.Use(Func<RequestDelegate, RequestDelegate> middleware)，也就說Func<RequestDelegate, RequestDelegate>就是一箇中介軟體。
對應的，在kestrel世界裡，也有一個IConnectionBuilder.Use(Func<ConnectionDelegate, ConnectionDelegate> middleware)，Func<ConnectionDelegate, ConnectionDelegate>就是kestrel的中介軟體，我們可以如下安裝kestrel的中介軟體：
kestrel.ListenAnyIP(port: 80, listen =>
{
listen.Use(next => context =>
{
if(true)
{
// 中介軟體1的邏輯
}else
{
return next(context);
}
})
.Use(next => context =>
{
if(true)
{
// 中介軟體2的邏輯
}else
{
return next(context);
}
});
});
值得注意的是，kestrel的最後一箇中間處理者是http中介軟體，以上程式碼，實際的kestrel已經包含3種處理者(文章後部分有中介軟體的篇幅，然後就容易理解了)，邏輯1、邏輯2和http解析，我們可以簡單理解為Startup的app物件，對應kestrel的內建的那個最後中介軟體。
2.2 Kestrel的ConnectionContext
在kestrel中介軟體裡，最重要的物件就是ConnectionDelegate，它等同於Func<ConnectionContext,Task>，我們可以理解為它就是一個Hanlder，傳入連線上下文，剩下就是我們要乾的工作了，而中介軟體是除了這個Handler之外，我們還能拿到一個叫next的Handler，我們可以選擇是否呼叫它，如果不呼叫，流程終止。
ConnectionContext是kestrel的一個Tcp連線抽象，其核心屬性是Transport，表示雙工傳輸層的操作物件，另外提供Abort()方法用於服務端主動關閉連線。基於ConnectionContext，很容易實現一個自定義協議的tcp雙工通訊伺服器，相比從Socket寫起，我們可能可以減少100倍程式碼量，而得到的是更高效能的服務。
3 基於Kestrel的SignalR+Redis的推送服務
本實戰中，我們使用asp.netcore內建的SignalR功能，外加自己實現的部分Redis協議（只簡單實現釋出訂閱功能），來做一個訊息從雲端推送到客戶端的服務，我們的服務對客戶端支援redis協議訂閱或Signal協議訂閱，同時我們提供redis+signalR+http三種協議介面給雲端其它微服務來發布訊息，釋出者不用關心客戶端是什麼協議，只需要選擇自己喜歡的協議的釋出介面來呼叫釋出。
3.1 協議與ConnectionContext的關係
在我們的這個應用裡，一個連線不允許同時使用SignalR和Redis並存協議，也就是說，一個連線在發起第一個請求裡，就確定了它整個生命週期裡的協議。所以，我們需要分析連線讀取到的第一個資料包，確定它是否為Redis協議，如果不是redis協議，我們要將ConnectionContext傳達到下一個中介軟體(即http中介軟體)。
3.2 使用Redis中介軟體
如下程式碼，Use裡面就是Redis中介軟體，裡面的個協議分析邏輯：
kestrel.ListenAnyIP(options.Port, listen =>
{
listen.Use(next => async context =>
{
if (await Protocol.IsRedisAsync(context))
{
logger.LogDebug($"{context.RemoteEndPoint} {nameof(ClientType.Redis)} 連線");
await redis.HandleAsync(context);
logger.LogDebug($"{context.RemoteEndPoint} {nameof(ClientType.Redis)} 斷開");
}
else
{
logger.LogDebug($"{context.RemoteEndPoint} {nameof(ClientType.SignalR)} 連線");
await next(context);
logger.LogDebug($"{context.RemoteEndPoint} {nameof(ClientType.SignalR)} 斷開");
}
});
});
Protocol類
/// <summary>
/// 連線的協議判斷
/// </summary>
public static class Protocol
{
/// <summary>
/// 返回連線是否為redis協議
/// </summary>
/// <param name="connection"></param>
/// <returns></returns>
public static async Task<bool> IsRedisAsync(ConnectionContext connection)
{
var result = await connection.Transport.Input.ReadAsync();
var state = IsRedis(result);
connection.Transport.Input.AdvanceTo(result.Buffer.Start);
return state;
}
/// <summary>
/// 返回資料是否為redis協議
/// 這裡不必嚴格檢查，只要能區分是http還是redis就行
/// </summary>
/// <param name="result"></param>
/// <returns></returns>
private static bool IsRedis(ReadResult result)
{
if (result.Buffer.IsEmpty)
{
return false;
}
var span = result.Buffer.FirstSpan;
return span.Length > 0 && span[0] == '*';
}
}
3.3 RedisConnectionHandler
在3.2程式碼裡，有一個await redis.HandleAsync(context);這個redis就是RedisConnectionHandler例項，它的功能是處理一個redis連線從建立成功之後到斷開的所有邏輯。
我們知道，Redis有好幾十個命令，單單是實現釋出和訂閱功能，我們也要實現必要的8個命令。說到這裡，我的腦海裡又閃現出一個長長的switch(收到的cmd) case xxx的程式碼了，我們甚至還需要在switch之前寫公共性的程式碼，比如列印收到的cmd內容，還需要在switch裡特別強調default分支：我們不支援這個命令。。。
既然kestrel基於連線處理中介軟體，上層的asp.netcore也是基於請求處理中介軟體，我們完全也可以也依葫蘆畫瓢，造一個Redis命令中介軟體Builder，最後將所有Redis中介軟體串起來，Buid得一個Redis處理委託。
var builder = new PipelineBuilder<RedisContext>(appServices, context =>
{
// 沒有handler來處理
return context.Client.ResponseAsync(RedisResponse.Error("unsupported cmd"));
})
.Use((context, next) =>
{
this.logger.LogDebug(context.ToString());
// 驗證客戶端是否已授權
return context.Cmd.Name != RedisCmdName.Auth && context.Client.IsAuthed == false
? context.Client.ResponseAsync(RedisResponse.Error("need auth password"))
: next();
});
// 新增各個cmd對應的handler條件分支
appServices
.GetServices<IRedisCmdHanler>()
.ForEach(item => builder.When(item.CanHandle, item.HandleAsync));
this.handler = builder.Build();
在RedisConnectionHandler，每收一個Redis命令，將命令包裝為RedisContext，然後使用build出來的handler物件來處理這個RedisContext就行。剩下的工作，就是我們一個命令實現一個IRedisCmdHanler物件就行，邏輯完全分開。
IRedisCmdHanler介面：
/// <summary>
/// 定義redis命令處理者
/// </summary>
interface IRedisCmdHanler
{
/// <summary>
/// 返回是否可以處理
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
bool CanHandle(RedisContext context);
/// <summary>
/// 處理
/// </summary>
/// <param name="context"></param>
/// <returns></returns>
Task HandleAsync(RedisContext context);
}
3.4 統一Redis和Signal客戶端操作介面
在Signal和Redis訂閱之後，我們將他們的連線包裝為統一介面的IClient物件，IClient提供PublishAsync()方法用於釋出訊息。
/// <summary>
/// 定義客戶端的介面
/// </summary>
public interface IClient
{
/// <summary>
/// 獲取唯一標識
/// </summary>
string Id { get; }
/// <summary>
/// 獲取連線時間
/// </summary>
DateTime ConnectedTime { get; }
/// <summary>
/// 獲取客戶端型別
/// </summary>
[JsonConverter(typeof(JsonStringEnumConverter))]
ClientType ClientType { get; }
/// <summary>
/// 傳送訊息
/// </summary>
/// <param name="message"></param>
/// <returns></returns>
Task<bool> SendMessageAsync(Message message);
}
3.5 IClient管理器
我們還需要維護一份單例的IClient管理器物件，用於維護正在訂閱的客戶端，在釋出訊息時，從這個管理器裡查詢IClient，並呼叫SendMessageAsync()方法釋出訊息內容。
3.6 SignalR部分
由於SignalR的內容非常簡單，官方文件細節齊全，這裡將不作任何講解了。
4 總結
由於要講解的內部比較多，篇幅和時間都有限，本文就只從思路上大概講解Kestrel在多協議連線的場景的使用方式。一句話，中介軟體的使用，使得這些場景變得簡單，那問題來了，什麼是中介軟體，你理解了嗎？