將來 須要的是 輕量 的 操做系統 而 不是 容器

將來 須要的是 輕量 的 操做系統 ， 而 不是 容器 。                 

 

對於  客戶端 、桌面 ， 須要的是 知足用戶需求的 ，生活化的  智能化的 操做系統 。

對於 服務器端 ， 須要 的 是  輕量 的 操做系統 。

 

所謂 輕量，  就是  簡單 直接 的 給出  服務器 須要 的 功能。  或者說， 服務器端程序 須要 的 功能 ， 或者說， 開發者 須要 的 功能 。

 

設備驅動  進程調度  虛擬內存  網絡通訊 ，  這些 都已經 發展 到   成熟 和  飽和  了。 

並不難。 也並不大。 所謂 並不大 。 是指 ， 這些 功能 的 代碼量 並不須要 很大 。 在 不運轉 時 佔用 系統的 資源 很 小 。

這些 是 如今 能夠作到 的 ， 也是 現狀 。

我在另外一篇文章 《淺談 操做系統原理》 http://www.javashuo.com/article/p-kfizjtdl-u.html    中 對 操做系統 的 基本 組成 和 原理 做過度析 。

 

而  所謂 的  各類  對於  服務器 能力 的 擴展 ，  本質上 ， 都是 圍繞 網絡通訊 爲 重點 來 發展 的 。

參考 下面 這 2  篇 文章：

https://blog.csdn.net/mawming/article/details/51941771                                                                

https://blog.csdn.net/wodeyuer125/article/details/43274527               

 

將來的 服務器操做系統 ， 要實現的， 是 把  網絡通訊（Socket） 的 能力 發揮 到  CPU 內存 網卡 的 極限， 就這件事 。

 

還有 另一件事， 就是 線程 的 輕量化 ：

減少 線程上下文，減小 線程切換的工做量，線程切換 輕量化，線程 輕量化， 是 操做系統 輕量化 的 一個 方向 。

關於 線程 的 輕量化， 可參考 《後線程時代 的 應用程序 架構》  http://www.javashuo.com/article/p-blioukym-ga.html

 

一個 輕量 的 操做系統， 實現 了上述 的 功能 。 就 足夠 了 。

簡單明瞭 的 內核 ， 清晰 的 意圖 ， 明確 的 要 解決 的 問題 。

若是 還不夠 ， 本身 改寫 內核 。 簡單明瞭  意圖清晰  的  輕量 操做系統   鼓勵  你 這麼 作 。

 

若是 須要   「鏡像」 （用於 部署 程序）， 那麼  輕量 操做系統 能夠 提供 鏡像 。

 

將來 ，只須要一塊 智能的 主板，能夠靈活的配置硬件配伍就行。硬件是指 CPU 內存 外存 等 。

外存的存儲空間分配是由外存的固件程序實現 。

 

對於  服務器 能力的擴展 ， 還有 集羣治理 和 突破一些傳統架構上的瓶頸 。

將來 是 服務器 「團隊做戰」 的時代 ， 因此須要 集羣治理 。

傳統架構上的瓶頸如今能夠看到的主要是 同步/互斥（Lock） 可能對將來 並行計算 和 大幅利用多核資源 形成的瓶頸 。 這部分我在 《漫談 C++ 內存堆 實現原理》    http://www.javashuo.com/article/p-huenfaog-bk.html      文中大概提到 ， 主要提到了 堆分配 和 套接字（Socket） 受到 同步/互斥（Lock） 的限制 。

集羣治理 並不難 ， 能夠偏重於硬件 ， 經過一些 總線 之類 的方式 ， 也能夠是比較靈活的 ，偏重於軟件的方式 。 軟件的方式主要是 網絡通訊 ， 經過 網絡通訊 來實現 服務器 之間的通訊的協做 。

這並不難 ， ……  好比 ， 我舉個例子， …… 

……

能夠看看    《利用 MessageRPC 和 ShareMemory 來實現分佈式並行計算》    http://www.javashuo.com/article/p-glolrmri-et.html  ，  

說到這裏 ， 我又要笑了 ，  不是我又推銷個人研究成果 ， 而是這真的不難 ， 就像上面 MessageRPC 和 ShareMemory 這樣 ， 再加些 協做算法就差很少了吧 ？

我想說的另外一點是 ， 這並不難 ， 咱們不須要一次又一次的 去 創造一些 「抽象層」 ， 沒有必要 。

一次又一次的 創造 「抽象層」 會讓事情複雜 。 實際上 ， 這原本是 很簡單的一個事情 。

 

堆 確實是比較重要的一個 基礎模塊 。 是 動態分配 內存 ， 動態使用 內存 的 基礎 。 算法也有那麼一點囉嗦和小複雜 。 但 實現了 堆之後 ， 就能夠方便的 動態使用 內存了 。

