皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

SignalR Core尝鲜

作者 Geovanny Alzate Sandoval    ,译者 一念无明 

要点

  • SignalR Core改用Microsoft.AspNetCore.Sockets,不再依赖HTTP。
  • 使用MessagePack序列化格式,支持二进制协议。
  • TypeScript客户端移除了第三方依赖包。
  • 支持WebSocket原生客户端,可以使用自己构建的客户端连接到SignalR服务器。
  • 伸缩方式更灵活,可以通过自己实现的方式进行横向扩展。

几个月前,SignalR Core团队发布了一个非官方版本的ASP.NET Core SignalR。为此,开发人员有机会了解其工作原理以及ASP.NET SignalR与Signal Core新架构之间的区别。

SignalR Core中移除了哪些特性

通过对比两个版本的SignalR可以发现,新版本不再支持一些重要的特性。首先是移除了对jQuery和其他第三方类库的依赖,因为新版本的JavaScript客户端是使用TypeScript开发的。其次是自动连接后的消息重放功能,移除该功能主要是出于性能方面的考虑。服务器需要为每一个连接维护一个缓冲区,用于保存消息,以便后续重新发送。当客户端断开连接,可以尝试重新恢复连接,然后将未发送的消息发送给客户端。可以想象,如果有很多客户端断开连接,而且每个客户端都发送大量的消息,对于服务器来说是个很大的负担。另一个被SignalR团队移除特性是多Hub端点,所以,在新版本里,每个连接只有一个Hub。

新版本的SignalR Core不再支持横向扩展(Scale Out)模型,原因是MessageBus被当成了横向扩展的“万灵丹”,但它实际上只支持Azure Service Bus、Redis和SQL Server。在实际的协作场景当中(客户端到客户端),随着客户端和消息数量的增长,通过以上三种方式进行横向扩展会有瓶颈问题。

不过,我认为,移除横向扩展功能这一决定有点太过激进,因为在某些场景下,MessageBus仍然十分有用。例如,在将SignalR作为一个广播服务器时,它可以控制发送消息的数量。而在SignalR Core的alpha版本中,开发者可以根据实际情况选择是否进行横向扩展,如业务需求、系统约束或基础设施,这种设计更加“可插拔”。SignalR Core团队提供了一个使用Redis进行横向扩展的示例。其他扩展方式可能会被包含在SignalR Core的最终版中。

最后一个被移除的功能是多服务器间的双向复制(backplane),因为这个功能会在服务器场生成太多的流量。ASP.NET SignalR通过MessageBus在服务器间复制每一个消息,因为客户端无法直接连接到服务器场,而现在,SignalR使用粘性会话来避免在所有服务器间复制消息。这样一来,SignalR Core就可以知道哪个客户端连接到了哪台服务器上。

SignalR Core中增加了哪些新特性

现在让我们来看一下SignalR Core带来了哪些新的特性。首先是使用了二进制协议来发送和接收消息。在ASP.NET SignalR中只能使用JSON格式的文本来发送和接收消息,而现在则可以使用二进制协议,该二进制协议基于MessagePack序列化格式,比JSON更快、体积更小。

主机无关性是另一个非常重要的特性,有了这个特性,就可以移除对HTTP的依赖。现在,我们可以在HTTP或TCP之上使用SignalR。端点API也是非常重要的一个特性,它是基础的构建块,用于支持主机无关性。因为新版本是基于Microsoft.AspNetCore.Sockets这一底层的网络抽象层,所以可以直接使用Socket。这么说来,SignalR Hub其实也就是一个端点。

多格式也是一个很酷的特性,有了这个特性,我们可以处理任意格式的消息。我们可以使用多种不同的客户端连接到同一个端点,这些客户端可以使用不同的消息格式。也就是说,SignalR Core已经实现了消息的格式无关性。这个示例在同一个端点上使用了三种格式(JSON、PIPE和Protobuf)来读写消息,因为使用了自定义的处理器,可以无缝地处理各种格式的消息。正如之前提到的那样,可能是因为使用了Microsoft.AspNetCore.Sockets,从底层来看,消息都只是简单的二进制字节。

新版本还支持WebSocket原生客户端,所以开发者也可以使用除SignalR Web客户端之外的其他客户端。之前,开发者必须使用基于JavaScript的Web客户端连接到SignalR服务器上。现在,开发者可以自己开发客户端,充分利用浏览器API提供的优势。当然,开发者也可以使用最新的TypeScript客户端,因为TypeScript提供了很多有用的特性。另外,客户端是通过NPM包管理器进行发布的,这样依赖管理也就变得更简单了。

