Cloudify——The Universal Service Manager (USM)

Overview

Universal Service Manager (USM) 是GigaSpaces processing unit ，特为安装、执行、监控、和管理外部过程而设计。 USM管理外部过程的生命周期，并在GigaSpaces 服务网格（GigaSpaces Service Grid）中扮演代理角色。这允许运营商通过服务网格将任何应用程序部署到云，并获得所有的好处(集中管理、远程部署、性能统计、等…)

How it works

建立一个服务器进程通常意味着设立主机(物理或虚拟)，下载和解压缩二进制文件、设置配置文件和启动/关闭脚本。USM帮助您运行在GigaSpaces服务网格机器上的过程自动化。通过USM，可以设置下载、安装、运行、监控整个过程所需要的详细信息的一个文件。这个文件，就是recipe，通过使用领域专用语言（DSL，Domain Specific Language)描述，专门设计来描述这个部署和监控的自动化流程。USM项目还提供内置插件和工具,可以用于常见的场景。配方DSL使得你应该安装和执行过程描述变得容易，使用命令行操作(包括windows批处理文件,Unix shell脚本和与操作系统无关的groovy脚本)或小段代码称为闭包，可以嵌入到配方文件。(More information is available online for Groovy and Closures)

理想情况下,您在运行的进程时，已经带有所需的脚本以启动和停止它，所以一个简单的recipe只会需要你设置这些脚本的名字，并表明你就已经准备就绪了。

What is a recipe

一个配方是基本的指令列表，将在需要时由USM执行。其目的是作为一个工具，可以被很少或没有开发经验的人们使用，但有一个幕后操作。 More details are available in Developing Recipes.

USM Lifecycle

USM的生命周期的各阶段可以被用户所控制，允许一个高水平的自定制。USM的生命周期被划分成几个阶段，每个阶段包括一个或多个事件。recipe在需要时可以实现这里的任何事件。只有“开始”事件是强制事件，用于启动外部过程。生命周期阶段和事件如下所述。

Service Start Phase

events: preServiceStart
当一个服务开始时被调用。这个事件只会在启动服务的第一个实例时执行 (which has an instance ID of 1)。

注意，其它实例可能在同时被启动，因此在他们的初始化阶段，可以在不同实例同时执行。

Initialization Phase

events: init

当USM第一次启动时调用。应该用于验证系统级设置(支持的操作系统,硬件架构,等等)。

Install Phase

events: preInstall, install, postInstall
在init阶段完成后调用。将设置应用程序期望的任何它需要运行的二进制文件。

注意，将来的版本Cloudify将提供内置集成标准软件包管理器, 像apt, yum, msi or maven.

Start Phase:

events: preStart, start, startDetection, postStart
开始事件是唯一强制性事件,外部进程被启动。应该使用的事件如下:

· preStart – 检查所需的操作系统文件可用,如文件、磁盘空间和端口。

· start – 启动外部过程。这个事件有特殊要求(见下文)

