OpenPitrix 是一个多云应用管理系统，目标是 Run Any Application at Any Scale on Any Infrastructure（能够将任何应用以任何规模部署在任何基础设施上），能够一站式管理企业各种类型的应用，让用户可以把精力专注于核心业务层。
本次内容为青云QingCloud 应用平台顾问工程师迟连义在 2018 年 QCon 全球软件开发大会北京站上演讲内容整理而来。（正文共：9087 字 15 图，预计阅读时间： 23 分钟）
以下为本次分享的内容整理
多云 Multiple Runtime，是指多个云服务提供商的服务应用管理平台，和一般云管理平台 （CMP） 的区别是：一般的云管理平台是管理云的基础资源也就是我们俗称的 IaaS，而应用管理平台是管理应用程序， 这些应用程序可以是单节点，可以是多节点、多角色的，节点之间交互时需要配合上网络、负载均衡器、存储等资源，也就是我们俗称的 PaaS。
多云部署与管理是趋势
我们为什么要去做多云应用管理平台。
今年 1 月份的时候，在知名云服务商 RightScale 公布的一份年度云状况调查报告中显示，采用多云管理的企业占受访的 81%，这充分说明多云是未来企业上云的一个大趋势。
多云的好处很多，很重要的一个因素防止被单个云服务提供商绑定，跨多个云服务提供商可以对冲风险，再者，每个云服务商的产品各有优劣，比如有的云存储功能强大，有的云数据库产品更稳定，采用多云可以充分利用其优势产品。
使用单云架构时，可以直接用这个云提供商所提供的成熟的管理工具或管理界面就可以了，但在多云环境下，用户希望能有一个统一的界面管理多个云服务，来降低运维和管理的复杂性。
应用是最贴近需求的，所以一个多云应用管理系统更具有市场需求，这样用户可以把更多的精力放在核心的业务层。同时企业可能有各种类型的应用需要管理，包括传统的应用，像数据库、Tomcat、Hadoop，还有基于微服务架构的应用、以及近来发展迅猛的 Serverless 应用等。企业需要一个可以管理不同类型应用程序的一站式管理平台。
俗话讲「格局有多大，成就就有多大」，做项目也是这样，既然我们做「多云应用管理平台」，我们的目标就是形成一个应用市场生态系统，各种企业开发者都可以在这个平台上开发他们擅长的 App，并便捷的提供在线运维和帮助，这些开发好的 App 提供给其他企业用户去使用，开发者可以盈利，使用者可以跳过手动搭建和维护的流程，使用现成的产品。
为了做成生态这个目标，从一开始这个项目就是以开源的方式进行，包括讨论、设计、代码都是在 GitHub 上完成的。
还有一个很主要的原因，我们几年前就开始开发应用上云的平台，2015 年 5 月发布了 AppCenter 的第一个正式版本，在 2017 年初发布了 AppCenter 2.0，旨在让开发者以最低的学习成本几天将应用部署到云平台上，这个平台提供应用的服务感知、弹性伸缩、配置变更等云计算基础特性。而且还为开发者提供便捷的管理、日志、监控、财务、工单等功能，最终用户在应用市场很便捷的找到自己需要的各种应用，通过一键部署来使用。
AppCenter 平台自去年 3 月份发布以来，已经陆续上线了一百多个不同企业开发者所开发的 App，其中涵盖了：大数据、AI、容器、 区块链等各种领域的应用。但 AppCenter 底层只兼容青云的 IaaS，我们的私有云用户也有 AppCenter 的需求，但私有云一般有多个云部署环境，所以客户提出 AppCenter 兼容其它云厂商的要求。
多云+应用+开源
这就是多云应用管理平台诞生的由来，我们给他起的名字叫做：OpenPitrix，集多云，应用管理，开源于一身的项目。这个名字的由来，Pitrix 是 PaaS + IaaS + Matrix （矩阵） 三个词的一个集合，这个其实是青云内部的项目的名字。我们拿来用了，前面加上 Open 即表示这个项目是开源的，也表明我们开放的心态。
OpenPitrix 想实现的是 Run any application at any scale on any infrastructure，也就是通过 OpenPitrix 这个平台可以将任何类型的应用部署到任何类型的基础设施上面。对于开发者来说就是 Build Once，Run Anywhere。
OpenPitrix 所能提供的功能，主要有 4 大块。
首先是多云平台的支持。
云平台可以是 AWS，可以使 OpenStack，既可以是基于 VM 的，也可以是基于容器的， 可以是公有云，也可以是私有云。 针对于平台提供商，OpenPitrix 会提供相应的 ProviderPlugin 插件，去调用相应云平台提供商的 API 来管理运行在其上的应用。
第二个是多应用类型的支持。
各种类型的应用都会支持，很多企业使用的是传统应用，他们希望在不改变其现有架构的情况下将其应用上云，所以这些传统应用是需要支持的。
这些传统应用既可以是典型的基于三层架构的软件，也可以是各种分布式软件：Hadoop 这种主从结构、ZooKeeper 这种 Peer to Peer 结构、Redis Cluster 这种分片结构都可以被 OpenPitrix 所管理。
微服务架构是大趋势，所以微服务类型的应用我们也会支持，微服务应用往往是容器化的，在容器的编排方面，开源项目 Kubernetes 已经是事实上的标准，因此，OpenPitrix 会支持 Kubernetes。Helm 是一个非常不错的 Kubernetes 包管理器，提供了打包、部署等功能。 在第一版 OpenPitrix 中，我们使用 Helm 作为 Kubernetes 应用程序的部署工具，来提供微服务类型应用的部署。
Serverless 应用我们也会支持，但目前来讲，由于 Severless 应用还没有一个统一的标准，第一个版本暂不支持，会持续关注其发展。
第三个功能就是高度可扩展和可插拔。
既包括云平台的支持，也包括应用类型的支持，这样无论未来出现了何种新的云服务商，或者是新的应用类型，都可通过添加相应插件的方式支持它。
第四是可商业运营。
我们最大限度解耦应用和应用所运行的云环境，一方面让开发者便捷的开发 App，同时平台为其提供管理和运维、计量计费、查看报表及统计信息等，应用可以放到公共市场，或者专有市场上去售卖。 另一方面用户可以在其所拥有的云运行环境上，部署相应的 App。任何基于 OpenPitrix 开发的应用， 都可以在任何基于 OpenPitrix 的应用管理平台上售卖。
OpenPitrix 架构
OpenPitrix 在设计之初，就决定以微服务框架的方式进行开发。微服务相较于单体应用有很多优点，比如降低复杂性，可独立开发、部署、升级和扩展等。
在 OpenPitrix 里面，我们拆分出了五个微服务：Repo、App、Runtime、Cluster、Pilot。
- App 是提供应用开发，注册等功能的服务；
- Repo 上是有很多个 App、App 组，类似于市场的概念。
- Runtime 是一个具体的云运行时环境，可以是某个公有云的某个 Zone，也可以是私有云的某个 Zone。
- Cluster 服务是管理部署在某个 Runtime 里应用实例生命周期的服务，包括创建、升级、扩容、删除等操作。
- Pilot 这个服务提供了 OpenPitrix 可以和部署到某个 Runtime 里面应用实例进行双向请求的能力。
每个微服务有自己的服务进程，有自己的数据库，一个服务的数据库也不可以被其他服务直接访问，因为每个服务是独立开发的，这样可以确保单个服务的表结构修改不会影响到其他服务。
持久层框架选择的 DBR，是因为这个框架没有其他依赖，代码简单，易于维护。
数据库迁移工具，选择的 Flyway，可以在子服务启动之前构建好数据库以及表结构，并可处理后续的数据库迁移工作。
对外提供 DashBoard 和命令行工具 CLI，外部访问都是通过 Restful API，经由统一的 API Gateway。Api Gateway 在经过内部路由将请求转发给具体的某个微服务上，各服务之间的通信属于内部通信，通过 GRPC 来实现，选择 GRPC 而没有用 Restful，由于其是二进制协议，相比于 Restful 的 HTTP 协议性能更高。
各服务之间会使用统一的一套 ETCD 服务，该服务提供配置更新\全局锁\消息队列等功能。
采用微服务设计，OpenPitrix 可以很方便的容器化，部署在容器平台中，比如 Kubernetes，并享用 Kubernetes 所提供的微服务治理功能，像服务发现、监控、负载均衡等。
解耦应用和其所运行的云环境
先看右下角，Runtime 是云的运行时环境，有 Provider 的属性，也就是云提供商，根据 Provider 用具体的 ProviderPlugin 去操作，Runtime 可以打标签 Labels。
每个 App 都可以用一个应用配置包来描述，这个配置包的内容后面会介绍。应用的配置包都是位于 App Repo 上面，App Repo 可以是 GitHub，也可以是某个云服务商提供的对象存储。
App Repo 也可以打标签，比如 Sorftware = DataBase 表示这个 Repo 上的 App 都是数据库相关的，App Repo 有个 Provider 属性，这是为了标记当前 Repo 上的 App 能够部署到哪些 Provider 的 Runtime 中去。Selector 是可以针对 Runtime 的 Label 进行检索的属性。
举个例子，开发者正在开发一款 MySQL 应用，开发中状态也就不是稳定版本，开发者将这个 App 上传到了第二个 App Repo 里面，Label 是 Sorftware = DataBase，这个 Repo 的 Provider 属性是 OpenStack 和 AWS，同 Key 是 or 的关系，不同 Key 是 and 的关系，也就是可以部署在这两个 Provider 的 Runtime 中，Selector 是 Env=Developing。
这时假如最终用户要部署这个 App， 系统会自动根据 Provider 信息，以及应用所在 Repo 的 Selector 和 Runtime 的 Label，自动选择可用的 Runtime，在右侧这些 Runtime 中，只有最后一个符合条件，可以部署这个 App。
Repo 子服务
看完了整体的架构，接下来重点介绍几个子服务的架构。
Repo 子服务采用了松耦合的设计，分为三个组件：Repo Manager、Repo Indexer、App Repo。
图中中间这部分是 App Repo， 可以是 Google 的 Storage，也可以是青云QingCloud 的 QingStor?对象存储 ，上面就是一个个的应用配置包。
左侧是 Repo Manager，负责 Repo 的增删改查功能，拥有自己的数据库，记录着 Repo 存储的地址、登录用的凭证、可见性等信息，可以是公开，可以是私有，也可以是特定用户组内共享。
最右侧的 Repo Indexer 会周期性地扫描注册的 Repo，发现 Repo 上的配置包有任何更新，就会将 App 信息同步到 App 子服务中。
我们可以看出，Repo 的存储是独立于 OpenPitrix 平台的，所以，仓库存储的应用可以共享给任何基于 OpenPitrix 的应用管理平台使用甚至售卖。
App 子服务
App 子服务控制一个应用，以及应用的具体版本的生命周期， 在这里我们会将应用的版本划分为很多个状态，状态切换会有相应的 API 触发。 OpenPitrix 拥有对应用的全生命周期管理。
只有 Repo 的可见性是 Public 的上面的 App 才是需要管理员进行审核的，这也能够确保最终用户使用到的 App 都是可用的 App。
Cluster & Pilot 子服务
接下来会介绍 Cluster 子服务和 Pilot 子服务的架构，也就是 OpenPitrix 整套架构的核心，也是最为复杂的一块。
在看实现和架构之前，先看几个部署时需要解决的问题，以及我们所采用的解决方案，从而解答我们为什么这样设计 Cluster 子服务和 Pilot 子服务。
第一个问题就是规范的问题，怎么样很好的标识一个应用，比如要开发 Kubernetes 的应用要学习他那套 Yaml 文件的书写格式，OpenPitrix 让开发者在这个平台上开发应用，也需要有一套简单易学的标准。
我们是沿用了之前青云QingCloud AppCenter 上应用开发成熟的定义模式，这是一个标准的配置包的目录结构，是一个 WordPress 应用，里面有这些固定名称的配置文件，后缀名标识了文件的类型：
- package.json 里面记录着一些应用元数据，比如 Version 信息，Description 信息，开发者信息， 图标信息等；
- cluster.json.tmpl 定义了具体应用架构，生命周期管理，监控报警等信息，也就是这个应用包含哪些角色，每个角色在启动时需要执行什么命令，关闭时执行什么命令，如何监控应用实例的健康状态等信息；
- config.json 里面会定义一些用户部署应用实例时需要作出填充和选择的信息，比如 CPU、Memory，应用本身的环境变量等信息。
- 后面还有一些 Option 的文件，比如 License、Readme 还有语言包。
前三个文件是一个应用配置包必须要有的文件， 后三个则是可选的。这其中 cluster.json.tmpl 和 config.json 和应用的关系尤为紧密，定义看起来比较长，但却极易理解。
上图一个 config.json 的例子，记录了在这个 App 中 MySQL 这个角色的资源定义，CPU Default 是 1，也就是默认是 1 核，Range 里面定义了其可选配置，可以是 1 核、2 核、4 核、8 核、16 核。
Memory 的默认值是 2048 也就是 2G，Range 里面定义了 Memory 的可选配置。在用户创建这个应用的实例时，DashBoard 会根据 config.json 里面的定义渲染页面，也就是右侧的截图， 可以让用户根据开发者提供的配置， 选择自己要创建的应用实例类型。
上图是一个 cluster.json.tmpl 的例子， 双花括号里面的是引用自 config.json 里面的值，一键创建时，用的是 config.json 里面变量的 Default 值，当然如果用户创建时通过命令行或者 DashBoard 修改了变量的值，则按照新的值渲染并创建。
这里定义了这个应用有一个叫 ZK 的角色，这个角色创建时需要用到 Docker 的这个 Image，下面 Service 部分则描述了应用创建，删除等生命周期所需要执行的指令，比如这里定义了创建时要执行的 Init 指令和 Start 指令。
开发者通过简单的配置包定义，就完成了应用的开发，可以通过 OpenPitrix，让不同云平台的用户去部署使用。
第二个问题：开发者的应用映像如何分发到多云环境？
其实容器类的应用在映像分发方面做的很好，可以有统一的容器映像仓库，启动时去仓库 Pull Image，所以微服务应用支持不存在映像分发的问题。
而传统应用通常是部署到虚拟机中的，传统应用多云部署时就面临映像分发的问题，开发者定义在应用 Package 里面的映像 ID，如何分发到多云的环境中去？
我们知道，每个公有云都会有很多的 Region 和 Zone，如果让开发者自己在每个里面上传或创建映像，是一件很困难的事情，为了解决这个问题，我们想了很多解决方案，但都还不成熟。
比如让开发者将 VM Image 的制作流程写成脚本，需要某些软件包，则从公网上下载，这样在用户第一次创建这个应用实例的时候，OpenPitrix 平台自动创建这个 Image，然后在跨 Zone 将 Image 迁移到其他 Zone，并共享给用户确保其能够启动应用。
在第一版本传统应用我们会先采用 VM 里面跑 Docker 的方式来解决映像分发的问题。
第三个问题，如何操作云主机执行命令，是个网络问题。
OpenPitrix 自身是可以部署到任何地方的，而最终用户要部署的应用是运行在各个云环境上的 IaaS 资源上，那两者之间如何通信，以及发送指令的呢？
我们的解决方案是通过公共互联网，也就是两者通过公网打通，现在的云平台主机资源为了安全性， 一般都是运行在专有网络里面的，也就是位于 VPC 下面，我们 OpenPitrix 也会将应用实例默认部署到 VPC 下，具体解决方案是分别在 OpenPitrix 框架内，位于 VPC 下应用实例主机里定义了 3 个组件：Pilot、Frontgate、Drone。
Pilot 领航员的意思，是 OpenPitrix 在部署 VM 类型应用时所使用的一个服务，作用就是下发命令给具体部署在某个 Provider 提供的云服务的 Runtime 的 Instance。
Drone，无人机，是运行在应用程序所在的主机上的，该组件由 Agent 和 Confd 所构成，Confd 是一个开源的项目，能够自动完成 App 服务配置文件更新，并在配置发生变化时触发特定的操作。Agent 负责接受 OpenPitrix 框架发过来的指令，并上报指令的执行状态。
Pilot 没办法直接发指令给 Drone，因为一个在 OpenPitrix 上，一个在具体 Runtime 上， 环境不同，没法直接通信， 所以需要一个 Proxy，来转发请求， 这个功能就是 Frontgate 提供的。
Frontgate，直译是前门，也就是最外层的大门，在有应用运行的 VPC 中都会存在一个 Frontgate，这个 VPC 内的所有应用集群共享这个 Frontgate。
该组件包含 Proxy 和 ETCD，Proxy 起着承上启下的转发功能，Frontgate 主机创建时，会将 Pilot 的地址写入，Frontgate 启动时可以和 Pilot 建立一个双向的 Grpc Stream，建立这个连接后，两个组件之间可以任意通信了。
后面 Pilot 就可以发指令给 Frontgate，而 Frontgate 和 Drone 位于同一 VPC 内，属于内网，可以将请求发给 Drone 并执行，执行结果也可以经由 Frontgate 上报给 Pilot。
Frontgate 里面的 ETCD 会存储应用部署实例的元数据信息， Drone 里面的 Confd 也是通过 Watch ETCD 从而实现服务发现和自动配置变更的。
这里有必要说一下， 既然 Pilot 只是一个下发指令的服务，从 Cluster 里面独立出来，是为了灵活的扩展性。Pilot 控制多云 VM Based 的 Runtime 里面的主机，量会越来越多。
目前第一版本，我们没有考虑多云应用的编排， 比如 AWS 上的一个 Kafka，使用的 OpenStack 上部署的一个 ZooKeeper。但由于 Pilot 可以和任何一个 Runtime 交互，所以后面的版本我们可以基于 Pilot 做多云应用的编排。
现在假设有一个用户要在 OpenPitrix 上部署一个应用，他选择应用，选择 Runtime，填写应用所必须的资源信息和环境变量后，点击创建，OpenPitrix 会如何工作呢？
首先，发送 API 到 API 网关，API 网关会将之转发给 Cluster 子服务；
然后，Cluster 子服务收到请求之后，会先解析配置包，注册 Cluster 的数据库信息，然后将请求封装为一个 JOB，并放到 JOB 消息队列中等待调度执行，JOB Controller 会异步的解析 JOB，拆分成多层 Task，每一层 Task 是可以并行执行的，多层 Task 是有依赖关系需要顺序执行的，这样就将一个 JOB 解析成了 Task 的工作流，Task Controller 可以逐层的去调度执行 Task，保障依赖顺序。
其次，Task 是根据当前 Runtime 的 Provider 的 Provider Plugin 来执行的，Task 有几种类型：
一种是调用云服务的 API 来执行 RunInstance、CreateVolume 的操作，如果是容器类的应用，Task 会将请求发给 Helm 的 Server 端，Tiller 去执行，这个后面会介绍。
如果是基于 VM 的应用，有些 Task 是需要经由 Pilot 下发到 Drone 的，这些 Task 的依赖 Task 就会完成前序工作。
也就是创建好 Frontgate 并和 Pilot 建立双向 Grpc Stream 连接。通过他们之间的交互，完成创建步骤后续的元数据注册，Confd 服务启动，开发者定义的 Init 和 Start 指令的执行等操作。
OpenPitrix 同样支持容器类型的应用，我们第一版本中的 K8S Provider Plugin 是通过 Helm Client 实现的，容器应用会通过 Helm 部署到 Kubernetes 集群中。
目前 Helm 的服务端 Tiller 只支持将 Chart 的实例部署到单一 Kubernetes 中去，所以需要在 Kubernetes 的 Runtime 里安装 Tiller 这个服务。
OpenPitrix 应用实践
刚才介绍了 OpenPitrix 的功能以及技术架构，接下来一同看下 OpenPitrix 的主要应用场景。
由于 OpenPitrix 的 Runtime 既可以是公有云，也可以是私有云的，所以最普遍的一种场景就是为采用多云或者混合云系统的企业，提供一站式的应用管理平台，让企业的员工可以不关心 IaaS 层，直接使用应用，且只用一套管理界面。
再一个就是一些云管理平台，只有多云 IaaS 资源的管理， 那可以将 OpenPitrix 整合进去，从而增加多云应用管理的功能。
第三个是 OpenPitrix 可以作为 Kubernetes 的一个应用管理系统。
OpenPitrix 和 Helm 有着本质上的不同，虽然 OpenPitrix 底层用了 Helm 来部署 Kubernetes 应用，但 OpenPitrix 着眼于应用的全生命周期管理，比如在企业中，通常会按照应用的状态来分类，如开发、测试、预览、生产等，同时还有应用市场的管理功能，这些是 Helm 所没有的。
OpenPitrix 未来发展
OpenPitrix 这个项目在去年 8 月份启动，到今年 2 月 24 日完成各个模块的设计和讨论工作并开始开发，目前已经完成了第一版大部分功能的开发，我们目前已经上线了官网：
openpitrix.io
希望感兴趣的朋友们加入我们，共同构建这个多云应用管理平台的生态。未来，OpenPitrix 希望逐步发展为多云环境下应用程序管理系统的全方位的解决方案。
