菜谱小程序_云应用程序食谱

这些年来，模式在软件开发，体系结构和操作中的价值已得到广泛记录。例如，TOGAF中的 The Open Group的Architecture模式讨论，以及Kyle Brown在运行时模式上下文中的所有级别的Patterns讨论。

在本文中，您将学习一种称为食谱的新型模式。您可以使用配方来评估候选应用程序以迁移到云或在云中实施。这些应用程序可以专门在云中或在混合模型中运行，其中某些组件在其他云平台或传统环境中运行。

食谱简化了分析应用程序并确定如何最好地将应用程序部署到IaaS或PaaS云平台中的时间和精力。使用下面概述的三个基本构建块，您可以评估每个应用程序，以定义所需的内容以及如何最佳地将您的应用程序与云系统和服务保持一致。此外，您可以通过两个附加服务层来扩展基本模式。特定配方的生态系统服务和一般生态系统服务

食谱

核心模式或配方可提供有关如何从一组运行时和服务中构建应用程序或组件的见解。它们不是样板文件（暗示特定服务的特定组合），而是有关如何组合一般服务类型的一组说明。样板更像是冷冻的比萨饼或拉面包装的杯子，而不是食谱。

本文探讨了三种通用的食谱类型，每种都有特定的子类型。您将学习不同的配方类型以及支持每种配方类型的服务类型。首先，您需要了解与可在云中构建的系统类型相关的三个概念。您将看到定义第一个配方时为什么这很重要。系统类型为：

记录系统–记录系统是您在其中记录有关真实对象或事件的信息的系统。如果在您的应用程序中，您在持久性存储中具有有关人员，事件和事物的复杂数据，那么您可能正在建立一个记录系统。
互动系统–互动系统是指您主要与人互动的系统，而不是其他系统。如果您的应用程序旨在访问现有数据，或者最多只允许对现有数据进行简单更改，那么您可能正在构建一个参与系统。
洞察力系统–洞察力系统也许是最难理解的系统类型。如果您的系统可以回答有关过去的问题，或试图以某种方式预测未来，那么您很可能会建立一个洞察力的系统。

这很重要，因为这三种系统类型均对应于该类型唯一的运行时和服务的特定组合。换句话说，这些是我们的第一个配方。但是，食谱包含一组核心成分。例如，记录系统通常需要数据库来满足其特定的功能和非功能要求。您可以改变的是适合当前特定问题的其他成分；就像烹饪食谱中的食谱一样，可以指导您“按时品尝”。

实际上，最简单的配方是用于记录系统的配方。在回顾了数十个已在developerWorks上记录或通过IBM®Bluemix Garage构建的记录系统示例之后，我们发现该方法是：

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

图1.示例数据源

这是什么意思呢？

运行时是IBM®Bluemix中的第一部分，它可能意味着Cloud Foundry Instant Runtime（例如Liberty Buildpack）或Docker容器或可以承载您的应用程序代码的VM。

数据源是下一个组件。它可以是Bluemix中SQL的任何一种选择（例如DB2即服务或Compose Service的PostgreSQL），也可以是NoSQL的任何选择，例如Compose的IBM®Cloudant®或Redis。

网关是可能更难理解的部分。一些（但不是全部）记录系统依赖于多种数据源类型，其中某些可能位于公司防火墙之后。因此，网关可以包括API Management之类的服务，甚至可以包括安全网关，以获取对这些数据源的访问权限。同样，记录系统也可以具有前端网关。如果您的运行时是作为异步服务构建的，那么您将需要诸如Message Hub或IBM®MQLight服务之类的网关，以允许其他系统与其通信。

洞察力系统与记录系统（数据源）共享一件事。数据源通常是唯一的通用性。这是洞察系统的秘诀：

洞察力系统=数据源+（可选）可视化+（可选）分析工具+（可选）数据移动

值得研究引入的两种新型服务。分析工具是一项服务，可帮助您对数据进行专门的分析。分析工具的示例包括用于Apache Hadoop的IBM®BigInsights®，Apache Spark甚至IBM®DashDB™。 可视化是一种服务，可以帮助您的用户查看分析结果。它可以是文本形式，例如“可嵌入报告”中的报告。或者，它可以位于IOT Real-Time Insights之类的可视工具中。最后，您可能需要在洞察力系统中将数据移入或移出不同的数据源–这是IBM®DataWorks之类的数据移动工具的工作。

使用参与系统，您将始终拥有一个运行时，通常还有一个网关，但是您可能有也可能没有数据源。如果您的参与系统在本地缓存数据，则可能有一个数据源充当缓存，但是您不应该将任何数据永久存储在参与系统中-这是记录系统的工作。因此，参与系统的简单方法是：

