级别： 初级 易永明, 高级技术顾问, IBM
2008 年 11 月 28 日 代理服务器管理技术是 IBM Rational Build Forge 区别于开源及其他商业竞争对手的重要特性之一，通过本文你将了解到 Build Forge 代理服务器管理技术的基础概念以及工作原理。
前言
IBM Rational Build Forge 是领先的自动化流程执行软件，除了能帮助客户进行自动化软件构建，测试及发布，也是业界最佳的持续集成服务器。Build Forge 始于 2001 年，在 7 年时间内帮助多家用户在自动化软件开发过程，构建 / 发布的可靠性、可重用性和可跟踪性等多个方面进行了明显改进。Build Forge 在 2006 年 5 月被 IBM 收购并加入到 IBM Rational 产品家族中。
Build Forge 在实际应用中经常被用来管理整个开发组织中成百上千台构建机器、测试机器以及发布和运行机器，这些机器在 Build Forge 系统环境中被称为代理服务器。这些机器负责执行软件开发过程的不同环节，例如编译、构建、冒烟测试、性能测试和发布等。代理服务器往往不仅在硬件上存在巨大不同（不同处理器、内存及磁盘空间），在操作系统（Unix、Linux 和 Windows 等）和应用层面也是千差万别。Build Forge 可以让开发组织的不同开发团队共享这些服务器资源，有效提高企业资源利用率；同时 Build Forge 在代理服务器上实行的用户代理技术可以避免研发人员直接访问这些经过严格配置的代理服务器，确保代理服务器环境的安全与稳定。
代理服务器管理技术是 Build Forge 区别与开源及其他商业竞争对手的重要特性之一，通过本文你将了解到 Build Forge 代理服务器管理技术的基础概念以及工作原理。
文中提到的 Build Forge 功能特性基于 7.0.2.0 版本。
Build Forge 介绍
自动化流程执行平台
Build Forge 可以集中、自动化并且加速不同软件开发组织的软件开发流程。在与其他软件生命周期工具一起使用时可以帮助企业打造出端到端的软件交付流水线，同时也可以更好地帮助软件开发组织合规。对于结构复杂的软件应用开发组织 Build Forge 可以提供一个灵活集成的平台，从而充分利用用户在已有工具的投资来提高整个团队的开发效率、实现交付自动化和可跟踪性。Build Forge 还可以帮助不同地域的团队更高效地进行协同，其所提供的分布式管理方式可以实现全球性的软件交付流程转接和控制。
图 1. Rational Build Forge 的灵活集成平台
（查看大图）
Build Forge 系统概览
Build Forge 提供了一个框架来自动化整个软件开发过程。除了能够对单独的任务进行自动化执行和追踪，还能够自动化软件开发过程中不同环节的信息传递和沟通。Build Forge 可以集成用户现有的脚本和工具，因此没有必要为了使用 Build Forge 而进行额外的脚本开发工作。Build Forge 自动化软件开发流程方案可以提供对应用开发周期完整的管理和控制，通过集成多种工具，Build Forge 可以将复杂的流程标准化、自动化进而进行优化，从而提供一个可重复的、可靠的应用开发生命周期流程。
自动化只是 Build Forge 所做的最基本的工作，Build Forge 还提供了诸如构建加速、自动化通知、调度、日志自动分析等多种功能。通过分布式的、基于 Web 的访问机制可以管理各类任务，对各种类型团队、甚至异地开发团队进行支持。
图 2. Rational Build Forge 系统概览
（查看大图）
Build Forge 代理服务器管理技术
Build Forge 体系架构
Build Forge 是一个典型的三层架构应用，整个自动化流程的配置信息和执行过程数据被存储在关系型数据库中，用户通过浏览器或者 IDE 插件访问 Build Forge 主服务器，Build Forge 的业务逻辑实现均在主服务器上进行，主服务器是 Build Forge 的核心构件，它负责处理并响应用户的数据请求，保持和代理服务器的实时沟通，对关系型数据库进行数据读写操作。自动化流程的每个环节例如编译、构建、冒烟测试、性能测试和发布等的执行并不是在主服务器上进行的，而是由代理服务器完成。
代理服务器在 Build Forge 工作过程中起到关键的作用，它是业务逻辑的具体执行者，在运行过程中代理服务器和 Build Forge 主服务器之间保持实时通信。主服务器按照可以设定的间隔时间去扫描所有配置好的代理服务器，确认它们的工作状态，如果某台代理服务器连接不上或者测试步骤运行失败，主服务器上会立即对该代理服务器显示出红色告警信号，那些即将在该代理服务器上运行的项目、步骤会在初始化的过程中失败退出并给出代理服务器不能工作的错误日志。Build Forge 主服务器和代理服务器之间缺省通过 5555 端口进行通信，用户可以根据自己的需要在配置代理服务器的时候对每一台代理服务器都设置不同的通信端口，前提是要与该代理服务器配置文件中所定义的端口号一致。
成为 Build Forge 代理服务器很简单，只需要在机器上安装 Build Forge 代理程序就可以了。为了适应开发组织不同的业务环境，Build Forge 代理程序支持多种硬件和操作系统平台，包括 Windows(XP/Win2K/Win2003/Vista)、Unix(AIX/HP-Unix/Solaris)、Linux(Red Hat)、Mac OS、System I (As400) 、System Z。同时为了提高其适应性，IBM 向用户公开 Build Forge 代理程序源代码，对于不在 Build Forge 代理程序缺省版本列表里的系统，用户可以通过自己手工重新编译的方式生成其所需要的 Build Forge 代理程序。
图 3. Rational Build Forge 体系结构
（查看大图）
代理服务器模式的优点
大多数 Build Forge 开源和商业竞争对手采用的是主服务器和执行环境捆绑运作的方式，这也是客户自己开发的自动化流程工具最多使用的模式。流程信息和执行环境互相依赖，直接导致硬件资源被绑定在特定的流程执行环境下，例如计费软件开发小组的自动化流程执行服务器由于绑定了计费软件的构建或测试配置环境，所以只能被计费开发小组使用，即使最近计费开发小组工作量比较小，而网管软件开发小组工作非常繁忙导致其自动化流程执行服务器一直处于超负荷工作状态，网管软件开发小组也不能使用计费开发小组的服务器。如果一个开发组织存在非常多的产品或项目，那么就要配备大量的服务器，由于不能在不同产品或项目间共享这些硬件资源，势必造成巨大的浪费。
这种执行流程和硬件环境绑定模式带来的另外一个问题就是维护成本高。由于执行流程信息和硬件环境相互依存，一旦出现硬件系统故障，需要切换到另外一台硬件环境上工作的时候，对维护人员来说就是一场噩梦，不仅要从头搭建整个执行流程，还要手工逐步修改因硬件环境变化导致的不一致性；即使这样，在很多时候新配置的服务器也不能正常工作，因为在不同的硬件环境下执行流程也容易发生变化。同样的情况也出现在新产品或新项目中，虽然已经存在很多这样的自动化流程执行服务器，但执行流程和硬件环境绑定的模式造成配置信息和流程步骤不能被其他产品或项目复用，只能从头搭建一个全新的系统。
Build Forge 通过代理服务器模式对执行流程和硬件信息进行分离，将所有执行流程和配置信息都存放在关系型数据库里而不是驻留在硬件环境中，流程的执行由代理服务器完成，代理服务器上和硬件相关的配置被简化到最小。这种抽象模式直接带来以下好处：
-
极大提高了开发组织的硬件资源利用率。整个开发组织通过 Build Forge 共享代理服务器池并能够实现失败切换和负载分担。
-
减少维护成本，提高流程复用和知识共享水平。
-
加速流程执行速度。通过 Build Forge 分布式并行处理机制可以将流程任务分发到多台代理服务器上并行完成，有效加快了流程的执行速度
代理服务器基本概念
在了解 Build Forge 如何管理代理服务器之前，有必要先掌握 Build Forge 代理服务器配置的基本概念。一台硬件环境安装了 Build Forge 代理程序后还需要通过一定的配置才能够开始工作，这些配置包括：
-
服务器认证。访问代理服务器的帐号 / 密码信息，通过配置可以实现一个服务器认证访问多台代理服务器。
-
收集器。要在代理服务器上收集的信息。收集器包含很多收集器变量，例如 CPU 个数，主频，空闲比率；物理内存大小，可用内存数量；磁盘剩余空间；JAVA 版本号等等，这些信息供后面选择代理服务器的时候使用。Build Forge 自带了丰富的收集器变量，用户也可以自定义收集器变量。
-
清单。Build Forge 主服务器和代理服务器之间是实时通信的，但代理程序按照收集器的内容获取代理服务器上的信息是定时进行的，这个时间可以手工设置，系统缺省是每天执行一次，主服务器把代理程序根据收集器内容获取的信息保存到数据库里形成清单，供主服务器选择代理服务器的时候使用。
-
选择器。用来选择代理服务器的变量及条件。选择器包含所有已经定义的收集器中所包含的变量，并设定不同变量值的比较条件例如只选择 JAVA 版本大于 1.4 的代理服务器，再和所有代理服务器的清单中有关此变量的值进行比较。
-
环境。一系列环境变量的集合，当主服务器访问代理服务器的时候会按环境的内容生成环境变量并对其赋值。
深入了解选择器
在基本概念章节我们对选择器做了一个简要介绍，为了全面了解 Build Forge 管理代理服务器技术，我们对其核心部件—选择器做更深入的分析。
选择器包含称为变量的属性 / 值的列表，可以为变量指定一个值和一个比较。例如，可以指定属性“PERL_VER=5.8”来仅选择具有该属性的服务器，但是也可以指定“JVM_VER >1.4”来选择版本为 1.5、1.6 的服务器。选择器支持数字和字符串比较操作，变量可以是必需的也可以是可选的。
图 4. Rational Build Forge 选择器界面
（查看大图）
要选择合适的代理服务器，Build Forge 将：
-
根据选择器包含的必需变量找到所有具有这些变量的代理服务器。
-
根据代理服务器的清单中变量的值和选择器中变量的条件进行比较，每匹配成功一条得一分。
-
得分最高的代理服务器被选中。
Build Forge 首先对不同代理服务器的必选变量匹配点数进行比较，如果两个代理服务器的必选变量匹配点数相同系统将挑选具有最多可选变量匹配点数的代理服务器服务器，如果可选变量匹配点数仍然相同系统则在这两个代理服务器中随机挑选一个执行任务。可以在选择器中重复定义可选变量，以增加与这些变量匹配的代理服务器的范围。例如，可能需要 MEM_TOTAL> = 1GB，但 MEM_TOTAL >= 2 GB 重复了三次，以便使系统偏向选择内存至少为 2 GB 的服务器。
为了加深对选择器的理解，下面我们用一个例子来说明选择器的工作过程：
名为 S 的选择器所配置的变量列表如下：
|
选择器变量名
|
运算符
|
选择器变量值
|
|---|
|
NUM_CPU
|
>
|
2
| |
MEM_TOTAL
|
>=
|
2000
| |
DISK_FREE
|
>=
|
5000
| |
OS_SYSNAME
|
=
|
Windows XP
|
在 Build Forge 主服务器上配置了三台代理服务器分别为 A1,A2 和 A3，它们共用一个收集器 C，收集器 C 变量列表如下：
|
收集器变量名
|
|---|
|
NUM_CPU
| |
MEM_TOTAL
| |
DISK_FREE
| |
OS_SYSNAME
| |
BF_JOBS
|
在收集器 C 的作用下，三台代理服务器 A1,A2 和 A3 的清单 M1,M2 和 M3 内容如下：
|
清单 M1
|
清单 M2
|
清单 M3
|
|---|
|
清单变量名
|
清单变量值
|
清单变量名
|
清单变量值
|
清单变量名
|
清单变量值
|
|---|
|
NUM_CPU
|
1
|
NUM_CPU
|
2
|
NUM_CPU
|
3
| |
MEM_TOTAL
|
2000
|
MEM_TOTAL
|
3000
|
MEM_TOTAL
|
5000
| |
DISK_FREE
|
8000
|
DISK_FREE
|
10000
|
DISK_FREE
|
20000
| |
OS_SYSNAME
|
AIX
|
OS_SYSNAME
|
Windows XP
|
OS_SYSNAME
|
Windows XP
| |
BF_JOBS
|
3
|
BF_JOBS
|
5
|
BF_JOBS
|
8
|
选择器 S 根据上面提到的算法运算后得到以下得分结果：
|
收集器变量名
|
A1 得分
|
A2 得分
|
A3 得分
|
|---|
|
NUM_CPU
|
0
|
0
|
1
| |
MEM_TOTAL
|
1
|
1
|
1
| |
DISK_FREE
|
1
|
1
|
1
| |
OS_SYSNAME
|
0
|
1
|
1
| |
BF_JOBS
|
0
|
0
|
0
| |
总得分
|
2
|
3
|
4
|
根据以上得分结果，选择器 S 将在 A3 代理服务器上运行项目及步骤。
Build Forge 管理代理服务器工作原理
代理服务器和硬件机器之间是多对一的关系，例如可以把一台 Solaris 机器虚拟成多台 Build Forge 代理服务器，只要这台 Solaris 机器上装有 Build Forge 代理程序。这些基于同一台硬件机器形成的代理服务器可以是相同配置，也可以是不同配置，例如根据登录该 Solaris 机器帐号的不同，创建不同的代理服务器，不同的自动化流程在不同的代理服务器上执行，这样就可以实现在同一台 Solaris 机器既可以做编译构建也可以进行回归测试，因为不同帐号登录该机器的时候环境是可以完全不同的，所以这两个流程环节相互除了共享硬件资源外没有任何其他干扰。
当一项任务需要交由代理服务器执行的时候，可能在开发组织中同时存在多台可以执行该项任务的代理服务器，Build Forge 既可以指定该任务由特定的代理服务器执行，也可以在多个代理服务器之间进行动态选择一个最佳的，这也称为动态服务器池管理技术。
Build Forge 对代理服务器是如何管理的呢？首先请看代理服务器配置表单：
图 5. Rational Build Forge 配置表单界面
（查看大图）
在代理服务器配置表单中首先要求输入代理服务器名称，Build Forge 要求代理服务器名称必须是唯一的，然后要求给出一个主机名称，这里既可以填入硬件机器的名称也可以是 IP 地址，接着要求给出一个已经定义好的，包含用户名 / 密码信息的服务器认证，然后选择合适的收集器及该代理服务器想要具有的执行环境，路径中指的是代理服务器执行主服务器下达的指令是在操作系统的那个磁盘路径下进行的。
再看需要代理服务器执行的任务属性：
图 6. Rational Build Forge 代理服务器执行的任务属性
（查看大图）
在“Execute Unit Tests”任务属性里明确定义了选择器名称，通过该选择器，Build Forge 主服务器找到对应的代理服务器执行该项任务。
具体工作过程如下：
-
Build Forge 主服务器接到用户请求需要执行某项任务。
-
Build Forge 主服务器根据该任务所配置的选择器对所有代理服务器进行筛选并选中合适的代理服务器。
-
Build Forge 主服务器根据该代理服务器所配置的机器名或 IP 地址进行网络连接。
-
网络连接成功后根据代理服务器配置的服务器认证所包含的用户名 / 密码登录该代理服务器物理机器。
-
在该代理服务器上加载环境变量。
-
进入所配置好的路径执行该项任务。
总结
本文所介绍的代理服务器管理技术是 IBM Rational Build Forge 最重要的特性之一，除了能够帮助开发组织极大提高硬件资源的利用效率，还可以降低其维护成本，并且使得自动化流程在复用和知识共享方面变得更加容易。
参考资料 学习
获得产品和技术
讨论
关于作者
对本文的评价
| 
