系统更换中,可能存在不可预料的 BUG

November 16, 2020

WIP: 另一种前后端同构

一般来说的前后端同构都是指用 React 之类的支持 SSR 的框架做服务端预渲染,然后直接混入进行 render 的一种提升用户体验的方式。

实际上在服务端本身就存在同构这种形式,上面说的前后端同构只是代码层面的同构,本质上是运行时的异构,所以或许我们能从异构计算中获取到一些灵感。

广义上,不同计算平台的各个层次上都存在异构现象,除硬件层的指令集、互联方式、内存层次之外,软件层中应用二进制接口、API、语言特性底层实现等的不同,对于上层应用和服务而言,都是异构的。

所以前后端在 SPA 应用上一直存在着因为异构而造成的巨大的鸿沟,而这些年也逐步从分离走向融合。早期 SPA 让后端能把业务下放到前端,而近些年 SSR 成功把前端的渲染推到了后端,而 WASM 更是把 CPU 密集型任务的处理,也就是边缘计算引入了浏览器环境中。

和 Brower/Server 模式对比的就是 Client/Server 模式,或者是更纯粹的单机应用,那么随着浏览器算力的逐步提升,是不是可以把 Brower 和 Client,甚至 Server 进行对等,比如存在一种称之为 RealTime DB 的奇妙的数据库类型,他们通过事件机制,让所有的连接者共享特定的数据,在这种情况下,除非网络断开,否则我们并不能知道是否存在明显的 B/S 的特征,还有浏览器挖矿来取代 Ad,以及 IPFS 和 WebRTC 这种弱化 Server 的应用场景。

那么是否存在一种能够对这个同构进行更佳系统化融合的方案,这时候我们就应该借鉴一下云计算的特性。

既然从应用上浏览器环境已经有了一定的实践,我们是不是应该引入更深层次的融合,比如:尝试将浏览器环境类比与云计算中的工作节点,将后端的任务再进一步的前移,尝试在浏览器和服务器端建立一种异构计算的模式,让浏览器作为异构计算的一个更加私有和富有弹性的计算节点,比如引入 Actor 模型来封装网络层作为消息总线来引导分布式环境下的工作。

如果我们成功使用 Actor 模型对业务进行合理的分割,那么 Actor 作为一个执行单元,实际上是可迁移的,既然弹性计算无法确定计算节点的位置,那么即使在浏览器中好像也没什么问题。

这样我们就是假定一个这样的同构方案,通过 Actor 模型作为消息总线,对其包装的模块进行同构,从而实现将浏览器作为边缘计算的节点来使用。

© Gitai 2011

Powered by Hugo & Kiss.