分类:  Blazor入门    ◆ 标签:  #Asp.Net core基础   #.Net   #Web Client   #Blazor   ◆ 发布于: 2023-05-21 19:23:31

前面的文章我们简要的介绍了什么是blazor以及给大家分享了两个hello world, 并且分别基于blazor框架的两种部署模式：WebAssembly部署模式和基于Blazor Server的部署模式。从Blazor的开发历史上来看是先在.net Core 3.0时发布了Blazor Server，然后在.net 5才发布了Webassembly。 但是这里有很多问题，例如：

• Blazor Webassembly和Blazor Server优缺点是什么？

• Blazor WebAssembly和Blazor Server分别适用于什么场景？

• Blazor Server和传统的基于Razor Page或者ASP.net Core MVC的应用到底有什么不同？

接下来的文章我们会围绕这几个主题一一展开讨论，希望大家能够多多关注，关注新技术的发展，并适当的充实自己的工具箱。

这里分享一篇微软的DevBlog, 这里详细的讨论了微软针对于Blazor框架的未来前景和探索：
https://devblogs.microsoft.com/aspnet/blazor-server-in-net-core-3-0-scenarios-and-performance/comment-page-2/

微软的技术团队在这里篇文章里详细的讨论了Blazor Server和Blazor Webassembly适用的场景，您可以参考这篇文章，当然我们也会在这篇文章里进行转述。

非常值得注意的是，这篇文章里提到未来的几点：

• Blazor PWAs应用：可以提供离线的场景支持，例如通知推送，和OS系统功能的集成等。

• Blazor Hybrid应用：本地程序使用web技术进行UI的应用的开发，直接使用本地的.Net运行进行驱动，预计应该是.Net 6可以支持。

• Blazor Native应用：当前的Blazor对应用的UI的渲染在这个类型的应用中会被基于本地的渲染应用所取代，完全运行在本地利用本地的UI库进行渲染。但是开发的理念还是和现在的理念一直，这个就太厉害了。

从这篇文章介绍中，我都感觉Blazor将来有可能会采用统一的设计理念和代码统一UI的开发，并且跨平台，多设备支持，非常期待微软技术团队能够完成这个宏大的理念。

回到正题，本篇文章主要讨论如下几个问题：

• Blazor Server应用和传统的Razor Page以及MVC 应用有什么区别？

• Blazor Server有哪些需要注意的技术要点。

• Blazor Server适用于哪些应用场景。

Blazor Server应用和传统的Razor Page以及MVC 应用有什么区别？

首先需要明确的是Blazor框架并不是为了取代Razor Page或者MVC类型的应用，Blazor框架的出现是为了补足Razor Page和MVC应用在一些应用场景上的不足。

要理解Blazor Server和Razor Page和MVC的不同，我们先看类似点：无论Blazor还是Razor Page（MVC, MVC使用Razor View instance, 后面我们都使用Razor 系来指代这二者）都是在基于ASP.net Core的服务段对客户端需要的UI进行渲染，这是相似点，但是最主要的不同点在于：

Razor系的渲染在每次用户的请求到达之后，Razor引擎会将整个视图全部编译并输出整个的基于txt格式的html内容(包括css, javascript), 虽然我们可以在Razor段设置缓存，但是编译和输出都是全部的HTML页面，而Blazor Server应用则不同，主要不同点在于：

• Blazor Server应用是由多个不同的组件组成的，想象一下：一个html包含很多个块，例如一个菜单栏，一个内容显示的块，几个按钮，这些在Blazor Server应用中每一个都可以定义为一个通用的组件，并且可以对每个组件设计不同的可以传入的参数，从而控制每个组件的不同表现。

• Blazor Server应用的各个组件在渲染的时候，会在内存中形成一个基于DOM的图表，当客户端的UI更新事件到达后，Blazor会根据DOM的图标计算相应组件的的更新，并将更新以二进制的格式传送到客户端，客户端只需要渲染相应组件的更新，而无需像razor系那样全面更新（razor 系想要做成这样需要使用javascript库，例如Jquery通过请求web api返回内容，然后需要在客户端写很多代码完成这个动作，但是blazor server不需要，可以尽量保持的瘦客户端）

• Blazor Server还有一个更好的特性就是组件预渲染（基于DOM), 并且是以二机制格式保存在内存中，当客户端和Blazor Server建立了一个链接之后，Blazor Server即会对相应的组件进行预渲染，当UI事件到达Server端之后，预渲染只需要比较不同，这样极大的缩短UI的渲染时间，从而给客户端更好的感受。

