剑客
关注科技互联网

云应用程序秘诀

模式在软件开发、架构和操作中的价值多年来已被广泛记录。这方面的示例包括 The Open Group 在 TOGAF 中的架构模式讨论 和 Kyle Brown 在运行时模式上下文下的 所有层级的模式 讨论。

在本文中,将学习一种称为 recipe(秘诀) 的新模式类型。您可以使用 recipe 评估候选应用程序是否适合迁移到云或在云中实现。这些应用程序可以仅在云中运行或在混合模型中运行,其中一些组件在其他云平台或传统环境中运行。

Recipe 减少了分析应用程序并确定如何以最佳方式将应用程序部署到 IaaS 或 PaaS 云平台所需的时间和工作量。使用下面列出的 3 个基本构建块,您可以评估每个应用程序,以便定义所需的资源和针对云系统与服务最佳地调整应用程序的方式。此外,您还可以通过两个额外的服务层来扩展基本模式:特定于 recipe 的生态系统服务和一般生态系统服务。

recipe

核心模式或 recipe 提供了如何使用一组运行时和服务构造应用程序或组件的洞察。它们不是 样板 (表示特定服务的一种特定组合),而是一组有关如何组合一般服务类型的说明。样板更像一块冷冻披萨或包装好的日本拉面,而不像是菜谱。

本文将探讨 3 种一般性的 recipe 类型,每种类型具有特定的子类型。您将学习不同的 recipe 类型和支持每种 recipe 类型的服务类型。首先,您需要知道 3 种与您可在云中构建的系统类型相关的概念。您会看到为什么这在定义第一个 recipe 时很重要。系统类型包括:

  • 记录系统 :您可以在记录系统中记录有关真实物体或事件的信息。如果在您的应用程序中,在一个持久存储中包含有关人员、事件和事物的复杂数据,那么您可能是在构建一个记录系统。
  • 互动参与系统 :在互动参与系统中,您主要与人交互,而不是与其他系统交互。如果您的应用程序被设计为访问现有数据,或至多仅允许对现有数据进行简单更改,那么您可能是在构建一个互动参与系统。
  • 洞察系统 :洞察系统或许是最难理解的一种系统类型。如果您的系统被用于回答有关过去的问题,或尝试以某种方式预测未来,那么您很可能是在构建一个洞察系统。

这很重要,因为这 3 种类型中的每种类型都对应于该类型独有的运行时和服务的特定组合。换句话说,这些是我们的第一批 recipe。但是,一个 recipe 包含一个核心材料集合。例如,记录系统通常需要一个数据库来满足其特定的功能和非功能需求。您可以改变的是您针对手头的特定问题而调整的额外材料:非常像烹饪食谱告诉您 “根据口味进行调节”。

事实上,最简单的 recipe 是记录系统的 recipe。查阅 developerWorks 上记录的或我们通过 IBM® Bluemix Garage 构建的数十个记录系统示例后,我们发现 recipe 是:

记录系统 = 运行时 + 数据源 + (可选)网关

图 1. 示例数据源

云应用程序秘诀

云应用程序秘诀

这是什么意思?

运行时是 IBM® Bluemix 中的第一部分,这可能表示一个 Cloud Foundry 即时运行时(比如 Liberty Buildpack)、Docker 容器,或者可能托管应用程序代码的虚拟机。

数据源是下一个组件。它可能是 Bluemix 中的任何 SQL 选择(比如 DB2 as a Service 或 PostgreSQL by Compose Service)或任何非 NoSQL 选择(比如 IBM® Cloudant® 或 Redis by Compose)。

网关可能是更难理解的一部分。一些(但不是所有)记录系统依赖于多个数据源类型,其中一些类型可能位于企业防火墙后。所以网关可能包括 API 管理等服务,或者甚至包含安全网关来获取这些数据源的访问权。类似地,记录系统也可以拥有前端网关。如果您的运行时被构建为异步服务,那么您需要一个类似 Message Hub 或 IBM® MQLight 服务的网关来允许其他系统与它进行通信。

洞察系统与记录系统有一个共同点,那就是数据源。数据源通常是唯一的共同点。这是洞察系统的 recipe:

洞察系统 = 数据源 +(可选)可视化 +(可选)分析工具 +(可选)数据移动

引入的两种新服务也很有必要查看一下。 分析 工具是一个帮助您对数据执行专业分析的服务。分析工具的示例包括 IBM® BigInsights® for Apache Hadoop、Apache Spark 或者甚至 IBM® DashDB™。 可视化 是一种帮助用户查看您的分析结果的服务。它可以是文本形式,比如来自 Embeddable Reports 的报告。或者它可以显示在可视工具中,比如 IOT Real-Time Insights。最后,您可能需要在洞察系统中的不同数据源中移入和移出数据,这是 数据移动 工具(比如 IBM® DataWorks)的工作。

对于互动参与系统,应该始终有一个运行时,通常还应该有一个网关,但不一定要有数据源。如果您的互动参与系统将数据缓存在本地,您可能有一个数据源来充当缓存,但您不应将任何数据永久存储在互动参与系统中 – 这是记录系统的工作。所以互动参与系统的更简单的 recipe 是:

互动参与系统 = 运行时 + [数据源即缓存] + [网关]

