谈谈 ServerFul 架构

我写了一篇文章 《自己实现一个线程池》  https://www.cnblogs.com/KSongKing/p/9803935.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 和 网格计算》      https://www.cnblogs.com/KSongKing/p/9486434.html

伸缩性   （弹性）

我发表过 一篇 博客 《未来需要的是 轻量操作系统 而不是 容器》      https://www.cnblogs.com/KSongKing/p/9259628.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 的 问题