参与系统=运行时+ [作为缓存的数据源] + [网关]

在此示例中，一切似乎都是可选的！那没有太大帮助。真正的区别在于下一层–当您考虑使用来自特定配方生态系统的服务的更特定配方时。

图2.逻辑配方类型

食谱特定的生态系统

下一层是特定于配方的生态系统中的服务，除了基本配方外，还包括一个或多个特定配方使用的系统或服务，以便在测试或生产环境中完全发挥作用。

食谱通常具有特定的子类型，可帮助您确定所需的核心服务和特定于食谱的生态系统服务：

交互系统分为Web交互系统和移动交互系统：

交互的Web系统可能会使用特定于配方的生态系统服务，例如会话缓存和单点登录
交互的移动系统可以使用特定于配方的服务，例如推送通知 ， 移动质量保证和移动安全性

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

最后，洞察力系统可以分为历史洞察力系统和实时洞察力系统

历史洞察系统使用DashDB中可用的表透视之类的技术。
实时洞察系统可以使用流分析或Apache Spark等技术

该层中的系统或服务可以分为两组。这些包括以下系统或服务：

实现运营成功 。这包括监视，负载平衡和缓存之类的服务。例如，在为Web交互（SOI）食谱选择云服务时，您可能会发现需要会话缓存，负载平衡或自动缩放。
与应用程序交互以支持功能需求。操作。交互可以使用多种协议（SOAP，REST，JDBC等）。这些系统或服务的可用性随环境（Dev，QA，Prod）的不同而不同，并且在某些情况下以发布的API或虚拟服务表示。

一般生态系统

最后一种服务类型是支持软件开发，交付和发布生命周期的常规生态系统服务。对于部署到混合，传统或大型机环境的组织，此生态系统为应用程序交付生命周期中的多个环境提供了系统和服务。例如，如果您在Bluemix public中部署Web应用程序，则可以选择BlazeMeter或LoadImpact来测试应用程序的性能。而且，如果您要开发一个本机云应用程序以部署到Public Bluemix上，请选择使用DevOps Services Delivery Pipeline来构建应用程序并将其部署到不同阶段。相反，如果您使用带有混合工作流的应用程序来开发应用程序，这些工作流将部署到传统的内部环境和一个或多个云（IaaS，PaaS）平台，则可以使用UrbanCode Deploy在云平台中进行应用程序部署和全栈置备。

了解可用功能

使用这种方法时，您可能希望通过确定您的应用程序是否支持云来限定您的应用程序和模式。此评估遵循的一个很好的框架是“ 云应用程序的前9条规则 ”（developerWorks，2014年4月）。

您还应该了解您的云提供商或传统平台功能，尤其是希望利用的提供的服务。许多提供商都有网站，例如IBM的云服务。

如果您打算在混合模型中跨平台运行某些应用程序，请了解集成平台的功能。 API和混合云集成就是一个很好的例子。

评估云提供商，跨提供商或在本地托管的系统或服务。例如，博客“ 用于混合云部署的带有Bluemix的UrbanCode ”展示了跨混合和传统平台的交付管道的通用功能。

建立食谱

最好将配方应用于每个应用程序，然后寻找可重复的生态系统，以将您的应用程序分类为通用模式。这应该迭代执行，并且仅在需要时引入新的要求或服务。

步骤1 ：建立食谱。实验并确定最适合您的核心配方的运行时和服务。
步骤2 ：您的应用程序是否需要配方生态系统服务来实现特定于配方的功能或满足配方核心的NFR？如果是这样，请添加特定于配方的生态系统服务。
步骤3 ：您的应用程序是否需要生态系统服务来在可维护性，性能或可靠性或安全性方面满足您解决方案的NFR？如果是这样，请添加一般的生态系统服务，例如DevOps Services或Security Services中的一项或多项。

下图显示了一个示例Bluemix配方。它包括Java运行时，Cloudant DB，安全网关和CUPS的核心配方，用于连接到其他本地数据源。它还以DevOps开放工具链，自动扩展分析和消息中心的形式包括特定于配方的常规生态系统。

图3.示例Bluemix配方

结论

在本文中，您了解了可用于计划将应用程序迁移到IaaS或PaaS云平台的体系结构模式。三步分层方法提供了一种定义核心和生态系统模式的方法，使您能够为应用程序定义运行时拓扑和必要的云服务。通过使用这种方法，当您使用相似的配方模式移动多个应用程序时，将减少计划迁移的时间和精力，并降低复杂性。

翻译自: https://www.ibm.com/developerworks/library/d-cloud-application-recipes-trs/index.html