在这个示例中,似乎所有组件都是可选的!这个 recipe 没有多大帮助。真正的差异来自下一层,当您考虑更加具体的 recipe 时,这些 recipe 会使用来自特定于 recipe 的生态系统的服务。

图 2. 逻辑 recipe 类型

云应用程序秘诀

云应用程序秘诀

特定于 recipe 的生态系统

下一层是 特定于 recipe 的生态系统 中的服务,在该生态系统中,除了基础 recipe 外,一个或多个特定的 recipe 使用系统或服务在测试或生产环境中正常工作。

recipe 通常具有特定的子类型,可帮助您确定需要哪些核心服务和特定于 recipe 的生态系统服务:

交互系统分为 Web 交互系统移动交互系统:

  • Web 交互系统可能使用特定于 recipe 的生态系统服务,比如 会话缓存单一登录
  • 移动交互系统可使用特定于 recipe 的服务,比如 推送通知移动质量保证移动安全

我们还经常看到 物联网记录系统 ,它们通过 IOT 网关 发送和接收消息。该系统通常与互动参与系统结合使用,允许用户与记录系统存储在数据存储中的信息进行交互。

最后,洞察系统可分为 历史洞察系统实时洞察系统

  • 历史洞察系统使用了 DashDB 中的数据透视表等技术。
  • 实时洞察系统使用了 流分析Apache Spark 等技术

此层中的系统或服务可分为两组。它们包括具有以下用途的系统或服务:

  • 促进成功操作 。这包括监视、负载平衡和缓存等服务。例如,当为一个 Web 交互系统 (SOI) recipe 选择云服务时,您可能发现需要会话缓存、负载平衡或自动扩展。
  • 与应用程序交互 来支持功能需求。交互可使用多种协议(SOAP、REST、JDBC 等)。这些系统或服务的可用性因环境(开发、质量保证、生产)不同而不同,在一些情况下由发布的 API 或虚拟服务表示。

一般生态系统

最后一种服务类型是 一般生态系统 服务,它们支持软件开发、交付和发布生命周期。对于部署到混合、传统或大型机环境的企业,此生态系统为应用程序交付生命周期中的多个环境提供系统和服务。例如,如果您将 Web 应用程序部署在 Bluemix 公有云中,那么您会选择 BlazeMeter 或 LoadImpact 来测试应用程序的性能。如果您在开发一个要部署到 Public Bluemix 上的云原生应用程序,可以选择使用 DevOps Services Delivery Pipeline 来构建应用程序,并将其部署到不同阶段。相反,如果使用混合工作流来开发要部署到传统内部部署环境和一个或多个云(IaaS、PaaS)平台的应用程序,那么应该使用 UrbanCode Deploy 在云平台中部署应用程序和配置整个堆栈。

理解可用的功能

在使用此方法时,您可能希望通过确定是否准备好将应用程序部署到云中,从而确定您的应用程序和模式是否满足条件。此评估过程中遵循的一个不错的框架是 “ 云应用程序的 9 大规则 ”(developerWorks,2014 年 4 月)。

您还应该了解您的云提供者或传统平台功能,尤其是您希望利用的已提供服务。许多提供者拥有网站,比如IBM 的云服务。

如果您打算在混合模型下跨平台操作某个应用程序,那么您还需要了解您拥有的平台集成功能。一个不错的示例是API 和混合云集成。

评估一个云提供者、多个提供者提供的或内部托管的系统或服务。例如,博客 “ 使用 UrbanCode with Bluemix 进行混合云部署 ” 演示了不同交付管道中的一个针对混合和传统平台的常见功能。

构建 recipe

最好将 recipe 应用到每个应用程序,然后寻找可重复的生态系统来将应用程序分类到常见模式中。应该以迭代方式执行此操作,而且仅在需要时引入新的需求或服务。

  • 第 1 步 :构建您的 recipe。试验并确定哪些是适合您的核心 recipe 的正确运行时和服务。
  • 第 2 步 :您的应用程序是否需要 recipe 生态系统服务来实现特定于 recipe 的功能或满足核心 recipe 的非功能需求?如果需要,则添加特定于 recipe 的生态系统服务。
  • 第 3 步 :您的应用程序是否需要生态系统服务来满足解决方案在可维护性、性能、可靠性或安全性方面的非功能需求?如果需要,则添加一般生态系统服务,比如一个或多个 DevOps 服务或安全服务。

下图给出了一个 Bluemix recipe 示例。它包含一个针对 Java 运行时、Cloudant DB、安全网关和 CUPS 的核心 recipe,用于连接到额外的内部部署数据源。它还以 DevOps 开放工具链、自动扩展分析和消息中心的形式包含特定于 recipe 的生态系统和一般的生态系统。

图 3. Bluemix recipe 示例

云应用程序秘诀

云应用程序秘诀

结束语

在本文中,您学习了可用于计划应用程序向 IaaS 或 PaaS 云平台的迁移的架构模式。这种 3 步分层方法提供了一种途径来定义您的核心和生态系统模式,使您能够定义应用程序的运行时拓扑结构和必要的云服务。通过使用此方法,您将减少计划迁移所需的时间和工作,在迁移多个包含类似 recipe 模式的应用程序时降低复杂性。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址