談談 ServerFul 架構

我寫了一篇文章 《本身實現一個線程池》  http://www.javashuo.com/article/p-bdymuidk-ds.html ，

 

其實 不只僅 是 線程池， 中間件 層 的 服務 咱們 均可以 從新 寫一遍， 好比 Hadoop, HBase, MapReduce， 又或者 Dubbo ， ZooKeeper 之類的 「分佈式服務計算框架」 ， 均可以 從新 寫 一遍 。 這些 並不稀奇 。

 

基於 虛擬機（Java JVM 或者 .Net CLR） 的 技術 自己 並不複雜， 或者說， 虛擬機（Java JVM 或者 .Net CLR） 層 以上 的 技術自己 並不複雜 。

實現 虛擬機（Java JVM 或者 .Net CLR） 的 技術 是 複雜 的 ， 可是 虛擬機（Java JVM 或者 .Net CLR） 層 以上 的 技術 並不複雜 。

虛擬機（Java JVM 或者 .Net CLR） 層 以上 的 技術 就是 中間件 和 業務系統 。

事實上 虛擬機（Java JVM 或者 .Net CLR） 自己就是爲了 簡化開發 因此纔出現的 。
虛擬機（Java JVM 或者 .Net CLR） 中間件 層 最複雜 的 技術 大概就是 多線程 ， 最多就是 字節碼 （IL OpCode） 。
沒了 。

可是 虛擬機（Java JVM 或者 .Net CLR） 自己的 實現 是 複雜的， 是 核心技術 。
這部分 技術 集 計算機 軟件 技術 之 大成， 
首先， 緊密貼近 操做系統，
其次， 編譯器 愈來愈複雜， 由於 語言特性 愈來愈 複雜， 語言愈來愈多，
對 效率 的 優化 也 愈來愈多，
可是 咱們 仍然 要 支持 開源
在 中間件 層 的 開源 也是 頗有意義 的

中間件層 以上的 軟件技術， 
主要 Focus 在
分佈式通訊
快速開發
快速 生產 安全穩定 的 業務系統
快速應對 需求變化
維持 業務系統 的 穩定
運維

應對  大規模 訪問  （使用    計算）       要 突破 現有的 集中式 架構 對於 大規模訪問 的 瓶頸， 須要 客戶端 智能化 和 服務器 多中心化， 參考我以前寫的一篇文章     《Grid Virtual Server 和 網格計算》      http://www.javashuo.com/article/p-hctfhgzx-dg.html

伸縮性   （彈性）

我發表過 一篇 博客 《將來須要的是 輕量操做系統 而不是 容器》      http://www.javashuo.com/article/p-oeegsskj-gp.html

事實上
要實現 上述目標
虛擬機 + 中間件服務 + 產生式編程 + DevOps         （這裏的 虛擬機 是 硬件虛擬化 的 虛擬機， 不是 JVM 和 .Net CLR 的 那個 虛擬機）
就能夠
沒有必要用 容器
也沒有必要 「無服務器」 （ServerLess）

因此， 我提出一個 「ServerFul」 架構， ServerFul 架構就是 n 臺 Server 經過 網絡通訊 的 方式 協做在一塊兒 。

也能夠說 ServerFul 架構是 虛擬機 + 中間件服務 + 產生式編程 + DevOps ，

也能夠說 ServerFul 架構是 基於 Server 和 網絡通訊（分佈式計算） 的 軟件實現架構 ， Server 能夠是 虛擬機 物理機 ， 以及 基於硬件實現的 雲 的 雲服務器 。

有網友問， 「假如你100個虛擬機 + 100箇中間件，你怎麼管理？ 不仍是用相似於容器的來操做。」

個人想法是， 用 網絡通訊 的 方式 管理 。 即用 網絡通訊 的方式 管理 服務器 羣 。

容器 我想 它 的 管理方式 有 2 種， 
1 對於 同一個 物理主機 內 多核 的 管理
2 對於 多個 物理主機 的 管理

對於 1 ， 應該是 用 操做系統 層面 的 技術

對於 2 ， 應該還是用 網絡通訊 的技術

只是，

本來 基於 網絡通訊 的 技術， 透明直觀， 如今 被 容器 包含進去了 吧 ！ ^^

