基于云内核的未来云计算架构

早期单机操作系统也是分层架构，后面才演化成今天的如 linux windows 的宏内核微内核架构，云操作系统也会有类似发展趋势

以前都是单机应用，而现代应用几乎都是分布式应用，kubernetes 已经成为事实上的“云操作系统内核”，能让云内核普及的发型版呼之欲出

你会发现现在 IaaS PaaS SaaS 在云原生技术普及的浪潮中已经名存实亡，比如容器运行在裸机上就已经拥有非常好的性能了，是否还需要 IaaS 这一层，PaaS SaaS 本质都是容器是否还需要去可以区分，这三层架构已经被击穿！

程序员很认“鸭式辩型”，就是会游泳长了翅膀的就是鸭子，这种抽象思维是极重要的，这也就是为啥 linux 一切皆文件的设计哲学了。而一个运行的 mysql 集群与一个 crm 软件其实也没有本质区别，所以在云操作系统中，“内核之上皆为应用”。

云计算三次浪潮

基于云内核的云操作系统未来会引发云计算的巨大变革。

先来看看有意思的 web1 web2 web3, 再把互联网的变革套用到云计算中，你会发现，生产关系有非常类似的地方。

【1 对 n 关系】

• web1 : 门户网站生产内容，用户查看内容
• 云计算 1.0 : 公有云厂商开发服务，企业和开发者使用

这个阶段生产关系是 1 对多的，你会发现云厂商几十款云产品是无法满足市场上体量庞大偏好各异的需求的，就像 web1 用户只能看小编写的一些新闻一样。

---

【n 对 1 对 n 关系】

• web2 : UGC 用户生产内容，用户之间产生链接
• 云计算 2.0 : 开发者生产云计算应用，给用户使用

渐渐的云厂商开始弄 markting place, 一定程度想通过开放市场来连接云计算的生产者与消费者，这就是云计算朝着 2.0 过度的信号, 但是缺乏标准就意味着难以协作，这个阶段想要彻底爆发必须要有“实际上的标准”出现。

Docker 镜像算是非常好的标准，但是可惜难以覆盖分布式软件，但是大家通过 docker hub 协作就是一个非常好的协作模型了。

kubernetes 的 API 的标准是真正有潜力成为云计算 2.0 事实标准的。未来大家都通过这个系统来相互协作，就像安卓生态蓬勃的应用爆炸一样，这样才能诞生越来越多优质的云服务出来。

---

【n 对 n 关系】

• web 3 : 网络所有权属于网络的所有参与者，数据回归用户自己手中
• 云计算 3.0 : 算力属于所有计算的参与者，一台分布式超级计算机诞生

整个过程其实是让计算和服务更民主，任何组织个人都可以贡献自己的算力，发布和使用应用的人也不用关心应用到底运行在哪个地方，整个计算的使用像使用一台虚拟计算机一样。 和现在很多大的公链一样，不过目前的智能合约还是场景过于局限，计算成本过高，形式上很像超级计算机，效果上还是差了好几个鸿沟。

基于云内核设计的云计算会更便宜

当前公有云提供的云服务还是极其昂贵的, 在某云厂商官网查到的价格和 IDC 托管硬件相比，如果是存储类型的机器，价格相差十倍！（不过云厂商对大B都有非常大的折扣，小B没有这种福利）

很多公有云厂商妖魔化私有云，说私有云就不叫云，我想问私有云怎么就不叫云了，是因为私有云太便宜还是私有云动了谁的蛋糕？

这个价格对比小学生都能算的清楚。其实在云内核设计的云操作系统出现之前公有云确实会便宜，因为软件成本很高，企业想云在自己机房玩一套如 openstack 这样的 IaaS 几乎每年会花费上千万成本，而现在开源生态逐渐成熟让软件成本变得便宜和稳定，私有云的成本便宜逻辑又开始成立了。

那还有个问题就是“传统公有云为什么贵？”

• 第一，因为基于的还是 IaaS PaaS SaaS 的架构，每一层都意味着成本，软件的复杂度直接决定成本，所谓的一切自研的优势现在反而会变成成本劣势，这是最主要的原因。
• 第二，谈边际成本，这个不是按照公有云的用户体量去计算的，而是按照每个可用区的建设成本去计算的，如果软件体系复杂，每个机房需要大量管理节点，需要大量交付人员配合，那成本就无法降下来。但是基于内核设计的云操作系统管理节点只需三台，实习生都能在半个小时以内交付，就像装 centos 一样简单。
• 第三，次要原因是因为公有云的弹性都是要预留资源的，这部分成本都会摊到消费者头上。

很多企业的业务资源使用都是相对固定，半年一年作一次扩容等，托管或者自建肯定会更便宜，促销活动什么的一年也就几次，在促销时使用公有云即可，这样成本可以大幅度降低。

云计算会走向开源开放

封闭的云服务对于企业来说是灾难，最简单的一个场景是应对云厂商的涨价行为，如果强绑定就意味着失去了议价权，近期某云厂商云开发就提价十倍，有些小企业的利润直接就被云服务吃光了。

