这是我参加11月更文应战的第12天，活动概况查看：2021最后一次更文应战
龙飞如同预见到了袁小白会再次发现新的疑惑点，由于龙飞自己通过上一次和袁小白一同整理后，也感觉到有一些细节在第一次的整理时，是有漏掉的，带着这些新的线节，龙飞将Frontends flow又重新整理了一遍：
看到袁小白的目光被Frontend flow给吸引住，龙飞开端说道。
这个解析流程的确有点绕，单单一个solve，就出现了8次，这就会让我们产生一些疑问：这些solve都是一个意思吗，在不同的目标里，如buildctl, client, control, solver等等，这些solve在这些目标里难道都是拥有同样的意义？ 不过不要急，让我们按这个流程再走一遍，看看作者到底想表达什么？
- 用户调用命令行
buildctl build --frontend dockerfile.v0 --local dockerfile ...，这儿是整个流程的触发点，这儿我们要开端解析用户的构建需求，而这些需求都按dockerfile的格式表达了出来 - 由于是C/S(client/server)结构，所以在客户端，我们需求有一个
client，用来处理网络恳求 - 可能还需求更切当的客户端，所以这儿需求的一个controlClient，用来发送解析恳求
- 终于，能够宣布解析恳求了，这儿需求发送的是grpc恳求 – moby.buildkit.v1.Control/Solve
- 前端宣布恳求后，剩下的也就要交给后端了，这儿后端为了处理好解析恳求，需求做好足够的准备。比如需求准备好frontends实例，由于需求上需求支撑多种不同的frontend，而dockerfile仅仅前端的一种，何况这仍是亲儿子，必需得支撑好。其次为了GRPC的注册和管理能统一管理，这儿control需求关心的便是供给对应的办法函数。而GRPC服务相关的就交给controller.Register了，像URL匹配，及GRPC服务相关的设置项都统一提前准备好。由于有了这些准备，control成功接收了前端发来的解析恳求。
- 为了正确解析，solver需求将真实供给解析服务的frontend相关起来，所以需求一个bridge
- bridge并不能自己解析，需求找到真实的frontend实例，如这儿的frontends[“dockerfile.v0”]，也便是frontend中dockerfile供给的build办法，由于需求解析中间状态，所以有一个回调，这儿要注意，虽然都是调用的llbbridge.solve，但两次所走的代码分支是不一样的：
这儿也正是袁小白不明白的当地，为什么在dockerfile.build里，又会出现c.solve，终于在这儿找到了答案。
可是，如果想要更清楚的理解这儿面的逻辑关系，我们需求整理出数据的形式转化进程：
dockerfile -> Definition -> Edge
那么接下来，我们能够去了解一下dockerfile的解析，及LLB中的数据格式转化。
看来，我们仅仅刚刚开端，路还很漫长，袁小白深深的吸了口气。
