打造一个Applevel虚拟化,内置plan9的rootfs:goblin(1)

本文关键字:applvl Virtualization。去中心化,无架构APP

我们知道云计算最大的特点就是虚拟化,将云虚拟化,将裸金属虚拟化,将CPU虚拟机vmm,将平台虚拟化,将语言运行时虚拟化,将appstack虚拟化。这种“云化,虚拟化,xaas化”动作其实正是传统最基本的抽象,正如保护模式划分CPU,进程划分任务之于”单机运算“一样,这些只是在传统架构上造云的步骤,本不足为奇 —— 但这些所有虚拟化,却唯独少了最后一个层面,将app本身虚拟化,这种工作似乎鲜少进行。

这是因为我们以为程序都是堆成的,一层一层,只要解决了上面的虚拟化,得到的最终会是最小的虚拟化,从上而下地虚拟化,和从下而上地将APP虚拟化,,这二者的复杂度和工作量都一样,但其实,对于最终开发者来讲,这二种方案造成的复杂度其实有着天地之隔。传统从上而下,开发者需要面对所有的复杂度,只是它们被抽象简化了,而从下而上,最终开发者仅需要面对领域逻辑。虚拟化方向和粒度的不同导致的差别很大。

golang的去中心无架构设计

在《golang》中我们谈到golang是一种将portable langvm植入app层次的语言系统,由于这个langvm是与x86无关的非常小,而且go语法是类过程C的非常精简,所以它带来了分布式和分布式开发的新语言规范,—— 大概没人想到会将一个单APP demo和运行层作为架构来集成,但事实是,go将语言运行时虚拟化集成到单app的方式也证明十分好用。我们知道,golang在源码层有着日常可见的那些deps,在发布层开始显露其本质不同:每个Go发布出去的单元,只是发布级/二进制级无依赖。无须依赖:对于移植度,它将解决移殖的方案集成到app内部而非一个共享虚拟机,对开开发和通常行为,这种运行层的去依赖,去堆栈化,打破了传统程序是一层一层堆起来的现实,没有一个对OS,langlibs,3rd party libs的复用,引用中心。也就把架构去掉了,这像极了去中心化和无架设设计 —— 这种“去中心,无架构设计”什么好处呢?这种使得所有跟APP有关人的活动局限于本app demo运行时内部,它使最终开发者不需要面对一层一层继续下来的复杂度,再开发者不需要管任何东西。—— 这才是一种一了百了的工作,这种虚拟化才是不需要管的东西,只要保证每个app内部的这个虚拟部分足够小足够可用,反之,一层一层的虚拟化,这种复杂化成本还是给了开发者。这在源码级也是一样的,我们以为一层层的抽象解决了大部分问题,领域逻辑变成了最终开发者需要面对的,但最终现实中开发者却看到不一样的事实。

applvl全虚拟化设计

虚拟化可以交叉设计。关键是找到正确好用的粒度,那么,除了golang,这种APP级的虚拟化重设计还有哪些呢?相似的设计还有:在前面《hyperkit》一文中,我们谈到这是一种将虚拟机植入app层次的设计,我们在《plan9》中还谈到,plan9是一种定义了9p分布协议的分布式OS,原生的plan9 os是受plan9 kernel支持的,但也存在一种usr space plan9 rootfs,可以用上9p协议。那么,能否将它也欠入到具体app中,,比如,将plan9 roofs 作为busybox欠入到每个app中。。而plan9和busybox shell式programming,如果还能加上go,其好处是:go这种本地程序,本地开发和远程程序,分布式开发合一的语言系统,无依赖,无架构,才能集成,无架构,才能post as app,程序不是预置的长设计蓝图,而是实时的调用,自包含,但并不意味没有复用。

这样就带来了一种applevel的全虚拟化,前提是,保证产生的每一个APP要尽量小。

———


(此处不设回复,扫码到微信参与留言,或直接点击到原文)

https://gitee.com/minlearn/minlearnprogramming/:minlearn的最小编程学习集和实训栈方案。
原文地址:https://www.cnblogs.com/minlearn/p/13771262.html