最后一点是,横向扩展变得更灵活,提供了更高的可扩展性。SignalR Core团队简化并改进了横向扩展模型,并提供了一个基于Redis的横向扩展示例,帮助开发者了解如何进行横向扩展。

去年9月14号,SignalR Core团队发布了第一个alpha版,10月9号发布了第二个alpha版,也就是SignalR Core 2.0官方预览版。现在,我们即将探讨这一版本中包含的主要变化。

在得知有新版本后,我在第一时间去拉取代码,并试着去构建最新的代码。不过,正如预期的那样,因为代码还在开发当中,无法立马构建成功。尽管如此,我们还是能够在第一时间看到正在发生的变更,这有助于我们了解为什么要做出这些变更。接下来,我将列出我在构建过程中遇到的问题,并告诉大家我做了哪些事情来修复这些问题。

要在项目中使用SignalR Core,必须引用Microsoft.AspNetCore.SignalR,最新版本是1.0.0-alpha2-final。

HubConnectionBuilder

在之前的版本中,如果要在服务器端连接到一个Hub,我们会使用HubConnection类,比如:

var connection = new HubConnection(new Uri(baseUrl), loggerFactory);

而现在,我们需要使用HubConnectionBuilder类(实现了Builder设计模式)来连接SignalR Core Hub,这也是第一个导致代码构建失败的变化。这一变化让建立连接变得更具可扩展性,不需要使用满是参数或带有null参数的构造函数。我很喜欢这个变化,因为它简化了建立连接的过程。

var connection = new HubConnectionBuilder()
                        .WithUrl(baseUrl)
                        .WithConsoleLogger()
                        .Build();

在服务器端处理连接

在之前的版本中,客户端在“On”方法中处理由SignalR Hub广播过来的数据,这个时候需要处理一大堆参数:

connection.On("UpdateCatalog", new[] { typeof(IEnumerable<Product>) }, data =>
{
    var products = data[0] as List<Product>;
    foreach (var item in products)
    {
        Console.WriteLine($"{item.name}: {item.quantity}");
    }
});

可以看出,这个方法有点累赘,因为不管用不用得到方法里的参数,都必须指定这些参数和它们的类型,即使用不到,也要指定一个空数组。但问题是,处理器的参数是无类型的,所以,即使在数组中指定了类型,仍然需要遍历数组,对它们进行类型转换。

而新版本的SignalR Core提供了最新的泛型方法重载机制,通过这种方式指定参数类型后就不需要再进行类型转换。泛型方法对原始方法进行了包装,从而简化了开发者的工作。最终的代码更简单、可读性更好。

connection.On<List<Product>>("UpdateCatalog", products =>
{
    // now, “products” parameter is a List<Product> type.
    foreach (var item in products)
    {
        Console.WriteLine($"{item.name}: {item.quantity}");
    }
});

命名约定

我发现Invoke方法名发生了变化(这个变化也导致代码构建失败):

await connection.Invoke("RegisterProduct", cts.Token, product, quanity);

这是一个异步方法,为了遵循命名约定,方法名被改成了InvokeAsync,方法参数的顺序也发生了改变,令牌参数被放在了最后:

await connection.InvokeAsync("RegisterProduct", product, quanity, cts.Token);

因为遵循了命名约定和标准,开发者在使用SignalR Core API(包括SignalR Core的开发者团队)时就更加直观,因为它带来了代码的统一性。例如,如果开发者在他们的IDE中使用了Intellisense,就可以提前知道这个方法是异步的。

另一个与命名约定有关的变化是MapEndpoint方法,这个方法被改成了MapEndPoint,遵循了Pascal的大小写风格

之前:

app.UseSockets(routes =>
{
    routes.MapEndpoint<MessagesEndPoint>("/message");
});

现在:

app.UseSockets(routes =>
{
    routes.MapEndPoint<MessagesEndPoint>("message");
});

可以看到,现在不使用“/”符号了。MapHub方法也一样。不过,我们发现这里存在一个问题,这些方法没有使用PathString API。不过,在下一个版本中会继续使用“/”,与其他的.Net Core API保持一致。

命名变更

