![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
作为一名好奇的 IT 架构师，在阅读了 developerWorks 文章 创建和定制虚拟应用程序模式 之后，我有一个问题：“创建模式类型有多困难”？因此，我准备为一台单独的服务器构建一个模式类型，这个项目虽然比较简单，但可以演示模式类型的基础概念。
本文为这一过程提供了指南，使用了 我的博客 中一篇更全面的系列文章中的步骤。每个小节都是完整说明的一个要目。为了深入挖掘相关细节，您需要访问链接，阅读完整讨论的 PDF 版本，或者阅读我的博客中的文章。PDF 是实际博客文章的副本，会定期更新；而实际博客文章的链接展示的可能是最新的信息，您可以在本文中找到新的博客文章。
另请注意：和大多数系列文章一样，每一段的内容都基于前面各段的内容，我研究了应用程序模型和物理模型的变化，以及如何通过测试来确保您的更改可以生效。
第一部分首先将描述模式类型 和模式 的区别：模式类型提供了构建模式所需的所有组件、链接、可伸缩性规则等。创建模式类型要做的工作要比根据模式类型创建模式多。
然后，我们会简要介绍以下场景：
- 模式类型只包含一个服务器。
- 该服务器有一个参数。
- 部署过程将在开始安装时记录一条消息。
- 部署过程将在部署期间的另一个时间点记录一条消息。
我们还介绍了三个重要的概念：
- 一个模式类型通常由一个插件组成，该插件包含模式类型的定义以及一个或多个插件，它们包含模式类型提供的功能，而插件的数量则由架构决定。
- 您可以将一个插件分解为两个主要部分：
- 应用程序模型：定义设计虚拟应用程序模式所需的各种组件和链接。
- 物理模型：定义必须在目标云上启动的各种虚拟机和脚本。
- 有两种机制可以将应用程序模型映射到物理模型：一个基于 Java™ 的代码机制和一个基于模板的机制（首选机制和推荐使用的机制）。
最后，我们介绍了本练习涉及的设置步骤：
- 创建一个工作空间。
- 导入模式类型和插件。
- 修改模式类型的名称。
- 编辑模式类型 JSON 描述。
- 为插件创建一个新的 Java 项目。
- 创建一个插件目录。
- 将 META-INF 文件、build.plugin.xml 和 build.properties 复制到插件目录中。
- 更新插件的 config.json 文件。
我还将讨论并提供以下内容的代码：
- 应用程序模型：在 plugin/appmodel/metadata.json 中定义。您将了解如何设计和测试它。
- 物理模型：包含一个 VM 模板文件，定义了应当部署的虚拟元素和应用程序模型的角色。
最后我们还进行了测试，为顺利进入第 2 部分做准备。
下一个任务是创建一个 Master-Slave 模式类型；它有别于第 1 部分的练习，因为 Master 服务器和 Slave 服务器之间有一个链接，该链接从 Slave 服务器检索一些信息（如 IP 地址）来配置 Master 服务器。
第 2 部分的步骤包括：
- 检查应用程序模型，查看我对它做的更改，这些更改是在应用程序模型的 JSON 文件中完成的（第 1 部分）。我们还增加了一个链接类型元素，用它指定源和目标。
- 检查物理模型的变化，了解如何更新 OSGI 目录，并根据与 Slave 相关的 Master 重新构建各个部分。
- 了解如何进行测试以及会产生怎样的结果。
第 3 部分展示如何向 Master-Slave 模式类型添加静态可伸缩性。静态可伸缩性的意思就是在模式设计期间定义实例的数量。
首先，向 Slave 组件附加一个策略组件，然后为该策略定义属性，最后更改 Slave VM 模板，以便导入从应用程序模型收集的信息。（该功能十分重要，因为它还适用于 IBM Workload Deployer 和 IBM PureSystems 专家集成系统）。
当然，为了实现动态可伸缩性（可伸缩性将对监控特性作出反应），您必须能够从服务器收集信息。这一部分的目标是能够监视某个服务器的给定目录中的文件数量，并用图形来展示它们。
涉及的步骤包括：
- 在一个元数据文件中定义将要收集的数据的格式。定义将在创建文件时进行。
- 创建收集器脚本，该脚本会在服务器上收集信息。可以使用不同的方法从服务器中收集信息，如 HTTP、WCA 等等；我选择使用脚本，因为它最容易理解。您还可以通过实现
ICollector接口来实现自己的 Java 类。由于所有收集器都必须遵从这一接口，因此收集器的响应也必须遵循给定格式。 - 创建一些脚本，以便在服务器上上传元数据文件和收集器脚本。我为该角色修改了 install.py 文件。也可以使用其他方法来实现此功能。
- 注册收集器。要注册收集器，请使用命令
maestro.monitorAgent.register()。您应该在 configure.py 文件中执行这个操作。 - 为用户界面提供相应配置，以展示所收集数据的图形表示。您需要创建一个 monitoring_ui.json 文件来展示该图形。该文件应该放在 config.json 文件的旁边。
您添加了一个简单的收集器来计算某个目录中文件的数量；接下来，我们将了解如何利用这个收集器来根据提供的指标添加伸缩规则。
要实现该场景，需要修改一些文件：
- 在设计模式时捕捉伸缩规则参数：
- 要监视的文件目录。
- 最小/最大阈值，表示文件的数量。
- 您希望扩展的虚拟机的最大/最小数量。
- 反应时间。
- 将这些值反映到拓扑中。
- 更改脚本，创建要监视的目录，并将参数传递给收集器。
必须修改应用程序模型的元数据文件，从而捕捉伸缩规则的各个参数并定义伸缩策略。还必须修改 VM 文件，将伸缩策略属性加入拓扑中。
对于脚本，在前面的小节中，我在脚本中硬编码了要监视的目录。我是在安装脚本中执行此操作的，但是现在，由于这是一个角色参数，所以必须将它放到角色脚本中，或者将它放到 configure.py 或 start.py 文件中。显然，这是一个配置角色，因此需要将它放到配置脚本中。
在模式类型中定义一个角色时，可以将该角色与一些操作关联起来，以便在部署该模式时启动这些操作。在本例中，我向角色添加了一个 “向日志发送字符串” 的操作。
要实现某个操作，需要额外添加名为 operation.json 的文件，将它放到 appmodel 目录中 metadata.json 文件的旁边。该文件指定了需要启动的脚本，而该脚本必须位于 part role 目录中。
在每个角色的 operation.json 文件中，可以定义大量操作；每个操作都有 id、书签、描述、分类、脚本和一个属性列表。通过使用分类，可以在 UI 中将大量操作组合在一起。因为该脚本是一个 Python 脚本，所以必须将它放在 role script 目录中。属性会显示在用户界面上。
实现一个非常简单的脚本。该脚本仅检索代码 stringToLog 属性值，并将它发布到日志文件中。您可以使用下面的语法检索属性值：maestro.operation['parms'][{attributeName}];，其中的 attributeName 是您希望检索的属性的名称。该脚本必须放在 role script 目录中。
在 前面有关伸缩的段落 中，我介绍了如何使用您自己的监控收集器进行伸缩（计算某个目录中的文件数量）。您还可以在一个伸缩策略中重用一些嵌入式 OS 指标。重用现有的指标要求更改两个文件：应用程序模型（收集伸缩策略的属性）和拓扑文件（定义规则并实现该策略）。
在应用程序模型文件中，您需要定义伸缩策略并捕捉该策略的所有属性。这非常类似于我们为自己的监控收集器定义策略的情况。与定义大量文件和一个目录来监视属性有所不同，我们将定义一个 cpuUsage 属性，它是一个百分数。定义一个用于服务器角色的策略类型元素。该策略分两个部分：一个适用于静态伸缩策略，另一个适用于基于 CPU 的策略。
对于基于 CPU 的策略，可以定义三个属性：cpuUsage、scaleInstanceRange1 和 triggerTime1。您可以自己选择名称；注意，该名称必须与此后定义的属性列表中的属性 id 相匹配。组中的属性引用的顺序定义了在模式编辑器中的显示顺序。
接下来，您需要定义每一个属性；例如，对于 cpuUsage，可以将它定义为一个范围，并且必须将它显示为一个百分数，默认的最小值和最大值分别为 1 和 100。
在拓扑文件中，需要注入在应用程序模型中捕捉到的属性，使用它们来定义伸缩规则。此操作是在 VM 文件的 scaling JSON 属性中完成的。您可以使用一个 Velocimacro 场景在拓扑中插入元素。
一名客户向我提出下列问题：
我有自己的日志事件系统，想将 WebSphere® Enterprise Application 环境的所有日志文件信息复制到我自己的日志事件系统中，但又不想为了添加一个新功能而重新创建完整的 WebApp 模式类型。那么，我该如何利用现有的 WebApp 模式类型并添加所需的功能？
答案很简单：扩展 WebApp 模式类型，添加一个插件来执行您所需的功能。幸运的是，扩展一个模式类型非常简单。您只需牢记模式类型是由模式类型定义和大量附加的插件构成的。每个附加的插件通过各个 config.json 文件中的几行代码指定它与模式类型的关系。
您需要做的是创建一个新插件，它将链接到目标模式类型（本例中为 WebApp）。然后向 metadata.json 文件添加一些新组件。
操作非常重要：它们提供了在已部署的模式或虚拟应用程序上采取相应措施的能力，比如设置参数和根据这些参数进行处理。启用一个脚本就可以实现这个目的，该脚本是在应用程序模型中创建的 operation.json 文件中指定的。请参阅如何 向模式类型添加操作。
操作模型使您通过参数对运行的模式启用脚本，但也可以使用另一种方法：微调。两者的区别在于，微调后的参数可在存储库 (storehouse) 中永久保存，可以在所运行模式的生命周期内的任意时间进行重用。
微调在已部署的模式中提供了相同的功能，但是参数可以持久保存。您可以使用微调参数重新生成一个崩溃的服务器，并将其设置为早期的版本。这方面的一个示例是 WebApp 模式中的 WAR/EAR 文件；在将它设置好后，该文件路径将永久保存到已部署的模式中。
微调后的参数可以链接到组件属性。
在应用程序模型中，您需要创建 tweak.json 和操作文件。在 tweak.json 文件中定义您的微调参数。
您可能会问 “如果要进行微调，为什么还需要一个操作文件”？您需要使用一个操作文件 ("id":
"configuration",)，让使用户界面显示 “tweak”。
持久存储是在 parameters.json 中完成的，该文件位于存储库的已部署模式中。
不需要在拓扑文件 (VM) 中进行特殊的处理，除非您希望使用 maestro.parms 函数来检索值。
在 SmartCloud Application Services 上将存储器附加到虚拟机
我曾经考虑过如何将存储器添加到在 SmartCloud Application Workload Service 上开发的模式类型生成的虚拟机：事实上，这很简单。您只需更新您的拓扑模板来请求存储器，然后在 vm-templates 数组元素中引用该存储器。
使用一个简单的 VM 文件，通过在 JSON 文件中添加 storage-templates 数组来添加存储器请求，通过在 vm-templates 元素中添加一个存储器数组元素来添加对该存储器请求的引用，然后构建您的插件并进行部署。
一旦完成了模式的部署，就可以进行连接并检查是否已安装了存储器，并且该存储器的大小是否合适。
还要注意的是：SmartCloud Application Workload Service 使用 GB 作为单位来指定其存储器大小；SmartCloud Enterprise 允许您以 GB 和 TB 为单位发出请求。
本文简要介绍了如何在 SmartCloud Application Services 中创建和修改模式类型，希望这篇摘要能够为您构建可重用的模式类型提供一个良好的开端，虚拟类型是用来创建虚拟模式的构建基础。请记住，只要单击本文提供的链接，便可获得每个部分的详细介绍。
学习
-
通过 作者的博客 获得该系列文章的更新。
- 在 YouTube 上了解 如何使用 SmartCloud Application Workload Services 创建一个简单的模式类型。
-
在 developerWorks 的云计算专区 上了解有关云计算技术的更多内容。
-
IBM 在 IBM PureSystems 系列专家集成系统中封装了有关云应用程序部署和系统配置的专家级最佳实践；从 developerWorks 的 PureSystems 专题 开始了解相关内容。
- 关注 Twitter 上的 developerWorks。
- 观看 developerWorks
演示中心，那里提供了面向初学者的产品安装和设置演示，以及面向经验丰富的开发人员的高级功能。
获得产品和技术
-
访问 IBM SmartCloud Enterprise。
-
访问有关 IBM PureSystems 专家集成系统 的更多信息。
-
以最适合您的方式 评估 IBM 产品：下载产品试用版、在线试用产品、在云环境中使用产品，或在 SOA 沙盒 中学习如何高效地实现面向服务的架构。
讨论
- 加入 developerWorks 社区。探索开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户进行交流。
