谈谈 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 的 问题