未来 需要的是 轻量 的 操作系统 而 不是 容器

时间:2022-09-03 14:03:39

未来 需要的是 轻量 的 操作系统 , 而 不是 容器 。                 

 

对于  客户端 、桌面 , 需要的是 满足用户需求的 ,生活化的  智能化的 操作系统 。

对于 服务器端 , 需要 的 是  轻量 的 操作系统 。

 

所谓 轻量,  就是  简单 直接 的 给出  服务器 需要 的 功能。  或者说, 服务器端程序 需要 的 功能 , 或者说, 开发者 需要 的 功能 。

 

设备驱动  进程调度  虚拟内存  网络通信 ,  这些 都已经 发展 到   成熟 和  饱和  了。 

并不难。 也并不大。 所谓 并不大 。 是指 , 这些 功能 的 代码量 并不需要 很大 。 在 不运转 时 占用 系统的 资源 很 小 。

这些 是 现在 可以做到 的 , 也是 现状 。

 

而  所谓 的  各种  对于  服务器 能力 的 扩展 ,  本质上 , 都是 围绕 网络通信 为 重点 来 发展 的 。

参考 下面 这 2  篇 文章:

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

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

 

一个 轻量 的 操作系统, 实现 了上述 的 功能 。 就 足够 了 。

简单明了 的 内核 , 清晰 的 意图 , 明确 的 要 解决 的 问题 。

如果 还不够 , 自己 改写 内核 。 简单明了  意图清晰  的  轻量 操作系统   鼓励  你 这么 做 。

 

如果 需要   “镜像” (用于 部署 程序), 那么  轻量 操作系统 可以 提供 镜像 。

 

未来 ,只需要一块 智能的 主板,可以灵活的配置硬件配伍就行。硬件是指 CPU 内存 外存 等 。

外存的存储空间分配是由外存的固件程序实现 。

 

对于  服务器 能力的扩展 , 还有 集群治理 和 突破一些传统架构上的瓶颈 。

未来 是 服务器 “团队作战” 的时代 , 所以需要 集群治理 。

传统架构上的瓶颈现在可以看到的主要是 同步/互斥(Lock) 可能对未来 并行计算 和 大幅利用多核资源 造成的瓶颈 。 这部分我在 《漫谈 C++ 内存堆 实现原理》    https://www.cnblogs.com/KSongKing/p/9527561.html      文中大概提到 , 主要提到了 堆分配 和 套接字(Socket) 受到 同步/互斥(Lock) 的限制 。

集群治理 并不难 , 可以偏重于硬件 , 通过一些 总线 之类 的方式 , 也可以是比较灵活的 ,偏重于软件的方式 。 软件的方式主要是 网络通信 , 通过 网络通信 来实现 服务器 之间的通信的协作 。

这并不难 , ……  比如 , 我举个例子, …… 

……

可以看看    《利用 MessageRPC 和 ShareMemory 来实现分布式并行计算》    https://www.cnblogs.com/KSongKing/p/9490915.html  ,  

说到这里 , 我又要笑了 ,  不是我又推销我的研究成果 , 而是这真的不难 , 就像上面 MessageRPC 和 ShareMemory 这样 , 再加些 协作算法就差不多了吧 ?

我想说的另一点是 , 这并不难 , 我们不需要一次又一次的 去 创造一些 “抽象层” , 没有必要 。

一次又一次的 创造 “抽象层” 会让事情复杂 。 实际上 , 这本来是 很简单的一个事情 。

 

堆 确实是比较重要的一个 基础模块 。 是 动态分配 内存 , 动态使用 内存 的 基础 。 算法也有那么一点啰嗦和小复杂 。 但 实现了 堆以后 , 就可以方便的 动态使用 内存了 。

操作系统 的 虚拟内存 可能比 堆 还简单一点 , 因为 虚拟内存 页 的 大小 是固定的 , 而 堆 里的 内存块 的 大小 数量 起始地址 可能是任意的 。

 

少搞一点 框架 , 大多数时候 , 库(Lib) 就足够了 , 库 是 最友好 的 。

 

还可以看看我写的另外一篇文章    《谈谈在 .Net 平台上的 软件生态 和 软件生产力》    https://www.cnblogs.com/KSongKing/p/9574379.html 

《程序员的职业归属》     https://www.cnblogs.com/KSongKing/p/9380112.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 架构》    https://www.cnblogs.com/KSongKing/p/9805610.html       中 谈到过 以 服务器(Server) 为 单元(基本计算单位) 的 架构, 

Server + 部署工具 = Server 集团作战

 

即,   “Server + 部署工具”    就可以实现   “Server 的 集团作战”    了 。

 

当然, 部署工具, 包含了一个 镜像 的 标准 和 实现,  我想 这并不难 。

核心算法  就是  复制文件  么 。:)   ^^ ^^ ^^

 

可参考另一篇文章  《我发起了一个 支持 ServerFul 架构 的 .Net 开源项目 ServerFulManager》   https://www.cnblogs.com/KSongKing/p/9899199.html

 

有网友说,  “这个所谓的轻量级操作系统,更像一个加强版容器,而不是操作系统” ,

是的, 也不是的, 

虚拟机 操作系统 容器, 本来 就是 同一种 性质的 技术, 可以说 都是 操作系统 技术,

就看 “壳” 在 外 ,还是 “壳” 在内  。

我之所以 倾向于 轻量操作系统 而不是 容器, 

是因为,

操作系统 是一个 广泛接受 的 入口(抽象层) ,

没有必要 再造一个 入口(抽象层),

再造一个 入口 导致的 结果 就是  复杂   。

实现新的 抽象层(容器) 的 技术 是 复杂的,

使用 容器 的 技术 也是 复杂的,

复杂 通常会 束缚   战斗力   爆发力    张力  。