一种追求高度融合,包容软硬方案的云主机集群,云OS和云APP的架构全设计

原创
2020/09/29 00:09
阅读数 61

本文关键字:兼容多主机硬件设计,兼容多os,兼容native/cloud程序模型,兼容本地程序/分布式程序。网络操作系统,不是x11,不是远程桌面,不是web nas,不是pouch存储同步。不是远程投屏。

云在人们的观念中就是远端,它承诺将计算发展成水电煤一样的可被直接利用的资源,与内容和我们本地的客户端或终端接入(所以有了云存储,云GPU等各种传统资源的云化,以及一些或细分或复用的云资源,如云验证,云游戏,etc..),虽然云技术的背后是一层一层的虚拟化,可是它并没有将这种工作进行到我们日常使用APP方面,作为用户,我们还是停在手机上装APP使用云资源的历史情景下 —— 试想一下,我们老早以前就有网络操作系统,TCP/IP这样的C/S程序。可是一直到现在,我们依然这样子使用云。——— 云程序没有过任何改变。它只是将服务端越做越肥兼带更强大的content streaming的改变(比如即将到来的5G)。

稍微涉及到复杂一点的自建云/云系统管理情形下,比如群晖,ECS,裸金属虚拟化,虽然云装机的方式更灵活多样,但我们发现我们最终还是在使用传统的OS来建立和使用云。还有远程桌面,vnc,远程桌面,局域网tou屏,wifi display,ip kvm,x11,web界面,这些永远是我们解决操作远程OS的方式。

云APP进化到现在最高级的形式,也就是webapp,它尝试解决一部分问题,可是它似乎依然不够完善,比如,它如同一些本质是”伪remoteapp“一样,永远基于某种远程界面,一部分逻辑在远端。无权直接访问本地资源,且延时较高。

PS:以上三个问题,表层来看,是因为云APP总有个OS,它与本地分属二个OS二个独立迥异的运行实体,这种现实割裂了我们原来使用本地操作系统操作APP来操作远程APP的习惯。—— 人们一般把兼容多OS称为云OS(如fydeos,openstack,linux,windows,etc..),把分布式APP称为云APP(web算,走socket的也算。。p2p去中心的算,暗网的也算。。)。这些OS从来都是相互的复合,早就被设计成单机OS+tcpip,从来没变过,只是被分布到了网络。所以它不可能有真正的分布式。——— 小到content streaming,vnc,大到开发,甚至一切,都只是权宜之道。。以至我们没有过真正的分布式OS和分布式APP,一直在web的小概念里打滚。见我的《打造一个Applevel虚拟化,内置plan9的rootfs:goblin(1)》,我认为这是因为我们始终把“真正的分布式”做到APP层次。短板理论下所以一切都是伪的。

分布式架构的本质问题是OS和APP的选型和实现问题

分布式架构本质是巨大的问题,这是我们bcxszy一直努力选型与实践的目标,因为有前面文章的铺垫,我们现在深入分析这个问题:

在前文《兼容多OS or 融合多OS?打造基于osxpe的融合OS管理器》中,我们看到,有时为了实用。我们宁愿牺牲少量的性能,选择融合这种折中的方案,而不是严肃意义上的那些破哪补哪直面问题解决问题的打法。 还比如:

1,为了促成能用好用的兼容多OS,从技术层面有二种流派和方案,一种是靠虚拟化,发明一套“OS的OS”,利用这样的元OS来管理guest os,一种是利用经典的再造OS的方法,像龙井,wsl,虽然它也是发展host os/guest os,guest os as subsystem,但与虚拟化流派的做法有着绝对的不同。前者依然是用传统的OS叠加OS,除了hypervisor,容器技术毫无创新,而后者,尝试从问题的源头重新去解决问题,从本生态内去解决问题而不是不断复合/融合(这里没有贬低该文OSXPE+PD方案的意思),如果问题出在最初考虑不周,抽象不够,那么就再抬高一个层次。结果是出来一个单一创新了的全新的OS ------ 这才是主体,其它子OS只是rootfs附属技术。

