虚拟组件是应用模型中的关键概念。
虚拟组件是可实例化的对象，由边界和内核组成。 边界包含配置组件所需的所有内容，将其绑定到外部存储卷上的数据并连接到其他组件。 内核包含一个虚拟机和一个启动卷，而启动卷包含操作系统、配置文件以及在组件内运行的应用软件。
上图更详细地显示了对典型虚拟组件的剖析。 组件的边界包含以下元素：
组件的内核包含一台虚拟机和一个启动卷。 启动卷配置有合适的 Linux 版本，以及组件正常工作所需的所有其他软件包和脚本。 虚拟机已配置为从启动卷启动，并包含多个虚拟网络接口卡。
eth0 vNIC 始终被设置为默认接口，通过它您可以登录到组件，安装软件并进行故障排除，其方式与对任何远程服务器执行此操作的方式相同。
此外，CA AppLogic® 会为在组件边界上定义的每个终端（输入或输出）创建单独的 vNIC。 尽管通过单个 vNIC 可将所有流量传输到组件或传送出组件，但如果为每个终端创建单独的 vNIC，CA AppLogic® 就可以轻松地定形和监控网络流量、强制实施连接协议和提高安全性。
边界包含一组可用于配置组件的组件特定的属性或参数。 启动组件时，CA AppLogic® 会自动为每个属性创建环境变量，并使用已分配给该属性的值对其进行初始化。 此外，CA AppLogic® 会将属性值传播到包含在启动卷中的一个或多个配置文件。 这样就可以轻松地将属性用作配置组件的主机制。
边界可能还包含一个或多个卷占位符。 占位符是用于存储卷的预定义插槽。 您可以通过为组件配置要挂接的卷的名称来填充插槽。 这样，您就可以获得可移动磁盘的虚拟等效项。 许多组件都使用此机制访问内容，如 HTML 页面、自定义代码或数据库。
CA AppLogic® 还会为每个组件分配一个硬件资源预算，其中包括三个范围的集合，这三个范围分别定义了组件的最小和最大 CPU 利用率、内存利用率以及带宽利用率。
最后，CA AppLogic® 会将每个组件与一组执行属性（可影响系统排定和运行组件的方式）进行关联。 您可能会频繁地使用其中的两个属性，即启动顺序值和可迁移标志。 考虑到组件之间的所有依存关系，启动顺序允许您指定和更改同一应用中的组件启动的顺序。 默认情况下，可迁移标志状态为 true，向 CA AppLogic® 指示可以根据排定程序的判断将此组件从一台服务器迁移到另一台服务器。 将此标志设为 false，允许您将组件保留在特定服务器上。
CA AppLogic® 将虚拟组件视为第一类组件对象。 创建新类型的组件时，实际上创建的是一类组件，可以让 CA AppLogic® 知道如何根据需要制造此类组件（称为类的实例）。 由于组件类是用于创建实例的模板，因此无法执行它们。 实际运行的应用仅包含实例，须对这些实例进行配置和互连才能协同工作。
上图显示了 CA AppLogic® 实例化类的过程。 每个类都具有一个关联的类描述符，用于定义以下内容：
类的完整定义包含类描述符和在描述符中标识的整套类卷，包括它们的内容：操作系统、应用软件和脚本，结合使用这些内容可定义组件的行为。
普通组件类可以生成任意数量的实例。 单例是指一次只能生成一个实例的类。 在需要编辑类或排除类的故障时，单例很有用。 因为只有实例可以在系统上运行，所以始终需要使用实例来测试类和排除类故障。 单例可使此过程变得更简单。 单例允许您测试实例并排除实例故障，然后从运行的实例自动生成新的类。
类定义不足以创建可用的运行实例。 要创建可用的运行实例，CA AppLogic® 还需要知道实例设置－一组定义如何连接、配置和执行实例的参数。 实例设置包括外部卷的硬件资源、执行属性、终端连接、组件属性和名称的特定值。
为了创建实例，CA AppLogic® 会解释类描述符并创建虚拟机，此虚拟机的每个终端都具有一个虚拟网络适配器，每个卷都具有一个虚拟块设备。 随后，它会为每个适配器创建一个虚拟网络接口实例，并将其绑定到相应的适配器上。
接下来，系统通过复制相应的类卷为每个在描述符中指定的卷创建虚拟卷实例，然后将其绑定到相应的块设备上。
通常，系统通过修改在类定义中标识的且位于一个或多个实例化卷上的配置文件，就可以使用属性值配置新建的实例。 因为每个实例卷都是各自类卷的副本，所以这些修改对实例而言是专有的。
CA AppLogic® 随后会启动 VM，这样会启动在组件中配置的各种服务。 它使用硬件资源和执行属性控制新建实例的启动、位置、排定和迁移。
CA AppLogic® 会将特定于每个组件实例的配置和连接数据从对给定类的所有组件通用的信息中分离出来，其中包括 OS 代码、应用引擎代码以及使这两种代码协同工作所需的配置参数。
与可以应用于任何组件的执行属性不同，您可以定义特定于每个组件类的配置参数。 CA AppLogic® 提供一种属性机制，用于通过通用属性界面定义和编辑一组此类配置参数。
要充分利用属性机制，您可以在类定义过程中指定属性的名称、数据类型和默认值来定义属性。 还可以选择位于组件卷上的一个或多个配置文件作为属性值的目标。
在组件实例中，可以下列两种方式之一访问属性值：
对于组件边界上的每个属性，CA AppLogic® 都会定义一个根据属性命名的环境变量。 启动时，变量的值会初始化为指定给属性的值。 这样，在组件内执行的后台进程、实用工具和脚本就可以轻松地访问属性。
注意：在组件上定义的属性可用于设置位于基于文本的配置文件中的一个或多个参数的值。 要将组件的属性映射到配置文件中的参数，您需要使用特殊的标记注释对文件中的值进行标记，标识您尝试映射的属性的名称。 设置属性后，CA AppLogic® 会将在文件中找到的值替换为指定给属性的值。
CA AppLogic® 终端是在组件之间进行逻辑交互的连接点。 已设计了终端抽象概念，以便虚拟组件内部的现有软件包可以通过终端进行通信，而无需进行任何修改。
终端可以是输入或输出。 输入是用于接受网络连接的终端。 输出是用于发出网络连接的终端。 对于请求和数据的流，这两种类型的终端都是双向终端。 终端包括网络名、虚拟网络适配器和虚拟网络接口。
当一个组件的输出连接到另一个组件的输入时，CA AppLogic® 会在它们各自的虚拟网络接口之间创建虚拟连线，并为连接的两端分配虚拟 IP 地址。
注意：虚拟 IP 地址仅用于 VM 内运行的软件。 他们不是实际网络地址，不可以进行路由。 连接上的实际流量会通过虚拟连线进行传输。
对于虚拟组件中运行的软件，终端需要显示为具名网络主机。 输入会定义一个主机名，服务器（如 Apache）可以在此主机上侦听传入的连接请求。 未连接时，输出在虚拟机内显示为“无法访问的主机”。 当连接到另一个组件的输入时，同一输出会充当与之建立连接的有效网络主机。 如果登录到组件并 ping 连接的输出，您将看到输出的名称会解析为该输出连接到的其他组件输入的 IP 地址。
注意：终端会消除对其他组件和服务器的引用。
在组件中运行的代码将看到仅包含几个主机的“网络”，这几个主机分别对应于在组件边界上定义的每个终端。 这样，就可以在不同的结构中连接同一组件的不同实例，而无需修改组件的配置。
例如：如果要生成需要访问数据库服务器的组件，您可以定义一个用于访问该数据库的输出，并称之为 DBASE。 在组件内部配置 JDBC 驱动程序时，可以简单地将输出“DBASE”的名称设置为目标数据库服务器的主机名。 运行时，在无需更改 JDBC 驱动程序的目标主机名的情况下，组件的每个实例都可以连接到不同的数据库服务器－相同主机名“DBASE”将自动解析为数据库服务器的正确 IP 地址（特定实例连接到此 IP 地址）。
对于每个终端，您可以指定终端上允许的协议。 这相当于在终端上创建虚拟防火墙，仅让允许的协议通过防火墙。 此外，当设置应用时，CA AppLogic® 可帮助确保只有具有匹配协议的终端才可以彼此连接。 因此，如果组件内部的软件已配置为通过 DBASE 输出与 MySQL 协同工作，则可以将 DBASE 的协议声明为 MYSQL，以防止某些用户不小心将其连接到 Oracle 服务器。
注意：可以将任何终端声明为强制性终端，让 CA AppLogic® 知道组件在未连接到这种外部服务的情况下不能正常工作。 如果强制性终端未连接，CA AppLogic® 将拒绝启动应用，并提示您忘记连接了哪个终端。
每个组件需要至少一个存储卷，即组件从其中启动的卷。 这些卷在组件类定义的过程中提供，并且只要创建组件实例，系统就会实例化这些卷。 定义包含其他卷的占位符的组件通常很有用。 在定义占位符时，这些位置会成为“插槽”，稍后可在其中插入外部卷。
可以“插入”到占位符插槽的卷称为应用卷。 通过执行相应命令并指定名称、存储大小和所需文件系统的类型，可以明确创建应用卷。 可以将应用卷挂接在 CA AppLogic® 控制器上，以在其上传入和传出数据。
例如：定义包含两个卷（启动卷和内容卷）的 Web 服务器组件会很有用。 启动卷包含启动 Linux 和运行 Apache Web 服务器所需的软件和配置文件。 该卷将成为类定义的一部分，并且针对组件的每个实例进行实例化。
但内容卷是包含 HTML 文件、静态图像和脚本（针对于特定网站）的应用卷的占位符。 通过引用内容卷配置 Web 服务器组件的实例将生成为特定网站提供服务的 Apache Web 服务器实例。 该 Web 服务器的页面和其他内容将被放置在内容卷上。
提示：可以使用单个应用卷为多个 Web 服务器部署内容。 实现此目的简单方式是添加可在卷上指定基本目录的属性，给定组件可从该目录中访问内容。 通过此种方式可以轻松配置具有相同内容卷的多个 Web 服务器，同时对每个实例进行设置以提供不同目录中的内容。
相同模式可以用于设计以下两种服务器：通用 J2EE 服务器，配置有包含特定应用功能的 EJB 软件包的卷（和卷上的基本路径）；或通用数据库服务器，配置有包含特定数据库的卷和路径。
事实上，使用应用卷和目录路径的组合属性可以将应用的用户界面、静态内容、代码和数据组合到单个卷中，使部署、修改和维护变得更加容易。
|
版权所有 © 2013 CA。
保留所有权利。
|
|