如何跨云实现应用部署管理

平台上售卖。OpenPitrix 架构OpenPitrix 在设计之初，就决定以微服务框架的方式进行开发。微服务相较于单体应用有很多优点，比如降低复杂性，可独立开发、部署、升级和扩展等。在 OpenPitrix 里面，我们拆分出了五个微服务：Repo、App、Runtime、Cluster、Pilot。App 是提供应用开发，注册等功能的服务；1:Repo 上是有很多个 App、App 组，类似于市场的概念。2:Runtime 是一个具体的云运行时环境，可以是某个公有云的某个 Zone，也可以是私有云的某个 Zone。3:Cluster 服务是管理部署在某个 Runtime 里应用实例生命周期的服务，包括创建、升级、扩容、删除等操作。4: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 应用，里面有这些固定名称的配置文件，后缀名标识了文件的类型：1:package.json 里面记录着一些应用元数据，比如 Version 信息，Description 信息，开发者信息， 图标信息等；2:cluster.json.tmpl 定义了具体应用架构，生命周期管理，监控报警等信息，也就是这个应用包含哪些角色，每个角色在启动时需要执行什么命令，关闭时执行什么命令，如何监控应用实例的健康状态等信息；3:config.json 里面会定义一些用户部署应用实例时需要作出填充和选择的信息，比如 CPU、Memory，应用本身的环境变量等信息。4:后面还有一些 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，Rang