一種追求高度融合，包容軟硬方案的雲主機叢集，雲OS和雲APP的架構全設計

本文關鍵字：相容多主機硬體設計，相容多os，相容native/cloud程式模型,相容本地程式/分布式程式。網絡作業系統，不是x11,不是遠端桌面，不是web nas,不是pouch存儲同步。不是遠端投屏。

雲在人們的觀念中就是遠端，它承諾将計算發展成水電煤一樣的可被直接利用的資源，與内容和我們本地的用戶端或終端接入（是以有了雲存儲，雲GPU等各種傳統資源的雲化，以及一些或細分或複用的雲資源，如雲驗證，雲遊戲,etc..），雖然雲技術的背後是一層一層的虛拟化，可是它并沒有将這種工作進行到我們日常使用APP方面，作為使用者，我們還是停在手機上裝APP使用雲資源的曆史情景下 —— 試想一下，我們老早以前就有網絡作業系統，TCP/IP這樣的C/S程式。可是一直到現在，我們依然這樣子使用雲。——— 雲程式沒有過任何改變。它隻是将服務端越做越肥兼帶更強大的content streaming的改變(比如即将到來的5G)。

稍微涉及到複雜一點的自建雲/雲系統管理情形下，比如群晖，ECS，裸金屬虛拟化，雖然雲裝機的方式更靈活多樣，但我們發現我們最終還是在使用傳統的OS來建立和使用雲。還有遠端桌面，vnc，遠端桌面，區域網路投屏,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融合的概念的實踐。

(此處不設回複，掃碼到微信參與留言，或直接點選到原文)