包括像 Service Mesh 這樣的技術， 也是 基於 容器 的

容器是一個 操做系統 層面的 技術

個人想法是，

用 中間件 的 技術 來 管理 服務器 集羣

而不是 用 操做系統 的 技術

我知道的很少， 不過 對於 CPU 資源 的 管理分配 ， 這應該是 操做系統 層面的技術

不過 如今 容器 彷佛把 更大範圍 的 服務器集羣 管理 之類 的 也 包含到 自身裏了

容器 的核心代碼 應該是 操做系統 內核代碼 的 一部分


容器 客戶端 應該是跟 核心代碼 通訊

容器 實際上 應該是 修改了 操做系統 進程管理 的 代碼

來實現 CPU 資源分配

或者說，

容器 實現了一個 「進程組」（進程 Group）


一組進程 就是一個 容器，也至關因而一個 小虛擬機

這部分是 修改了 操做系統 內核代碼 中的 進程管理 部分

這應該是 容器 的 核心

此外的話，就是 對於 存儲資源 的 管理

內存 到 磁盤

我猜的 ~

再次就是 網絡通訊

大概 能夠 虛擬 網卡

一個 網卡 虛擬成 多個 虛擬網卡 來提供給 多個 容器 和 外界通訊

這也是 操做系統 內核 ， 屬於 內核中 網絡通訊 的 部分， 網卡驅動

同時

像 Service Mesh 這樣負責根據 業務 提供一個 虛擬網絡 通路 的 技術

也 是 基於 容器 的

事實上 不基於 容器 也能夠實現 這種 虛擬網絡通路

只是 如今 流行 使用 容器 吧 ~ ！

還有

Kubernates 還包含了 管理 服務器 集羣 的 能力

前段 時間 看到 文章說，

Kubernates 在 國外 某個 大學 （好像是， 反正大概是 科研單位 之類的）
爲一個 項目 管理 了 上千臺 服務器
用於 科學計算 之類的 吧 ？
虛擬網路通路 最核心基本 的 技術應該是 虛擬網卡

Service Mesh 基於 容器 ， 虛擬網卡 多是 最主要的緣由
這個 不須要 容器 也能夠實現

虛擬機 （VMWare 之類的） 應該已經實現

還有另一個緣由

就是 如今流行用 容器

因此， Service Mesh 直接選擇了 容器 做爲 基礎架構

虛擬網卡 實際上 就是 一個 網卡驅動程序

在 網卡驅動程序 裏 對 包 做一些 Wrap 和 UnWrap

邏輯 上 跟咱們 中間件層 寫 AOP 之類的 差很少

或者 Http 代理 ， Http 攔截器（Interceptor） 之類的 差很少

跟 Asp.net 裏的 HttpModule

Asp.net Core 裏的 MiddleWare 差很少

固然 這樣 虛擬來 虛擬去

效率 確定 打折扣

服務器 集羣 管理， 其中一個工做就是 批量部署， 或者說 鏡像部署， 或者說 克隆部署

這也能夠用 中間件 技術 實現

本質上就是 拷貝文件 嘛 ！

虛擬網卡 的 實現， 至關於 在 驅動程序 裏 要加入一份 IP 協議 的 邏輯， 把 數據 按 虛擬網卡（IP） 處理後， 再傳給 操做系統 的 IP 協議

這樣就至關於 經歷了 2 次 IP 協議 的 處理

效率天然會受影響

固然， VMWare 也能夠 修改 操做系統 內核

即 直接 修改 操做系統 的 IP 協議， 在 操做系統 的 IP 協議 中 加入 虛擬網卡（IP） 的 邏輯

這樣將 虛擬網卡（IP） 的 工做 合併 到了 操做系統 的 IP 協議 裏

能夠 減小一些 重複的 工做量

但 對於 效率 仍然有 影響

同時， 這種 作法，

修改了 操做系統 內核，

會 形成 代碼版本 很差 管控

操做系統 代碼 變得 複雜，

且 難於 管控

好比， 這個 操做系統 修改了 內核代碼

就須要 考慮 Merge 的問題

或者 操做系統 修補了 某個 漏洞

也一樣 須要 考慮 Merge 的 問題