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

SignalR Core尝鲜

2018-03-20 分类：开源资讯 评论(0)

作者 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

                       

相关推荐