36、开源云平台软件对比及 mOSAIC 技术解析

tree8

于 2025-10-12 03:32:32 发布

阅读量26

点赞数

CC 4.0 BY-SA版权

分类专栏：云计算方法与实践文章标签： mOSAIC Cloud Foundry OpenShift

本文链接：https://blog.youkuaiyun.com/tree8/article/details/153096456

云计算方法与实践专栏收录该内容

36 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

开源云平台软件对比及 mOSAIC 技术解析

1. 三种开源平台软件详细对比

为了更好地了解不同开源平台软件的特点，我们对 Cloud Foundry、mOSAIC 和 OpenShift 进行了详细对比，具体内容如下表所示：
| 产品 | Cloud Foundry | mOSAIC | OpenShift |
| — | — | — | — |
| 开发支持 | 1 | 2 | 3 |
| 专注于 Web 应用或通用 | Web 应用 | 通用 | Web 应用 |
| 桌面云模拟器 | 是 | 是 | 否 |
| API 访问 | 否 | 是 | 否 |
| 支持标准编程库 | 是 | 是 | 是 |
| 对 Web 应用架构的影响 | 否 | 是 | 否 |
| 对迁移 Web 应用的友好程度 | 中等 | 中等 | 高 |
| 移植 Web 应用的复杂度 | 中等 | 低 | 低 |
| 标准支持工具 | Spring 工具 | 否 | JBoss, Zend |
| 线程访问 | 是 | 否 | 是 |
| MySQL | 是 | 是 | 是 |
| 允许选择堆栈组件 | 是 | 是 | 否 |
| 允许提取数据 | 是 | 是 | 是 |
| 调试模式 | 是 | 是 | 是 |
| 部署支持 | 1 | 2 | 3 |
| 构建自有云时的锁定情况 | 是（VMware） | 否 | 是（RHE） |
| Web 服务器（如 Tomcat） | 是 | 是 | 是 |
| 内置负载均衡器 | 否 | 是 | 是 |
| 自动扩展应用服务器 | 否 | 是 | 是 |
| 自动扩展数据库 | 否 | 是 | 否 |
| 性能分析 | 是 | 否 | 是 |
| 支持多个云提供商 | 是 | 是 | 是 |
| 服务级别协议（SLA） | 否 | 是 | 否 |
| 使用特殊工具部署 | 是 | 否 | 否 |
| 支持私有云 | 是 | 是 | 否 |
| 允许添加第三方组件 | 是 | 是 | 是 |
| 执行支持 | 1 | 2 | 3 |
| 命令行界面（CLI） | 是 | 是 | 是 |
| Web 控制台 | 否 | 是 | 是 |
| 通过 Web 访问日志 | 否 | 是 | 是 |
| 基于 Web 的监控 | 否 | 是 | 是 |
| 多租户 | 是 | 是 | 是 |

从这个表格中，我们可以直观地看到不同平台软件在各个方面的差异。例如，mOSAIC 在 API 访问、内置负载均衡器和自动扩展数据库等方面表现出色，而 OpenShift 在对迁移 Web 应用的友好程度上具有优势。

2. PaaS 对比的通用标准

这个表格涵盖了 PaaS 评估的多个维度，为我们全面了解和比较不同的 PaaS 服务提供了详细的参考。

3. mOSAIC 满足的标准

mOSAIC 在各个阶段满足的标准如下表所示：
| 阶段 | 级别 | 标准 | 特性（仅支持的） |
| — | — | — | — |
| 所有阶段 | 通用 | 支持类型 | 软件 |
| | | 源代码可用性 | 开源 |
| | | 云依赖性 | 无关 |
| | | 支持多个提供商 | 所有云 |
| | | 接口 | API 访问 - 开放；命令行界面；Web 控制台 |
| 开发 | 特定 | 编程风格 | 通用代码；互操作代码生成；无线程访问；对现有应用迁移的有限支持；应用可移植性支持；可编程弹性支持 |
| | | 标准支持 | REST；OCCI |
| | | 框架 | Eclipse 插件 |
| | | 语言支持 | Java；JavaScript；Python；Node.js；Erlang |
| | | 数据管理支持 | MySQL；键值存储；内存数据；分布式文件系统 |
| 部署 | 特定 | 工具 | 在特殊框架内部署；调试模式；其他：mOS |
| | | 支持的操作系统 | Linux 类别 |
| | | 与其他服务的集成 | 消息服务；数据服务 |
| | | 云注册 | 支持云间互操作性；支持云注册；支持 SLA 协商；支持代理；支持基于策略的服务选择 |
| 执行 | 特定 | 监控 | 应用监控；基于 Web；通过 Web 访问日志 |
| | | 性能 | 性能分析；外部负载均衡 |
| | | 服务级别 | 多租户 |
| | | 模型 | 投资回报率：免费；Apache 2.0；开放 |
| | | 设计价格 | 公共资金 |
| | | 状态 | 开发 |

