我写了一篇文章 《自己实现一个线程池》 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 的 问题