以上是从对于客户端内容的渲染上来描述最大的不同，同时要理解Razor 系和Blazor Server之间还有更大的不同在于，Razor系应用客户端基于无状态的http协议链接服务端，每次请求如果不借助cookie或者session, 客户端所有的请求都是无状态的请求，但是Blazor Server不同，对于Blazor Server应用，客户端必须通过SignalR协议和Blazor Server保持持续的链接，所有的客户端的UI事件都必须通过SignalR协议即时传送到Blazor Server端。这就会给我们引入下一个需要讨论的点

Blazor有哪些需要注意的技术要点？

前面我说了基于Blazor Server的应用本质上是一个瘦客户端的应用，同时客户端是必须通过SignalR的协议链接到Blazor Server服务端，通过该协议将所有的UI事件发送到服务端，并由服务端进行相应。这里有一个概念：

• Circutis(中文翻译我一时没想好，要不就翻译为环路吧）环路：
  当客户端链接到Blazor Server端时，建立一个SignalR链接之后，即拥有了一个环路，环路这个概念是一个抽象概念，主要是基于SignalR协议的，它的意义在于，每个环路是有状态的，前面我们讲过Blazor Server会对每个组件进行预编译，同时在内存里维护组件的结构图表对吧？那么这个环路的主要作用就是维持一个客户端和服务端之间的状态，同时由于环路的概念存在，运行客户端和服务端之间短暂的网络故障，当客户端发现由于网络原因无法和服务端进行通讯之后，它会自动进行重试，一般情况下重试8次左右，当网络故障消失，客户端会自动重连，并且恢复之前的状态，也就是各组件的状态还保持在服务端。

• 相较于Razor系的应用，由于无需在服务端保持状态，因此在UI编译和渲染上，内存使用上有优势，但是基于Blazor Server的应用会增加内存的使用，因此对于这点尤其要注意。

• 同时需要注意的是由于客户端是通过SignalR协议链接服务端，并且是由状态的，这个时候，如果后端为了应付压力需要扩展多个后端实例，这个时候就需要注意了，我们需要客户端通过负载均衡或者网关进来之后，同一个客户端必须总是链接到同一个后端服务器上，这样的话，如果你的blazor Server应用部署在Azure Web上一定要启用ARR支持。如果是在本地基于IIS部署也定要打开ARR支持，如果是在Linux系的前端上部署的，需要找相应的服务配置确保Blazor Server 针对客户端路由到同一个后端服务上。官方推荐如果您有大量的服务，建议直接使用Azure SignalR服务，例如网络聊天程序。

• UI的网络延迟，针对于Blazor Server的应用，我们要尽量优化内存的使用，关于这方面的指导，微软官方有一个指导文档：https://docs.microsoft.com/en-us/aspnet/core/blazor/security/server/threat-mitigation?view=aspnetcore-5.0,  后继我们也会对这些文档进行详细的解析。

以上是基于Blazor Server应用的技术要点，在我们的开发工作中应该时刻牢记这些不同的点，并优化自己的应用，关于如何优化这个部分我们后继的文章也会一一介绍。

Blazor Server适用于哪些应用场景？

如果你需要一个交互性非常强的单页应用，那么Blazor Server应用就非常适合。

另外如果您的客户和服务端之间有非常好的网络连通性，或者客户端和服务端在同一地理区域内，都可以考虑Blazor Server应用。同时Blazor Server应用不是为了替换你的MVC应用或者Razor应用，在同一个应用中完全可以同时混用，当然你也可以完全使用Blazor Server构建新的应用，假如你将您的应用完全设计为一个单页应用。

Blazor Server性能到底怎么样？

通过微软官方宣布，基于.net core 3.0, 使用一个Azure Standard_d1_v2实例（1个vCPU, 3.5G内存）通过压测可以支持5000用户的并发。一个标准的Azure Stand_d3_v2 虚拟机实例（v个vCPU, 14G内存）通过压测可以支持20000用户的并发。对很多中小型的应用已经可以应付了，如果直接使用Azure Web App或者Azure SignalR 服务，使用Azure的auto-scale功能完全可以应付超高的并发。

本章的深入介绍目前就介绍到这里了，如果您有任何疑问，欢迎联系我。