第二个原因是云厂商的云产品如果发展的不好是有可能被下架的，如果企业不幸使用了这类产品，下架时又需要付出巨大迁移成本，有些与代码耦合的甚至需要重写代码。

开源自然是开放的最好实现方式，不仅对上面几种场景有比较好的应对措施，关键还可以自由按照自己的需求进行定制。

所以未来开源与云是左右腿，像 vercel supabase sealos 这样的产品是云计算的大势所趋。

基于内核架构的云计算会变得更简单

复杂的东西无法普及，复杂的软件要么走向腐烂和消亡，要么重构变得简单，云计算也是如此，你会发现 centos ubuntu 这样的 linux 发行版普及了，但是现在的一些公有云能力很难到处运行和做到普及，即便是开源了，像 openstack 一直未能普及，原因很简单，需要几十个人的团队才能在生产环境玩起来的话绝大多数企业都会放弃。

什么叫“内聚”，就是功能不是以牺牲复杂度来换取的，像 linux 的 core 很内聚，驱动即使扩展了一万个系统复杂度也没增加，虽然代码在一直增加。所以软件设计时的抽象能力就变得极重要，基于云内核架构设计的云操作系统也是高“内聚”的，通过扩展应用来扩展能力，而各应用之间是低耦合的。

内核架构云操作系统爆发时机

基于开源技术的云服务在侵蚀昂贵且强绑定的公有云的服务

现在可以发现公有云云原生领域提供的服务商业化做的好的几乎都是开源强相关的， 如基于 kubernetes 的云服务，基于 prometheus grafana 的可观测服务等。

用户越来越聪明了，便宜还是贵按按计算器就能算出来，而且绑定意味着认人鱼肉，技术选型明显往开源技术倾斜。

云原生侵蚀传统 IaaS 服务

基于虚拟机的业务增长速度已经远远赶不上云原生生态的发展速度了，基于 kubernetes 的云原生生态每年几倍甚至有些产品每年几十倍的增长，大量企业在从虚拟机架构往云原生架构迁移。

前几年市场被教育的很好，越来越多企业知道云原生降本增效不是一点点，该填的坑也被填的差不多了，开始考虑从观望状态变成实践了。

市场需要一款云操作系统进一步降低云原生门槛与成本

现状是企业在实践云原生的时候还是容易迷失，生态过于庞大复杂，上千款生态软件让很多企业无从下手，而且真要落地至少得有个专家能把云原生计算存储网络都玩的明白，所以这个生态依然还是缺乏好用的开箱即用的发行版。

其实这个发行版的要求还是很高的，要非常简单不多不少的去满足客户的需求，还不能给用户带来负担，这就必须得非常好的设计理念和实现机制。

如何实现这样一个云操作系统

如何去设计这样一个操作系统，首先一定需要有非常好的设计理念

1. 化整为零，这意味着如果你不装应用，这个系统就是空的，就是 nothing,就是 void*,就和你买了一台新电脑里面除了操作系统什么也没装一样。
2. 自由组装，所有用户的需求都是通过具体应用实现的而这些应用都是按需求从应用市场中下载，不会硬塞给用户不需要的东西，未能得到满足的需求也是通过应用去扩展。云操作系统不会去追求各种应用风格的统一，就像 macOS 上的微信和飞书不会有统一的风格和账户系统一样，只有这样各应用才能在自己的场景尽情发挥出最大优势。

实现层面，core 是非常内聚的意味它向下仅提供云内核生命周期管理，如安装/伸缩/升级/清理，向上做好应用的打包与管理即可。

应用市场方面很重要，一定要有好的标准，这涉及到应用的提供者与消费者之间的协作，OCI registry 仓库就是个非常好的已有事实标准，兼容它是最好的选择。

User interface 一定要简单极致，这是用户直接使用你东西的地方，API > CLI > GUI, Desktop 是产品化的终极形态，真的做到用云像用 PC 操作系统一样简单。

剩下一切都在于扩展应用的宽度和深度：

1. 广度，常用分布式软件如 mysql 集群，redis 集群，消息队列等逐步覆盖，不断扩展常用分布式应用数量
2. 深度，基本安装->高可用->可监控->自运维->高性能/安全性->产品化，几个阶段衡量一个分布式应用成熟度

那 sealos 就是使用这样的思维去设计的，laf 就是 sealos 上的第一款杀手级应用。

总结

未来的云会更便宜 更开放 更简单，最终会有一款优秀的发行版本实现云原生的普及，而 sealos 诞生之日起就朝着这个目标不断进步~

相信未来云计算属于所有算力的提供者，云的价值也会属于所有云计算的参与者，不再受任何厂商绑定之苦，更便宜的享受云计算带来的便利。开源开放带给大家简单/便宜的云计算！

作者：fanux.方海涛.中弈 sealos 作者, CNCF sealer 项目发起人。曾就职阿里云，现任环界云计算 CEO, 环界获得陆奇博士奇绩创坛种子轮投资

sealos 以kubernetes为内核的云操作系统发行版，让云原生简单普及

laf 写代码像写博客一样简单，什么docker kubernetes统统不关心，我只关心写业务！