本文关键字：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要尽量小。
———
(此处不设回复，扫码到微信参与留言，或直接点击到原文)