2,带着这些观点再谈分布式APP,我们发现这种历程正有点像业界对于分布式APP的挣扎和创新,在前面我们不断谈到分布式应用模型的讨论,其中最重要的地方《Plan9:一个从0开始考虑分布式,分布appmodel的os设计》中讨论得最为深刻,在那里,我们提到plan9正是这样的创新。它有别于用传统OS叠加的云化分布式 ——— 正如那些单调的兼容多OS技术一样,而是一种从协议级去创新,去重新发明不同理念OS的一种努力,plan9协议是一种从开发,从内核理念到语言,到APP的变革,去促成不同于现今可见的任一分布式APP的全新分布APP,而谈到协议,它必定是某种上种抽象。刚好在《用开发本地tcpip程序的思路开发webapp》,我们还讲到协议化。使用本地方式开发web程序。将web首先升阶抽象变为协议化的东西这样可以融进“静态web仅为资源”这样的webapp。那文中,我们还坚持一惯贬低了webapp vs 通用分布式app的那些优缺对比,因为它使用传统os,利用appstack层打洞,所以它是分布式OS中极为狭隘的一支,Web绝对是分布式appmodel中最浅层的一个典型。

无论如何,从这二大段说的正是:a,虽然能融合也很不错,不过话说回来。这并不表示能直接解决问题也并不是就不能实现效果最大化,b, ——— OS与APP,本来就是问题的一对最原始中心 ——— 只要先解决这类问题并创新,挖掘发现“真正的分布式APP”才能稍后解决开发,语言和工具。c,而抽象和协议升阶,是软工解决新问题出现的手段。

其中,b是中心的中心。

所以,我们为什么不能做一个真正的OS和分布式呢?

首先来看兼容OS解决多硬件,多主机软硬平台融合:一个多主机环境,跨本地远程,多os兼容的多主机方案设计

前文《兼容多OS or 融合多OS?打造基于osxpe的融合OS管理器》中,我们谈到的是单主机多OS的方案,稍微提到但没有深入多主机方案,我们提到,多OS的需求跟多显示器,多桌面机制一样可笑却实际存在。但其实细说起来一点也不奇怪,我可以在一台电脑上装三系统,一桌面系统用于生产,一类似dsm的系统用于同步文件,人手三件套手机电脑路由器,OS各各不一,未来公共使用的物联网(华为hm os?)。基于容器,OS也不会少。我经常看到和能想到的是,有些人还有二部手机,开发者有二个主机甚至多个电脑,

PS:多主机PC,这些主机可以要么是Computer as unit,便携显示器加nano itx小主机打造新式便携pc(用一个双系统机箱,或定制一个类双盘位的nas铝盒把这二个主板装上,nano itx 二个是24*12,下面刚好有空位上电池+整机箱上面覆盖键盘键盘就更好了,,打造多主机笔电式机箱)或者直接多nano itx PC集群,随身网吧(直接定制长vesa挂架挂墙),都可以带着出远门。,最现实的方案:要不就2台pc,一台带typec的笔记本,一台无屏带typec供电的便携显示器。也可以组成至少二主机环境。要么一台有双vesa的显示器,主机在显示器后,二个位。

无论是使用实体现,还是这些实体主机配合使用一台云主机,或全云主机,或云主机加一台实体主机,兼容多OS管理器都能使它们协同工作,我样可以将这些云主机中的一部分分出来一些,比如,负责某些任务较重的APP可以独占一个CPU较强大主机。负责存储的可以独占一台配有大容量存储的主机,因为我们要谈到的兼容多OS主要是在一台机器上装多个OS,负责路由的分在另外一个台机,etc… 如何将这些平台上的OS,以及平台本身用兼容平台/兼容os方案整合起来,使之协调一体,前提是:这一切受兼容OS管理器的管理,它本身是个融合OS。

前面我讲到使用macmini+oray控控的方案,wifi局域网纯软或借助硬件的投屏技术,内网穿透+VNC桌面,或ip kvm显示技术,都可以被舍弃了。因为这是个:远程OS也能被统一的虚拟机以桌面虚拟机同样的模式被分布式管理的架构,如下:

一种mirror to local的远程投屏操作系统,可放在pd

