开放源代码平台 Flynn 的架构与实现原理

现在的应用程序从源代码到运行阶段太复杂，没有标准的、通用的方式。整个过程及产出分为以下几个阶段。

• 开发阶段：源代码。

• 构建阶段：发布包/可执行程序。

• 部署阶段：可运行的镜像（发布包+配置）。

• 运行阶段：进程、集群、日志、监控信息、网络。

如果需要管理或者构建一个完整的服务栈，容器扮演的仅仅是一个基本工作单元的角色。在服务栈的最下层，需要有一种资源抽象来为工作单元展示一个统一的资源视图。这样容器就不必关心服务器集群资源情况和网络拓扑，即从容器视角看到的仅仅是“一台”服务器而已。还应该能够根据用户提交的容器描述文件来进行应用容器的编排和调度，为用户创建出符合预期描述的一个或多个容器，交给调度引擎放置到一台或多台物理服务器上运行。

如何为容器中正在运行的服务提供负载均衡和反向代理，如何填补从用户代码制品到容器这一“鸿沟”，如何将底层的编排和调度功能 API 化等，这些功能看似并不“核心”，却是实现“面向应用”云平台的必经之路。

Flynn，一个具有 Layer 0 和 Layer 1 两层架构的类 PaaS 项目，对宿主机集群实现一个统一的抽象，将容器化的任务进程合理调度并运行在集群上，然后对这些任务进行容器层面的生命周期管理。

1、Flynn 的主要功能

• 分布式配置和协调

Flynn 选择了 etcd，但并没有直接依赖它，可以方便地通过实现 Flynn 定义的抽象接口将分布式协同组件更换成其他的方案。

• 任务调度

Flynn 原生提供了两种调度器，一种负责调度长运行任务(Service Scheduler)，另一种负责调度一次性任务(Ephemeral Scheduler)。

• 服务发现

在 Flynn 中，服务发现的主要任务是观察被监控节点（包括服务实例和宿主机节点）的上线和下线事件，从而在 callback 回调中完成每个事件对应的处理逻辑（如更新负载均衡的 serve 列表）。

• 宿主机抽象

所谓宿主机抽象，是指上层系统(Layer 1)以何种方式与宿主机交互。宿主机抽象可以屏蔽不同宿主机系统和硬件带来的不一致。一般来讲，抽象实现的方式是在宿主机上运行一个 Agent 进程来响应上层的 RPC 请求，向上层的调度组件报告这台宿主机的资源情况，以及向服务发现组件注册宿主机的存活状态等。

2、Flynn 的上层功能

Flynn 构建在 Layer 0 之上的一套组件统称为 Layer 1，它能够基于 Layer 0 提供的资源，抽象实现容器云所需的上层功能。

• API 控制器

Flynn 也运行着一个 API 后端，以响应用户的 HTTP 管理请求。

• Git 接收器

Flynn 使用 Git 来发布用户代码，Git 接收器作为一个获取远程配置在用户方，所以用户推进的代码会直接交给这个接收器来制作代码制品和发布包。

• Buildpacks

用户只需要上传可执行文件包（如 WAR 包），Buildpack 就能够将这些文件按照一定的格式组织成可以运行的实体（如 Tomcat+WAR 组成的压缩包）。通过定义不同的 Buildpack，PaaS 就能实现支持不同的编程语言、运行环境、Web 容器的组合。

• 路由组件

容器服务栈要想正常工作，一个为集群服务的负载均衡路由组件是必不可少的。Flynn 的路由组件支持 HTTP 协议和 TCP 协议，它能够支持大部分用户服务的访问需求。Flynn 的管理类请求也是由路由组件来转交给 API 控制器的。通过与服务发现组件 etcd 协作，路由组件可以及时地更新被代理服务的 IP 和端口。

3、Flynn 体系架构与实现原理

用户代码是如何上传到 Flynn 并执行运作的呢？主要有以下两种方式。

1）用户通过 Git 指令直接提交代码，这时 Flynn 需要做的工作至少包括以下几项。

• 接收用户上传的代码。

• 如果需要的话，按照一定的标准编译代码，组织代码目录。

• 按照一定的标准将编译后的可执行文件保存到预设的目录中。

如果需要的话，按照一定的标准将可执行文件目录和 Web 服务器目录组装起来，生成启停脚本和必要的配置信息；将上述包含了可执行文件、Web 服务器、控制脚本和配置文件的目录打包保存起来；在需要运行代码时，只需在一个指定的 base 容器中解压上述包，然后执行启动脚本即可，从可运行实体转换为应用实例。

当服务发布完成后，作为一个类 PaaS 项目，Flynn 还需要实现这个服务或应用的整个生命周期管理，包括应用启动和停止、状态监控和测量。

第一，整个服务的生命周期管理的实现很简单，只需要针对微光生成的启动命令和运行起来的 PID 进行操作即可。

第二，服务和应用的状态监控。Flynn Host 上的 Container Manager 进程负责实施健康检查，并检测本身运行着的容器数目，检测结果会更新 Flynn 数据库中的 Formations 表。另一端的 Flynn Controller 保持监听该表的数据变化，一旦发现预期的实例数和实际的实例数不一致，Controller 就会根据差异值重新在某台 Flynn Host 下载并运行对应的 Slug（或者删除多余的实例）。

第三，服务的水平扩展。如果需要增加实例，Flynn 由用户指定某个 Flynn Host 来启动新的实例容器。如果用户不指定 Host，那么 Flynn 调度器会选择一个当前运行中的实例数目最小的 Host 来运行。如果用户需要减少实例，Flynn 会直接选择这个服务或应用的最新实例，然后把它们删除。

2）直接上传用户 Docker 镜像并运行起来。

当需要运行某个应用时，Flynn 会从 Blobstore 中下载对应的 Slug 来运行。Flynn 如果想要用户上传一个 Docker 镜像来运行，就要想办法把镜像制作成一个伪 Slug。对于 Docker 镜像来说，发现和编写两步是不需要的，所以 Flynn 处理 Docker 镜像的过程直接来到了释放这一步骤。最后，就可以使用 scale 指令启动 Docker 镜像。