从这个表格中，我们可以看到 mOSAIC 在多个方面具有独特的特性，例如它支持多种编程语言，提供了丰富的数据管理支持，并且在云注册方面具有较强的功能。

4. mOSAIC 的目标和应用场景

mOSAIC 的主要目标是支持依赖云资源（基础设施或软件）的软件或服务产品开发者的活动，即云应用的开发。云应用提供给最终用户并消耗云资源。mOSAIC 可以帮助开发者解决两个关键问题：
- 问题 1 ：如何将应用从一个云迁移到另一个云（与云间可移植性相关）。
- 问题 2 ：哪个云适合该应用（与云提供商和技术的选择相关）。

基于这两个问题，mOSAIC 支持三种使用多云的场景：
1. 场景 1：更换云提供商
- 应用开发者或其客户可能希望更换云提供商，以实现资源利用、成本或收益的优化。
- 其他原因包括原提供商倒闭、市场上有更好的选择、技术变革、合同终止、法律问题等。
- mOSAIC 的 API 设计使得使用其 API 开发的应用可以从一个 IaaS 提供商迁移到另一个，并且支持云应用的软件栈采用了开源技术。
2. 场景 2：服务代理
- 在快速发展的云服务市场中，为特定应用找到最合适的云服务是一个具有挑战性的问题。
- mOSAIC 的语义引擎基于云本体，支持用户将请求与服务（功能和资源）进行匹配。
- mOSAIC 的云代理扮演云服务代理的角色，帮助用户找到合适的云服务。
3. 场景 3：云应用开发
- 云应用的开发需要在准备执行环境（IaaS 场景）或编程风格（PaaS 场景）方面具备专业知识，开发成本高，测试阶段的成本也可能很高。
- mOSAIC 的轻量级可部署 PaaS 可以在桌面、本地集群或私有云中使用。经过充分测试后，完整的软件栈可以无更改地部署到公共云或用于构建混合云。

5. mOSAIC 的架构概述

mOSAIC 的完整软件栈架构包括以下几个部分：
- 应用支持：包括 Java、Python、Node.js 和 Erlang 中的 API 实现、应用工具、语义引擎和服务发现器。
- 软件平台：包括可部署的核心组件、可部署的应用组件和应用服务组件。
- 基础设施支持：包括云代理、供应商代理和经纪人。
- 云适配器：支持托管和可部署服务。
- 概念验证应用：涵盖五个领域。

mOSAIC 解决方案的开源部分（称为 Cloudware）包括部分应用支持、部分软件平台支持和部分云适配器。代码可在 bitbucket.org 的开源代码仓库（http://bitbucket.org/mosaic/ ）获取，从该仓库可以获取文档页面的链接。

6. mOSAIC 对云软件设计要求的响应

6.1 对电子基础设施可编程性的支持

云计算不仅降低了对电子基础设施的访问门槛，还朝着可编程电子基础设施的概念迈进。在基础设施即服务（IaaS）中，资源的设置需要与用户进行一定的交互；而在平台即服务（PaaS）中，电子基础设施的获取和设置是自动化的，对开发者或用户是隐藏的。使用 PaaS 的好处是可以将创新精力集中在解决问题上，但缺点是开发者或用户对系统的控制不足，可能导致性能不可预测或应用质量低下。

为了解决现有编程库的多样性和供应商依赖性问题，提出了元 API（如 Libcloud、jclouds、Deltacloud、CloudSigma），但这些元 API 仍然与连接的 API 的编程风格紧密相关，并且减少了操作、方法和对象的数量。mOSAIC 则更进一步，通过引入多个抽象层次来消除对云资源供应商 API 编程风格的依赖。