操做系統 的 虛擬內存 可能比 堆 還簡單一點 ， 由於 虛擬內存 頁 的 大小 是固定的 ， 而 堆 裏的 內存塊 的 大小 數量 起始地址 多是任意的 。

 

少搞一點 框架 ， 大多數時候 ， 庫（Lib） 就足夠了 ， 庫 是 最友好 的 。

 

還能夠看看我寫的另一篇文章    《談談在 .Net 平臺上的 軟件生態 和 軟件生產力》    http://www.javashuo.com/article/p-htejkczu-em.html 

《程序員的職業歸屬》     http://www.javashuo.com/article/p-wbqmkext-ea.html

 

咱們來看看一篇文章    《雲架構師進階攻略（2）》     https://sq.163yun.com/blog/article/215552048311889920?tag=M_tg_546_65

這是一個系列的文章， 這是 第 2 篇， 

文章的內容 不少， 很詳實 。

 

咱們再看看文中的一篇 連接 的文章   《容器平臺選型的十大模式：Docker、DC/OS、K8S誰與當先？》

https://mp.weixin.qq.com/s?__biz=MzI1NzYzODk4OQ==&mid=2247484679&idx=1&sn=60344c7d43fd8a90324f4f90b9f83aad&chksm=ea151225dd629b33ad01036012457b0afcd43781c694c6e50c720e8156cba6bc4fb1a524c7ab&scene=21#wechat_redirect

 

 

若是 僅僅 是 爲了 鏡像（部署），

那麼 ， 操做系統   也能夠， 只須要 在 操做系統 裏 增長一個 部署工具 就能夠了  。

這樣 就 不須要 資源分配 容器隔離（安全） 等  複雜技術 ，

固然 也就 無所謂 容器 一說了 ，

只須要 操做系統 集成 一個 部署工具 就能夠 。

這樣的話， 操做系統（虛擬機）   也能夠作到   鏡像很小（只包括 應用），  秒級啓動，  快速複製  。

 

這裏的 鏡像 固然不是 虛擬機鏡像，  而是 應用 的 鏡像 ，

咱們這裏所說的是 不須要 頻繁 的 建立銷燬 虛擬機， 可是能夠 快速的 複製和部署 應用鏡像 到 虛擬機 上 。

或者說， 建立銷燬 虛擬機 的 速度 能夠和 複製部署 應用鏡像 的 速度 處於 2 個 數量級 上  。

也能夠說， 這種方式也使得 遷移 的 速度 不受 虛擬機鏡像 大小 的 限制 了 。 

或者說， 遷移 速度 和 虛擬機鏡像 大小 無關 了 。

遷移 速度 只和 應用鏡像 大小 有關 。

由於在這種架構下， 虛擬機鏡像 不包含 應用， 只是標準的 操做系統 。

因此， 

即便是 異地遷移， 異地環境 也應該會提早準備好 須要的 虛擬機鏡像（操做系統）， 因此 遷移 速度 和 虛擬機鏡像 無關，

只和 應用鏡像 有關 。

 

事實上， 我在另一篇文章《談談 ServerFul 架構》    http://www.javashuo.com/article/p-yzetvfzb-gh.html       中 談到過 以 服務器（Server） 爲 單元（基本計算單位） 的 架構， 

Server + 部署工具 = Server 集團做戰

 

即，   「Server + 部署工具」    就能夠實現   「Server 的 集團做戰」    了 。

 

固然， 部署工具， 包含了一個 鏡像 的 標準 和 實現，  我想 這並不難 。

核心算法  就是  複製文件  麼 。：）   ^^ ^^ ^^

 

可參考另外一篇文章  《我發起了一個 支持 ServerFul 架構 的 .Net 開源項目 ServerFulManager》   http://www.javashuo.com/article/p-ufbwsosk-gv.html

 

有網友說，  「這個所謂的輕量級操做系統，更像一個增強版容器，而不是操做系統」 ，

是的， 也不是的， 

虛擬機 操做系統 容器， 原本 就是 同一種 性質的 技術， 能夠說 都是 操做系統 技術，

就看 「殼」 在 外 ，仍是 「殼」 在內  。

我之因此 傾向於 輕量操做系統 而不是 容器， 

是由於，

操做系統 是一個 普遍接受 的 入口（抽象層） ，

沒有必要 再造一個 入口（抽象層），

再造一個 入口 致使的 結果 就是  複雜   。

實現新的 抽象層（容器） 的 技術 是 複雜的，

使用 容器 的 技術 也是 複雜的，

複雜 一般會 束縛   戰鬥力   爆發力    張力  。