现在的应用程序从源代码到运行阶段太复杂，没有标准的、通用的方式。整个过程及产出分为以下几个阶段。
- 开发阶段：源代码。
- 构建阶段：发布包/可执行程序。
- 部署阶段：可运行的镜像（发布包+配置）。
- 运行阶段：进程、集群、日志、监控信息、网络。
如果需要管理或者构建一个完整的服务栈，容器扮演的仅仅是一个基本工作单元的角色。在服务栈的最下层，需要有一种资源抽象来为工作单元展示一个统一的资源视图。这样容器就不必关心服务器集群资源情况和网络拓扑，即从容器视角看到的仅仅是“一台”服务器而已。还应该能够根据用户提交的容器描述文件来进行应用容器的编排和调度，为用户创建出符合预期描述的一个或多个容器，交给调度引擎放置到一台或多台物理服务器上运行。
如何为容器中正在运行的服务提供负载均衡和反向代理，如何填补从用户代码制品到容器这一“鸿沟”，如何将底层的编排和调度功能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镜像。
