企业在实施云战略的时候，由于历史遗留，或成本考虑，或防止厂商锁定等原因，在企业内部形成数据中心与云共存的混合 IT 架构或多种云平台共存的现状，新的烟囱式建设导致从整体上无法体现云平台的优势。

---

因此，多云统一管理平台尤其是多云应用管理平台成为企业急需解决的难题。多云的好处有很多：

• 首先是防止被单个云服务商绑定，跨多个云服务商可以对冲风险。

• 再者，每个云服务商的产品各有优劣，采用多云可以充分利用其优势产品。

当然，多云拥有诸多优点的同时也带来了挑战，比如管理的复杂性。在多云环境下，用户希望拥有一个统一的平台管理多个云服务及应用，从而降低运维和管理的复杂性。

上篇文章中我们详细讲解了如何通过 IFCloud 来进行多云资源的管理，今天我们将会和大家分享面对多种应用，我们如何来进行统一管理。

OpenPitrix 的诞生

对于企业来讲，其实应用程序是更贴近于需求的，所以一个多云应用管理平台是更具有市场需求，这样用户可以把更多的精力放在核心业务层。

同时企业可能有各种类型的应用需要管理，包括传统的应用，像数据库、Tomcat、Hadoop，还有基于微服务架构的应用、以及近来发展迅猛的 Serverless 应用等。企业需要一个可以管理不同类型应用程序的一站式管理平台。

还有一个很主要的原因，我们几年前就开始开发应用上云的平台，2015 年 5 月发布了 AppCenter 的第一个正式版本，在 2017 年初发布了 AppCenter 2.0，旨在让开发者以最低的学习成本几天将应用部署到云平台上，这个平台提供应用的服务感知、弹性伸缩、配置变更等云计算基础特性。

而且还为开发者提供便捷的管理、日志、监控、财务、工单等功能，最终用户在应用市场很便捷的找到自己需要的各种应用，一键部署来使用。

AppCenter 平台自发布以来，已经陆续上线了一百多个不同企业开发者所开发的 App，其中涵盖了：大数据、AI、容器、 区块链等各种领域的应用。

但 AppCenter 底层只兼容青云QingCloud 的 IaaS，我们的私有云用户也有 AppCenter 的需求，但私有云一般有多个云部署环境，所以客户提出 AppCenter 兼容其它云厂商的要求。

这就是 OpenPitrix ——多云应用管理平台诞生的由来。

OpenPitrix 如何实现多云管理

OpenPitrix 会针对于每一个云服务提供商的服务，提供一个 ProviderPlugin 插件来适配，ProviderPlugin 会使用相应云平台服务商的API来管理运行其上的应用，这种方式可以做到，无论未来新加了任何一种新的云服务商，我们都可以通过添加插件的方式对其进行支持。

OpenPitrix 最大限度地解耦了应用和应用运行时的云环境，这样一方面可以让开发者很便捷地开发应用，并可以管理和运维，查看报表及统计信息；另一方面又可以让开发者对这个应用进行定价，售卖给最终使用用户。

我们可以做到，在基于 OpenPitrix 上开发的任何运行的应用，都能够售卖给任何基于 OpenPitrix 的应用管理平台上去使用，我们的口号是：Run any application at any scale on any infrastructure，也就是基于 OpenPitrix 可以将任何应用以任何规模部署到任何基础设施上面，对开发者来说就是 Build once and run anywhere。

梦想很美好，现实很骨感。

在 OpenPitrix 的建设过程中，我们其实也遇到的很多问题。

第一个就是标准的问题，如何定义一个 APP。

因为 OpenPitrix 本质上是一个开发平台, 提供给开发者开发应用的能力，因此需要一种便捷的开发方式。

我们的解决方案就是用一个应用配置包来唯一的标识一个应用，这个应用配置包里面有很多个配置文件，沿用了之前 AppCenter 那一套成熟的标准定义方式，让开发者易于学习，同时每个文件各司其职。这样一来开发者只要知道怎么去安装软件就知道怎么去开发 APP 了。

第二个问题是应用的映像分发问题。

很多传统应用其实是基于 VM 的 Image，开发者会把 Image ID 写到配置文件的配置包里面，最终用户部署应用实例的时候, 会在具体云环境里面根据 Image ID 创建主机，如果让开发者基于每一个 Region 或者是 Zone，上传或者是创建映像，这会是一件非常困难的事情。

而容器在映像分发方面做得很好，可以有个统一的容器映像仓库，在启动的时自动去仓库 Pull Image，所以我们即将发布的第一个版本使用了容器的解决方案，采用 VM 里面跑 Docker 的方式解决映像分发问题。

第三个问题是网络的问题。

OpenPitrix 自身是可以运行在任何的环境里面的，而具体用户的应用实例是运行在不同用户云环境的 IaaS 资源上，这两者之间怎么样去通信，以及发送指令呢？

我们的解决办法就是通过公网，两者之间通过公网打通。为了安全起见，用户的应用实例一般是部署在专有网络里面，即 VPC 下面的，我们会基于每一个有应用的 VPC 启动一个 Frontgate 的组件，这个组件最大的作用就是 Proxy，组件在创建时会和 OpenPitrix 建立一个双向的 gRPC 流连接，这样 OpenPitrix 就可以与 Frontgate 实现双向通信。

而 Frontgate 和具体的用户应用实例位于一个 VPC 下面，两者之间是网络互通的，所以也是可以通信的，这样就可以让 OpenPitrix 和应用的实例主机，经由 Frontgate 所提供的 Proxy 功能进行双向通信。

微服务打造最强多云应用管理平台

我们在设计开发 OpenPitrix 之初就决定使用微服务架构的方式进行开发，微服务相比单体应用有很多的好处，比如降低了复杂性，可独立的开发、部署、升级扩展等等。

OpenPitrix 内部会拆分出很多个微服务，每个微服务都会有属于自己的服务进程，以及属于自己的数据库。它们会统一的使用一个内部的 ETCD 服务，这个 ETCD 服务是容器平台使用非常普遍的一个组件，我们会用 ETCD 来做全局的配置更新，以及全局锁、消息队列等一系列的功能。

OpenPitrix 还对外提供了 Dashboard，还有命令行工具 CLI，外部访问都是通过 Restful API 的方式，经由统一的 API gateway 来访问，API gateway 内部通过路由机制将这个请求转发到具体的微服务上去处理。

各服务之间的通信属于内部通信，通过 gRPC 来实现的，选择 gRPC 而没有用 restful 是因为 gRPC 是二进制协议，相比于 restful 的 HTTP 协议，性能更高。

我们使用的数据库持久层框架是 DBR，是因为这个框架没有其他的代码依赖，可以很方便的去管理和维护。

数据库迁移工具，我们用了开源的 flyway，因为这个工具可以在子服务启动之前，就能把这个数据库，还有表结构都创建好，并可以管理后续的数据库迁移工作。同时我们使用 confd 实现了自动配置变更，能够自动完成 App 服务配置文件更新，并在配置发生变化时触发特定的操作。

我们使用微服务架构还有个好处就是很容易容器化，容器化以后可以部署到容器平台上，像 Kubernetes 里面，这样就可享用 Kubernetes 生态圈所提供的微服务治理功能，像服务发现、监控、负载均衡、灰度发布等一系列的功能。