我们在前面《聪明的Mac osx本地云:同一生态的云硬件,云装机,云应用,云开发的完美集》谈到mac的云是一种很聪明的云,它主要将浏览器直接作为云存储的同步客户端,而且通过server app+描述文件管理器,利用caching as sync在苹果不同终端间建立私有线上线下打通的云,而且客户APP和服务性APP同宿一个osx,有别于群晖这种分二端APP的做法。而且它的IDE自带devops,也是一体化客户/服务性APP模式 —— 利用本地浏览器作同步客户端,利用sync+caching同时建立云content streaming,提倡使用客服一体化app ——— 正是Mac显得聪明的几个地方, 一言以概之,mac将云理解为传统桌面的附属,所以在实现上尽量向它靠近。

为什么就不能有一种OS:它将远程的一切无缝mirror到本地,如果远程OS可以被管理,可以像mac server一样,它作为分布式远端的OS,不只是一个远程桌面,而是一个实实在在的与其它OS等同的OS,只是被mirror到这里,所以在本地,有跟远程一模一样的运行状态和所有资源,如果放到PD下,就跟其它虚拟机一样,也即,我们本地会mirror远程机一模一样的状态,如果可以这样做到,为什么不呢?当然,mac也做得并不完善,反正,群晖这种webos,需要急待改进了。

缺少一个真正的分布式OS外观,正是分布式问题得不到真正解决,麻烦开始的地方,必须要在这里攻克它。

是不是还想到了plan9?它将API和运行状态都用本地/远程统一的协议来保存。它可以将nativeapp的四栈全部协议化,包括上面提到的投屏和界面。最主要还是其存储协议化,这种协议不光是面向本地的,也面向分布式。所以plan9是一种协议化升阶OS,它解决的是API,但是这种抽象和协议要向下兼容,即,把远程OS也弄为跟本地一样。

真正的分布式云程序,其行为要类似本地,不仅要从开发层透出API,api as services.而且要mirror出当时的host环境,才能透出整个对应native app的文件系统,等信息。这样才能以类似编程本地app的方式去编程dist app,比如,上传一个文件,你有界面,也有upload api,但是没有远程机器的磁盘信息。更具体点,远程桌面要有上传下载文件。所以,新的applvl runtime,要整合一个xaas环境,而不仅仅是api这些app本身的东西,要么在每个applvl像go塞进去一个vm一样,可以为每个app像plan9一样集成一套9p rootfs,也可以像plan9一样用相同协议的OS来保证这类远程APP有同样的本地/远程互操作性。

其中,第三种方法就可以将这种OS作为管理远程OS的实例,塞入PD,实现本地管理,而不必受到远程桌面之类的限制。有相同的外观。下面谈APPLVL的文件系统外观。

云APP/本地APP融合:一种uniform navtive/cloud appmodel抽象的appmodel设计

我们现在一些分布式文件系统,或oss,或文档数据库最大的毛病,是因为它们在操作系统的粒度上,没有给用户呈现一个类本地文件的打包视图。这些必须做在OS层面。才能给后来的APP提供统一的外观。应该上升到os层作为os的理念。和applvl虚拟化程度。

就如同plan9协议化了分布式OS交流用的存储协议一样,mac osx用finder作云同步客户端一样,统一的文件系统外观,使得可以结合plan9以操作本地文件和界面的方式来操作这些存储,形成真正的storage backend distapp。比如,用于web,可以有,基于化远程可观文件系统的网盘,可以有基于网盘同步的通用webapp设计。

基本,搞定了PD管理器,uniform navtimve/cloud 存储和界面协议。一个app的栈就被完全定义下来了,关键是,这些是按本地原来的用户开发和应用习惯设计的。而不是像web一样打洞,像虚拟化一样造更多雷同的东西(虚拟化只是解决了通往分布式APP问题的平台层及一些层面。更多其它的工作需要完成),而是重新从0开始,重发明,创新包容。也即,为了制造那种nativecloud体验合一的分布式,唯有像plan9一样。从经典的内核,API这些源头做起。

这样。从装机,OS到语言,开发,app,这些最终才能做到最好融合,对于促成一种真正的一种native/cloud融化方案平台和app这一最终目的,才能达成。

———————

Bcxszy用goblin这种被创造以整合plan9rootfs,工作在applvl虚拟级,可用于linux kernel based兼容多OS装机环境的分布式集群环境和类PD管理器,做到平台和OS级的融合。Bcxszy将最终打造一个网盘app用于说明云app/本地app融合的概念的实践。


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

展开阅读全文
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部