驱动程序 ：维护元 API 级别，是用特定语言和编程风格编写的软件，用于不同类型的资源，如消息队列、键值存储和分布式文件系统。一个简单的参数可以将驱动程序转换为特定云资源的本地 API 翻译器。
连接器 ：描述特定类型云资源的功能，用特定语言编写。
云组件 ：与连接器使用相同的语言编写，调用连接器中描述的操作，并描述应用对结果的反应。
互操作性 API ：在驱动程序和连接器之间充当代理生成器。

mOSAIC 的 Java 和 Python 实现以及初步效率测试证明了这种多层次抽象解决方案的可行性，同时云本体、语义引擎和服务发现机制也有助于应用的开发。

此外，mOSAIC 还采用了应用描述符和资源提案调用的方式来支持应用的部署。应用描述符描述了应用对资源类型和通信的需求，基于此可以开始云服务的经纪过程。如果已经与云提供商建立连接，可以直接部署应用组件和 mOSAIC 软件平台；否则，生成提案调用，云代理将返回可用资源的链接。

在 PaaS 设计中，重用其他供应商或通用服务是一个趋势。mOSAIC 特别关注云原生消息队列系统的重用，如 RabbitMQ，它是应用组件交互和弹性的关键。更换队列系统可以通过应用描述符和组件仓库中的软件可用性来实现。

6.2 对弹性应用的支持

云计算范式目前主要成功应用于 Web 应用，这些应用具有响应时间和可用性保证、长生命周期以及使用 Web 标准等特点。大多数 PaaS 主要支持 Web 应用，限制了应用编程风格，而科学社区的应用需求与 Web 应用不同，他们更倾向于 IaaS 服务，对云弹性的需求较少。

mOSAIC 旨在满足两类社区的需求，支持非 Web 应用的开发，这些应用需要动态调整资源容量。在当前的 PaaS 中，实现弹性有两种方式：编程式和自动扩展（自动缩放）。mOSAIC 同时支持这两种方式：
- 容器级自动化 ：容器管理多个云组件实例，根据消息队列中未处理消息的数量增加或减少云组件的数量，并决定哪个云组件处理消息。当云组件数量超过一定数量时，会发出警报，提示增加容器数量。
- 应用级编程 ：应用可以根据性能测量结果编程式地调整资源。

此外，mOSAIC 还支持在不重启应用其他组件的情况下启动、停止和替换应用组件，这对于长时间运行的组件化应用非常重要。

综上所述，mOSAIC 通过其独特的架构和功能，为云应用的开发、部署和执行提供了全面的支持，特别是在电子基础设施可编程性和弹性应用支持方面具有显著优势，有望在云计算领域发挥重要作用。

7. mOSAIC 弹性应用支持的工作流程

为了更清晰地理解 mOSAIC 对弹性应用的支持，下面通过一个 mermaid 流程图展示其工作流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(应用启动):::process --> B(消息队列接收消息):::process
    B --> C{消息数量判断}:::process
    C -->|消息多| D(增加云组件数量):::process
    C -->|消息少| E(减少云组件数量):::process
    D --> F(容器管理云组件处理消息):::process
    E --> F
    F --> G{云组件数量是否超阈值}:::process
    G -->|是| H(发出警报，增加容器数量):::process
    G -->|否| I(继续处理消息):::process
    I --> J(应用性能测量):::process
    J --> K{是否需要调整资源}:::process
    K -->|是| L(应用编程式调整资源):::process
    K -->|否| I

这个流程图展示了 mOSAIC 在容器级自动化和应用级编程两个层面实现弹性应用支持的过程。从消息队列接收消息开始，根据消息数量动态调整云组件数量，当云组件数量超过阈值时增加容器数量。同时，应用会定期进行性能测量，根据测量结果编程式地调整资源。

8. mOSAIC 与其他开源平台软件的优势对比

