真正写代码的人才能看懂 CNB 的底层逻辑

admin管理员组

文章数量:1028916

真正写代码的人才能看懂 CNB 的底层逻辑

了解更多，可以点击我们的官网：

“百G秒克、缓存并发、分支即环境，像开了挂一样快。”

这些违反常识的离谱操作，都壹一照进了现实。

这，还是一个普通的代码托管平台该拥有的么？

CNB 的声明式语法，Docker 生态都好理解，

但他的 高并发弹性 是如何实现的呢？

目前认知里能实现弹性的技术

1. 借助云平台动态创建 cvm，比如 github-action
2. 借助 kvm 快速创建轻量虚拟机，比如 云函数
3. 借助 k8s 动态创建 pod，比如 k8s job

以上方案确实能实现计算资源和存储资源的弹性，

但是无法进一步实现缓存弹性！

因为存储资源创建出来都是干净的空盘，

就算对空盘进行缓存填充，硬盘干冒烟，

都不可能快速复制 100 G 的代码文件，

更别谈高并发了。

根据 git-clone-yyds 开源的代码来看，

底层用了 OverlayFS 来实现缓存的快速复制。

OverlayFS 只能工作在同个主机上，

以上的方案都存在跨主机，首先排除。

CNB 的弹性，绝非简单的动态创建，

而是伴随着存储的复制。有没有一种可能？

CNB 仅有一块硬盘，缓存被同盘复制？

当排除所有其他的可能性，最后剩下来的，

不管多么不可思议，那也一定是真相。

CNB 运行在一个超大核的主机上！！！

缓存先复制，然后供容器挂载使用，很合理吧？

容器的本质是进程，所以 CNB 的高并发，

就是平平无奇的多进程并发。

计算资源不是创建，只是限制，越来越合理了~

基于云的弹性我们乐意称为云原生，

那 CNB 这种基于复制的弹性又如何称呼？

秒级克隆：代码是复制出来的

缓存并发：缓存是复制出来的

云原生构建：构建环境是复制出来的

云原生开发：开发环境是复制出来的

复制式弹性，云原生复制，多重影分身？

一切皆可复制，只靠产品本身就能做到了，

由此可见，CNB 背后的研发团队绝非普通玩家！

github 固然强大，只有祛魅 ，回归技术本身，

才能做出真正好用的开发者工具

海外的 GIT 比国内的 GIT 更圆？

减少崇洋媚外，从你做起，从我做起~

真正写代码的人才能看懂 CNB 的底层逻辑...

叁二1，上图

至此，艺术已成～

点击链接访问我们的官网了解更多

真正写代码的人才能看懂 CNB 的底层逻辑