· startDetection – 在开始事件中，USM启动外部过程之后，当外部进程被认为是“就绪”时应用程序应该通知它。在实践中，USM常是启动一个操作系统shell，是然后启动实际的过程的启动脚本。当实际的过程是准备好了，USM并不一定知道，因此这个事件提供了一个提示。当这个事件结束，USM将扫描它刚启动的操作系统进程树(即，在开始事件中的这个启动进程，和其所有了子进程）。

Stop Phase:

events: preStop, postStop 
默认情况下，USM通过调用操作系统kill进程来停止这个外部过程。(using the Sigar library). 对于大多数情况，这是一个有效的方法，但可能不适合一些案例，一个进程需要执行特定的关机操作时,如持久化状态到磁盘。在这些情况下，配方应该使用preStop事件来处理任何额外的逻辑。例如，一个tomcat配方可能在preStop阶段调用关闭脚本，然后等待，直到关闭命令关闭了tomcat进程。

Shutdown Phase:

events: shutdown
关闭事件应该用于在USM实例关闭前执行任何需要清理工作。它常用在，运行物理主机上，要删除一些存放在本地文件系统上而不是存放在服务默认目录下的文件时 (服务默认目录下的文件，会在USM卸载时自动删除)。

Service Installation

服务包括一个安装阶段配方,配方将设置正确执行需要的文件。
这些文件通常可以使用下列方法之一，或它们的一个组合：

1. 使用像wget工具，或包存储库像yum、apt、maven，从网上下载文件。
2. 下载文件从本地网络资源，如网络共享。
3. 假设放在文件系统的主机的文件是可用的。
4. 在打包服务文件夹中包括所需的文件，可能是一个压缩的文件，将在安装阶段解压缩，或者是未压缩的文件。

其中每个选项影响部署的系统的架构：

1. 从网上下载文件需要一个外向连接到互联网 (可能在某些环境中不可用)，以及足够的带宽，确保快速下载。所需的时间下载文件也是一个因素，作为一个慢下载将大大增加每个实例的启动时间。最后，源站点必须随时可用，如果一个主机或服务实例失败，一个USM实例必须供应。Cloud Blob Stores通常一个好的候选源站点。
2. 当下载从本地网络资源，资源必须高度可用的。例如，单个NFSserver，是一个不好的选择，因为一个NFSserver的失败可能导USM实例不能恢复。
3. 这个选项通常意味着使用一个预装所需二进制文件的虚拟机，或使用一组固定的以前设置了所需的文件的机器。这种方法是一种适合应用程序期望部署在相当静态的知名的系统，或在一个特定的云供应商。
4. 深入打包文件的过程，打包处理需要考虑打包文件的大小。当前版本，GigaSpaces服务网格会验证文件是否大过150MB。对于小于这个大小的文件，这个打包处理将保持至少两个主机(主机运行GigaSpaces Grid Service Managers). 未来版本将支持更大的文件。

Executable Recipe Entries

几个配方参数是可执行的条目– 条目定义配方特定代码的执行，如执行shell脚本。
USM支持多种方式来定义一个可执行的条目。每种方式都有不同的输入。

· Command line (String): 从字面上表明了命令行应该作为一个外部过程执行。如果空格存在于命令行， 每个单词被视为一个单一的参数，由所有的单词构成一个字符串数组，所以，第一个单词是运行的可执行文件，其余是可执行的参数。

· A list: 类似于命令行选项，这个选项通过部分明确地阐述定义命令行，允许用户通过包含空格参数。

注意处理空格，在操作系统中指定单引号或双引号，它的职责是开发人员来处理这个正确的配方。

· A closure: 在USM的JVM中一个可执行的代码块被执行。该选项提供了最好的性能，允许你在你的recipe中避免使用额外文件，但是需要懂得Groovy编程语言。此外，重要的是要注意，代码执行一个闭包的工作文件夹是在USM的JVM工作文件夹(即，GigaSpaces Grid Services Container)。这通常是在GigaSpaces安装目录下的bin目录下，而不是USM的serrvice文件夹。通过服务上下文可以找到service文件夹。

· A map: 在某些情况下，一个配方将运行在多个操作系统。每个操作系统可能需要一个稍微不同的实现。map选项允许您定义一个映射为每个操作系统。map的key 是一个字符串，表示一个Java正则表达式(更多细节可以在Javadoc中找到，http://download.oracle.com/javase/6/docs/api/index.html?java/util/regex/package-summary.html），其应该是前面描述的选项。
USM将尝试匹配的操作系统，通过map中keys(使用‘os.name’属性) 。和执行第一个匹配的条目。典性的keys是‘Linux’, ‘Win.\*’, ‘Mac.\*’ (最近所有的苹果操作系统)。
操作系统名称的列表可用。在http://lopica.sourceforge.net/os.html.

所有外部进程启动使用服务目录(“ext“的处理单元)作为进程的工作目录。

Command line handling

USM给定的命令行执行一些常见的修改，基于一些常见的用例:

· 在windows上，如果首字以‘.bat’结尾，表有这是一个windows批处理文件，这个命令通过‘cmd.exe’和‘/c’预处理。这是正确的方法来执行一个批处理文件。winndows machines，命令行启动之前，如果第一个参数是一个服务recipe文件夹及子文件夹中的文件，被标记为可执行。

· 如果命令行的首字是以‘.groovy’结尾，USM将会启动groovy processor，由GigaSpaces提供 (在GigaSpaces安装目录中的tools/groovy) ，处理给定的命令。这需要CLASSPATH环境变量是可用的，对于Groovy的特定jar文件是可用的，比如在PU下的lib目录。

Complex command lines

USM并不是操作系统的命令shell替代。
它不处理参数，单引号或双引号、空格、及shell中的其他特殊字符。如果你的命令行是复杂的，建议你复制命令到脚本文件(windows批处理文件,unix shell脚本等)和使用新的脚本文件名作为命令行。 这将确保你的命令执行，就像它是一个shell中执行。

Plugins

配方文件旨在处理最常见的用例,但它是不可能处理所有的场景。
最终,您可能会遇到一个场景中,需要编写自定义代码来处理某种事件或性能统计。
这是什么插件机制允许。一个插件是一个java类，它实现了org.cloudifysource.dsl.Plugin 接口，再加上一个或多个额外的接口这里所描述的那样。
POJO类名称，以及参数的映射，被定义在这个配方文件。 
当USM加载时， 它将根据接口的实现执行插件，给开发人员所需的灵活性。
将包含编译插件的实现和任何额外的类及资源需求的jar文件，放在你的recipe文件夹中usmlib目录。
当PU被部署时，这些文件将被放到PU的lib目录，使得它们在USM的类加载器中可用。

How plugins works

一个类实现一个插件应该实现的接口,它形成钩子(如特定的事件、监控等),并且它必须有一个默认的构造函数。当USM启动时,它将读取DSL文件，并根据recipe中指定的类名中创建实例，通过指定的配方文件参数映射传递参数给该实例对象。然后这个对象加到USM的Spring应用上下文中，它是一个spring bean单例。这个对象将根据接口插件实现会注入到USM不同的钩子。

Monitors and Details

GigaSpaces Service Grid允许一个Processing Unit实例通过key/value的形式发布数据，即可以是保持PU生命周期的静态数据(ServiceDetails)，也可以是任何时候产生变化的动态数据(ServiceMonitors)。
USM发布一组细节和监控器, 主要与操作系统统计的监控过程，但一个配方可能根据需要增加额外的细节和显示器。
在这个时候，添加监控或细节，需要实现一个DSL插件，虽然未来的更新将允许一个配方开发人员直接在配方中定义细节/显示器。
发布监控或细节，插件应该实现一个或两个同时相关的接口:
org.openspaces.usm.details.Details 和org.openspaces.usm.monitors.Monitor.

USM Technical Design

本节描述一些USM实现的技术细节。创建大多数配方都不需要熟悉这些细节，但是对于更先进的实现是有用的。

Implementing events and other integration points

USM在很大程度上依赖于spring的基础依赖注入。 所有用户控制的事件和集成点通过实现一个或多个USM接口形成POJO而实现的。例如，”init“事件是被一个实现接口org.openspaces.usm.events.InitListener 的POJO处理的。在USM启动期间，它将加载DSL文件，并使用其设置中定义的来创建一系列的POJOs，来实现recipe中描述的行为。下图展示了所有可用的接口：

Processing Unit Structure

USM被部署成与标准的XAP Processing Unit一样。
它包括一个标准的pu.xml文件，usm.jar实现文件 (在lib/platform/usm下的XAP安装文件夹下可用)，和一个额外的文件夹, 命名为‘ext’, 用于放置服务的配方和任何额外的资源。
PU
+ lib
     \| usm.jar
     \|
+ META-INF
     + spring
          | pu.xml
+ ext
     | -service.groovy
     |

Process Handling

USM充当一个外部进程的代理，定义在配方中。在GigaSpaces service grid中代表这个进程。要做到这一点，它为此进程监视操作系统指标，如CPU使用率，内存消耗等等。 但能够做到这一点,USM必须先找这个进程。这听起来很容易,因为USM启动外部脚本的组件。但在现实中,可以启动一个进程，进程启动另一个进程，再启动另一个,等等。例如，一个进程可以启动一个groovy脚本。USM启动一个shell进程，像groovy启动脚本的bash，用于启动一个JVM运行Groovy脚本 ，goovy脚本再启动实际的进程。这最后的进程是USM应该监控的，而不是启动时的初始Shell进程。

通过比较在启动外部进程前和启动后的操作系统进程树，实现USM处理。一个新的进程其父进程是USM的JVM，称为子进程（child process）。USM随后寻找一个用相似方式被子进程启动的进程，再继续沿着进程程树找，直到“叶子”进程被找到，不再有子进程。这个进程也是真正的进程（actual process）, 并且这个进程就是USM将将监控性能统计数据

The child process and the actual process may be the same.

在USM能够找到这个真正进程前，它必须首先知道实际的过程已经启动了!启动进程链，最终开始实际的过程可能需要一个不确定的时间。正是因为这一原因，USM支持开始检测事件,即配方确定在实际进程已经开始了。这是最经常完成的等待一个端口打开本地主机上的(如80端口为一个web服务器)或一个特定的文本消息被写入到一个日志文件。例如,通过轮询端口，直到它变得可用，recipe可以告诉USM什么时候实际进程是就绪了。一个工具扫描端口与USM打包在了一起，尽管配方可以配置任意代码来确定这个。

If one of the processes in the process tree under the child process launched multiple processes, theUSM will not be able to determine which process is the actual process. This behavior is not currently supported by the USM.

This document refers to Cloudify Version: 2.2