命名方面发生了很多变更,其中一个是与Connection类有关的ConnectionContext。ConnectionContext包含了与连接相关的信息,如元数据、通道等。

之前:

public override async Task OnConnectedAsync(Connection connection)

现在:

public override async Task OnConnectedAsync(ConnectionContext connection)

另一个命名方面的变更与ConnectionContext中的Transport有关。之前,用于管理输入和输出的属性分别叫作Input和Output,而现在它们被改为In和Out。

之前:

connection.Transport.Input.WaitToReadAsync()
connection.Transport.Output.WriteAsync()

现在:

connection.Transport.In.WaitToReadAsync()
connection.Transport.Out.WriteAsync()

TryRead和WriteAsync

TryRead和WriteAsync方法得到了简化。之前,它们接收一个Message对象作为参数。

之前:

Message message;
if (connection.Transport.Input.TryRead(out message))
{
    ...
}

connection.Transport.Output.WriteAsync(new Message(payload, format, endOfMessage));

现在:

// message is byte[]
if (connection.Transport.In.TryRead(out var message))
{
    ...
}

// payload is byte[]
connection.Transport.Out.WriteAsync(payload);

现在他们使用字节数组作为参数,因为底层的Socket使用了Channel<byte[]>。SignalR Core团队认为,将字节数据移到上层可以让Socket层的逻辑更清晰。之前,SignalR Core团队在字节数据之上使用了一个底层的数据帧协议(不过WebSocket已经有数据帧,所以没有在WebSocket上使用该协议)。

因此,Microsoft.AspNetCore.Sockets层得到了“净化”,只允许端点处理二进制数据,而端点就可以使用任何一种协议,比如TCP或HTTP。

底层的数据帧协议是在Microsoft.AspNetCore.SignalR层实现的,所以消息类型、数据帧都是在实现了IHubProtocol接口的类中处理的,比如JsonHubProtocol和MessagPackHubProtocol。这种设计提供了一种可扩展的方式用于实现其他的Hub协议。

其他变更

我们可以直接通过NPM管理器来安装signalr-client,比如,我在package.json文件里将它作为客户端依赖:

{
  "version": "1.0.0",
  "name": "asp.net",
  "private": true,
  "dependencies": {
    "@aspnet/signalr-client": "^1.0.0-alpha2-final",
    "jQuery.tabulator": "^1.12.0"
  }
}

Visual Studio会在构建解决方案时自动安装这个包。当然,我们也可以使用.NET Core内置的新特性,它会自动把signalr-client文件拷贝到wwwroot目录,这样就不需要再使用gulp、grunt或其他任务执行器了。

[
    {
        "outputFileName": "wwwroot/lib/signalr/signalr-clientES5-1.0.0-alpha2-final.min.js",
        "inputFiles": [
            "node_modules/@aspnet/signalr-client/dist/browser/signalr-clientES5-1.0.0-alpha2-final.min.js"
        ],
        "minify": {
            "enabled": false
        }
    },
    {
        "outputFileName": "wwwroot/lib/signalr/signalr-client-1.0.0-alpha2-final.min.js",
        "inputFiles": [
            "node_modules/@aspnet/signalr-client/dist/browser/signalr-client-1.0.0-alpha2-final.min.js"
        ],
        "minify": {
            "enabled": false
        }
    }
]
默认情况下,.NET Core启用minify选项,而我引用的文件已经被minify过,当它尝试再次minify这些文件时就会报错,于是我就把minify选项禁用了。

结论

以上就是我在升级到最新版SignalR Core时发现的一些变化。我把它们分享出来,让其他开发者也知道这些变更以及为什么要做出这些变更。我希望这些信息对大家有用,也鼓励大家在自己的项目中测试最新的SignalR Core。

我花了几个小时解决在构建新版本代码时遇到的问题,而查看代码和理解这些变更又额外花了我几个小时时间,不过这些都是值得的。

关于作者

SignalR Core尝鲜Geovanny Alzate Sandoval 是一名来自哥伦比亚麦德林的系统工程师,他喜欢所有与软件开发、新技术、设计模式和软件架构相关的事物。他已经在该领域工作了十多年,做过开发者、技术负责人和软件架构师。他乐于向社区做贡献,喜欢在博客上写与微软新技术有关的东西。另外,他还是麦德林.NET开发者社区MDE.NET的联合组织者。

查看英文原文:First Hand Account of SignalR Core

转自 http://www.infoq.com/cn/articles/signalr-alpha