这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战
听着贾大智的问题：
buildkit这个新工具的业务价值是什么？为什么要重新写一个呢？
袁小白的内心还是有一点拒绝的。 心想，啥也没干，整天就会提问题，还都是这些看起来和技术没啥关系的问题。 有本事上代码啊。 心里正嘀咕着。 耳朵里响起了贾大智的声音：我这一周也看了些资料，我从我的视角来说一下我对架构的理解。
我和龙飞一样，我也去看了下源码库，发现提交次数最多的是这位作者 - Tõnis Tiigi，名字不会念，就用谷歌翻译识别了下，原来是爱沙尼亚语，大致发间是"托尼斯 提gi"，为了方便，我们就叫他T神吧。
龙飞和袁小白都一齐点着脑袋，表示赞同。
贾大智接着说道。
然后我就去搜了下关键字Moby buildkit architecture design。
就发现了这篇文章，准确的说是这个issue - moby issue 32925。
原来这个就是最早提出问题和介绍架构理念的issue，与其说issue，我更愿意称之为架构提议草案。
细节大家可以会后去看，我先说一下我的理解。
解决的问题
下一代 docker build命令行工具。
因为现在的工具，只能一个文件一个文件的构件，还都是Dockerfile，很多项目不只一个构建文件，有的有多个构建文件，并且相互之间有依赖，这些需求，目前的工具都满足不了。
还有一点，就是慢，因为都是顺序执行，如果是大型项目，比如微服务，耗费的时间没法忍耐。
而新一代的工具，正是要解决这些问题。 用并行构建的方式，让用户可以自由定义前端描述语言，解析为统一标准操作集，来构建这些复杂需求的构建项目，并且可以满足多项目同时构建。
架构目标
其中一个主要的目标，就是将构建的前端和后端进行分离。 前端指的是，用户对于构建步骤的定义。 后端指的是，用最高效的方式，来构建通用操作集(low-level description of the build operations)。
不是一个随意的任务执行者。 而是一个长运行服务，用来解决将源码构建为人工制品的问题，并且以一种独立、便携、可重复和最高效的方式。
重要模块
总共有八个模块。
sources
资源模块，用来从远端获取数据。
如From ubuntu:14.04，获取基础镜像。
frontends
获取用用户定义好的构建信息，就像龙飞说的./example | buildctl build命令。
用于转换成统一的后端标准构建操作集。
这里要强调的是Dockerfile是所支持前端的一种形式，那就意味着，大家可以自定义自己的前端语言，自己的Container building DSL。
袁小白张大了嘴，想想还有点小激动呢。
solver
找到最高效的构建策略，构建构建图谱，这里说的正是龙飞前面指的DAG（有向无环图），通过图所承载的所有信息，包括Operation和各操作之前的依赖关系，这样就为后面找到高效的方法提供了数据支持。
最后还可以将所有的操作结果，进行缓存，为后续的构建任务提供缓存服务。
那这个就厉害了，想想看，以后全世界的人都不用再重复构建，浪费算力了，这真是绿色环保的壮举啊！
实现这个底层逻辑，我猜是cotent addressable，指的就是对一个文件进行HASH求值，生成唯一标识，如果由这份文件拷贝出来的新文件，用同样的HASH算法，就可以得到同样的KEY，就不用自己再构建一遍了，嗯，理论是可行的。
worker
运行容器的真正组件。
如用OCI runc运行容器。
exporter
将构建结果，根据导出配置，进行导出，如导出tar包，或者是zip包。
snapshots
为构建操作提供文件系统服务，如在根文件系统rootfs。
这个涉及到LXC(linux container)技术。
cache manager
将最近的构建产出，中间结果，都可以进行缓存，为再次构建，提供高效保障。 这里不仅仅缓存关系型数据，还可以缓存blob块数据。
controlAPI
用来将多个构建任务关联起来。 前面的多少还可以和龙飞说的对应上，这个好像没找到对应的流程，可能不在主时序图里吧。
这就是我对这个项目的起源，和需要解决的问题 - 为用户提供的价值，以及最早设计的思路的理解。
看了看时间，贾大智还没等大家提问。
说道：咱们接下来的方向就顺着主时序图和这些模块结合起来看吧，那下一次例会，咱们的主题就选frontends了。
时间过得真快，但今天对于袁小白来说，真的是思路大开，原来，学习源码这么有挑战，但同时，也还挺有意思的。 加上两位好队友，感觉这事好像能成。 已经开始期待下一次的例会了。
