全栈终结者-把nuxt扔进垃圾桶、Blazor与seo的化学反应

科技 06-21 来源：一往无前松鼠k2

#头号周刊#

目标

实现一个包含BBS、博客、工具、常用工具类整合型网站,自己运营

技术考量要点

结合其传播特点,需要整体考量SEO
服务因涉及到工具挂接特性、类App集市特点,在加上SSR服务端渲染,需考虑并发扩容问题,考虑Nacos集成netcore集成微服务架构形式
博客、社交从业务复杂性上并不复杂,但另外一个维度的问题是以人为中心、关系、生产数据会随着运营巨量化,之前有调研基础,考虑过一种骨骼特性化（即,个体的特征数据结构化,具体的细节以皮肤纹理去补充）
数据库层级考量,通过分库分表的方式破坏性强,人力成本太高,暂时考虑的模式为mysql仅管理网站显示内容,用户的相关个体生产数据及关系存储到mongo,骨骼特性话存储,需要时再抓取

技术调研

Seo Ssr考量,最优先想到的时nuxt,经过2周反复的考量,最终放弃了这种处理

找到了一个开源的vue,nuxt仿掘金的、vue单页无SEO的做的都很好,但是服务端渲染貌似只能用node，如果换成其他服务端成本太大,我调研了2周,找了好几个,从部署和服务扩展性上彻底放弃了这个方案

nuxtcontent也反复看了一下,觉得就是前端线路的解决方案

另外工具网站也参考了一部分

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生服务范式) 服务基础设施。因为netcore之前的微服务方案有点儿不太理想,具体应用一段发现nacos挺理想,也支持netcore服务接入,这会儿算是找到我比较满意的方案了,(至于为啥不用java,还是一句实在化,部署和调试维护层级考量)
服务端问题因为之前有做聊天软件的朋友有咨询,给他提过相关的优化方案,他的实际问题就是app用户量上来之后导致性能很差,只能不停的补窟窿,当时我就过骨骼特性化设计的思考,还有常规的分库分表
mysql数据库层级实践后发现,服务分部署部署,要补的窟窿有点儿多,单纯个人的力量成本太大，雪花ID生成规则、表自动创建扩展、复杂的排序扩展查询,主从备份,读写分离等等问题,也就自然而然的放弃了，因为达不到预期。

技术定型-柳暗花明

前因

之前有看到过antd有出过一个Blazor相关的组件，但没有具体去细看,最终的一个技术验证让我柳暗花明，最开始可能和你们想法一样，觉得是技术考古，看了几天都觉得网上很多帖子都没完整的说明白,为什么Blazor更棒

不管是asp、jsp、mvc那一套东西其实走的线路一直是ssr,本来就是老本行职业,所以seo这块的东西毋庸置疑。
asp、jsp、mvc技术被淘汰的本质原因是显示效果,单页面渲染的诉求，另外就是ssr资源加载卡白屏、前后端职能清晰、前端框架性组件井喷等综合性考量导致的结果,另外就是特性式的写法很让人诟病
C#的没落主要是,不能跨平台、笨重,后两年的netcore系列虽然支持了跨平台部署，但又频繁的更新了2年,直到net5,net6才算稳定成型，jsp就不用说了,算是放弃状态,历史残留物。
原本asp,其实也有组件化写法,但怎么说，弊病太严重,根本无法有效的兼容js、css等内容,而且不利于长期的运维

后果

Blazor 是一个使用 Blazor 生成交互式客户端 Web UI 的框架：

使用 C# 代替 JavaScript 来创建信息丰富的交互式 UI。
共享使用 .NET 编写的服务器端和客户端应用逻辑。
将 UI 呈现为 HTML 和 CSS，以支持众多浏览器，其中包括移动浏览器。
与新式托管平台（如 Docker）集成。
使用 .NET 和 Blazor 生成混合桌面和移动应用。

使用 .NET 进行客户端 Web 开发可提供以下优势：

使用 C# 代替 JavaScript 来编写代码。
利用现有的 .NET 库生态系统。
在服务器和客户端之间共享应用逻辑。
受益于 .NET 的性能、可靠性和安全性。
使用开发环境（例如 Visual Studio 或 Visual Studio Code）保持 Windows、Linux 或 macOS 上的工作效率。
以一组稳定、功能丰富且易用的通用语言、框架和工具为基础来进行生成

重点

Blazor Server

Blazor Server在 ASP.NET Core 应用中支持在服务器上托管 Razor 组件。可通过 SignalR 连接处理 UI 更新

Blazor WebAssembly

Blazor WebAssembly 是Blazor WebAssembly，用于使用 .NET 生成交互式客户端 Web 应用。 Blazor WebAssembly 使用无插件或将代码重新编译为其他语言的开放式 Web 标准。 Blazor WebAssembly 适用于所有新式 Web 浏览器，包括移动浏览器

Blazor Hybrid

混合应用混合使用本机和 Web 技术。 Blazor Hybrid 应用在本机客户端应用中使用 Blazor。 Razor 组件在 .NET 进程中本机运行，并使用本地互操作通道将 Web UI 呈现到嵌入式 Web View 控件。

结果导向

-从特性上说,确实发展性可以,而且性能没得说,生态也比较丰富

从组件化习惯来说,也趋近于react、vue（起码一定程度上扩展性没有问题）

对于后期部署及负载均衡来说,简直不要太契合整体对前后端做负载均衡及分布部署不详嘛,而且一体化的vs开发环境,体验效果不要太好

后续

重点无脑吹了波Blazor,后续关于"骨骼特性化"特性设计放在后续的大篇幅陈述
至少是bbs显示部分会考虑用blazor进行尝试,最终会补充成品及过程,至于管理端会视情况而定，初步还是会用vue去处理，因为不必考虑seo,又有整套验证过的crud,会节省花销一些
关于nacos和netcore相关过程,留待验证更新,netcore linux随后就会更新
BBS服务端设计也会紧接着进行