为了更直观地看出 mOSAIC 与其他开源平台软件（以 Cloud Foundry 和 OpenShift 为例）的优势，我们将之前表格中的关键信息提取出来进行对比：
| 特性 | Cloud Foundry | OpenShift | mOSAIC |
| — | — | — | — |
| API 访问 | 否 | 否 | 是 |
| 内置负载均衡器 | 否 | 是 | 是 |
| 自动扩展数据库 | 否 | 否 | 是 |
| 支持 SLA 协商 | 否 | 否 | 是 |
| 对现有应用迁移的支持 | 中等 | 高 | 有限但有云代理辅助 |
| 编程风格灵活性 | 主要针对 Web 应用 | 主要针对 Web 应用 | 通用代码，支持多种语言 |

从这个表格可以看出，mOSAIC 在 API 访问、自动扩展数据库和支持 SLA 协商等方面具有明显优势。同时，它在编程风格上更加灵活，不仅支持 Web 应用，还能满足通用代码开发的需求，对于现有应用迁移也有一定的支持，并且通过云代理可以更好地辅助选择合适的云资源。

9. mOSAIC 在不同场景下的操作步骤

9.1 更换云提供商场景操作步骤

评估当前应用 ：对当前使用的云应用进行全面评估，包括资源使用情况、性能指标、数据存储等。
选择新的云提供商 ：根据应用需求和 mOSAIC 的云代理提供的信息，选择合适的新云提供商。
配置 mOSAIC 驱动程序 ：使用 mOSAIC 的驱动程序，将其参数配置为新云提供商的本地 API 翻译器。
迁移应用组件 ：通过 mOSAIC 的软件栈，将应用组件从旧的 IaaS 提供商迁移到新的 IaaS 提供商。
测试和验证 ：在新的云环境中对应用进行全面测试，确保应用正常运行，性能达到预期。

9.2 服务代理场景操作步骤

提交应用需求 ：开发者将应用的功能需求、资源需求等信息提交给 mOSAIC 的语义引擎。
匹配服务 ：语义引擎基于云本体，将应用需求与市场上的云服务进行匹配。
云代理筛选 ：mOSAIC 的云代理根据匹配结果，筛选出合适的云服务，并提供相关信息和链接。
选择和签约 ：开发者根据云代理提供的信息，选择合适的云服务，并与云提供商进行签约。
部署应用 ：使用 mOSAIC 的软件栈将应用部署到选定的云服务上。

9.3 云应用开发场景操作步骤

搭建开发环境 ：在桌面、本地集群或私有云中部署 mOSAIC 的轻量级可部署 PaaS。
编写应用代码 ：使用 mOSAIC 支持的编程语言（如 Java、JavaScript、Python 等）编写云应用代码。
配置资源需求 ：通过应用描述符描述应用对资源类型和通信的需求。
进行测试 ：在开发环境中对应用进行充分测试，确保应用功能正常，性能达标。
部署到生产环境 ：将经过测试的完整软件栈无更改地部署到公共云或用于构建混合云。

10. mOSAIC 未来发展展望

mOSAIC 作为一款具有创新性的开源云平台软件，在云计算领域已经展现出了强大的潜力。未来，它有望在以下几个方面取得进一步的发展：
- 更广泛的云资源支持 ：随着云计算市场的不断发展，新的云资源和技术不断涌现。mOSAIC 可以进一步扩展其对云资源的支持范围，包括更多类型的数据库、存储系统和计算资源等，以满足不同用户的需求。
- 增强的安全性能 ：安全是云计算领域的重要问题。mOSAIC 可以加强其安全机制，提供更高级别的数据加密、访问控制和身份验证等功能，确保用户数据的安全和隐私。
- 与更多技术的集成 ：mOSAIC 可以与其他热门技术如人工智能、大数据分析等进行深度集成，为用户提供更丰富的功能和服务。例如，结合人工智能技术实现智能资源调度和故障预测，结合大数据分析技术提供更精准的性能分析和优化建议。
- 社区生态系统的建设 ：一个强大的社区生态系统对于开源软件的发展至关重要。mOSAIC 可以积极吸引更多的开发者和用户参与到其社区建设中来，促进技术交流和创新，推动 mOSAIC 的不断完善和发展。

总之，mOSAIC 凭借其独特的架构、丰富的功能和对云计算发展趋势的适应能力，有望在未来的云计算市场中占据重要地位，为云应用的开发和部署提供更优质的支持。