系统体系结构

本章提供了 Sun Java™ System Content Delivery Server 体系结构的系统视图，并重点介绍了 Content Delivery Server 的不同系统组件如何相互关联以及如何映射到逻辑和物理网络以及计算资源。

1.1 服务传递网络体系结构

服务传递网络 (SDN) 体系结构蓝图用于创建 Content Delivery Server 体系结构的系统视图。这是一个经过精确测试的系统结构，非常适合由 Content Delivery Server 提供的服务。该体系结构使用服务模块和服务域的理念。

服务域包括提供服务所必需的计算机系统逻辑分组。例如，Content Delivery Server 管理域可能包含部署到一台或多台计算机的 Catalog Manager 和 Vending Manager 控制台组件。

服务模块由一个或多个服务域以及生产网络的计算机系统和网络连接组成。将服务域映射到服务模块可建立软件组件到物理资源的映射。

Content Delivery Server 的部署通常需要集成多个外部服务。实际上，有若干单个的服务模块可能提供这些外部服务。但是，本文关注的是外部系统的各个质量特性对集成内容传送系统的影响，为了简化起见，讨论过程中假设一个服务模块（称为外部服务模块）提供了所有这些服务。如何最好地部署外部服务以提供所需级别的质量不在本文讨论范围内。进行简化后，典型的内容传送系统包括下列服务模块：

注－对于本文的其余部分，“内容传送系统”和“内容传送系统配置”是指 Content Delivery Server 的部署。除非特别说明，否则“部署”都用于说明 cdsi deploy 命令生成的 Content Delivery Server 软件的可配置实例。有关创建部署的详细信息，请参见《Sun Java System Content Delivery Server 安装指南》。

1.1.1 外部服务模块

这些服务的配置通常不在本文中述及。以下各节介绍其质量特性对集成内容传送系统质量的影响。

1.1.1.1 核心网络服务

核心网络服务（例如 DNS）对于内容传送系统的操作至关重要。本指南假设此类服务具有很高的可用性。

1.1.1.2 网关和安全性服务域

典型的内容传送系统要求集成无线应用程序协议 (WAP) 网关。《Sun Java System Content Delivery Server 定制指南》介绍了如何执行此集成。

WAP 网关管理员需要考虑内容传递系统生成的递增负载。对 Content Delivery Server 上的负载进行估算后，还必须估算通过 WAP 网关的负载部分。WAP 网关的可靠性、可用性和安全性对内容传送系统具有直接影响。需要考虑的其他网关包括防火墙、SSL 代理、Web 高速缓存等。

通常必须配置防火墙，以允许和控制对 Content Delivery Server 的访问。防火墙必须能够处理由内容传送系统生成的通信流量。对于使用 HTTPS 的配置，具有硬件加速功能的 SSL 代理（例如 Sun Fire B10p SLL 代理刀片式服务器）能够大大提高系统性能。配置 Web 高速缓存可以提高性能，但由于 Content Delivery Server 设备门户仅使用动态页面以及少量图像，所以 Web 高速缓存对它的影响有限。

1.1.1.3 消息传送服务域

典型的内容传送系统配置要求使用 SMS、MMS 和电子邮件消息传送服务。《Sun Java System Content Delivery Server 定制指南》介绍了如何执行此集成。

消息传送服务管理员需要考虑内容传递系统生成的递增负载。要估算此负载，需要考虑如何根据不同的消息传送服务使用 Content Delivery Server 功能。例如，如果要使用活动功能，则必须预计相对高容量的传出消息。由于使用量随内容传送系统的配置以及用法的不同而具有很大差异，因此无法提供常规建议。

消息传送服务的可靠性和可用性影响传入和传出 Content Delivery Server 的消息传送。如果消息传送服务暂时不可用，Content Delivery Server 不会删除消息。但是，Content Delivery Server 通常没有在消息传送服务或网络中检测消息丢失的机制。虽然消息丢失不影响 Content Delivery Server 的操作，但它会对商务操作产生负面影响（例如客户要求赔偿损失）。

1.1.1.4 OSS 和 BSS 服务域

典型的内容传送系统要求将外部操作和商务支持系统集成。例如，记帐和分级系统、客户服务系统、监视系统等。《Sun Java System Content Delivery Server 定制指南》包含有关如何执行这些集成的信息。

这些系统的管理员需要考虑 Content Delivery Server 的集成生成的递增负载。负载估算取决于集成实现，因此很难提供常规建议。

OSS 和 BSS 系统的可靠性和可用性会影响 Content Delivery Server。影响大小取决于配置。例如，如果集成要求实时调用分级引擎，则 Content Delivery Server 的性能和可用性由分级引擎的性能和可用性限定。

1.1.1.5 LDAP 服务模块

内容传送系统通常需要与现有轻型目录访问协议 (LDAP) 订户目录集成。《Sun Java System Content Delivery Server 定制指南》介绍了如何执行此集成。该目录服务的配置通常不在本文中述及。

目录服务管理员需要考虑 Content Delivery Server 生成的递增负载。由于 Content Delivery Server 主要使用 LDAP 进行用户验证，因此可以通过估算订户会话的频率来估算负载。Content Delivery Server 还使用目录访问和更新（有时）订户配置文件数据。但是，这种用法通常相对较少，您可以通过增加验证使用的估算对其进行说明（例如 10-30%，这取决于使用 Content Delivery Server 管理订户数据的程度）。

由于 Content Delivery Server 依赖于目录服务进行订户验证，因此必须准备好目录服务以供使用（例如，使用群集和目录复制进行部署）。

1.1.2 数据库模块

由于数据库模块可以使用现有资源实际实现，所以本指南假设数据库是 Content Delivery Server 使用的专用资源。

数据库模块包括运行数据库软件（例如 Oracle9i）的单个服务模块。为了进行试验，直接进行数据库安装即可。对于商业内容传送系统，则应该使用一对高可用性群集的服务器并运行 Oracle9i 和 Oracle Real Application Cluster (RAC) 软件来实现此服务域。如果需要，您可以购买通过 Sun^SM 客户就绪系统 ("Sun CRS") 程序完整配置的数据库系统。有关详细信息，请与 Sun CRS 客户代表联系。

Content Delivery Server 数据库用于存储有关订户、设备和内容的信息，还用于记录数据库中的下载、购买和其他事件。对于商业内容传送系统，必须进行正确的备份和复制过程保护此信息。

要维护数据的安全性，应该在独立于 Content Delivery Server 其余部分的硬件上运行数据库，并将其置于订户、开发者、客户服务代理或 Catalog Manager 和 Vending Manager 管理员不能直接访问的其他网络段中。《Sun Java System Content Delivery Server 安装指南》介绍了如何设置数据库的信息。

分发模块提供内容服务模块、数据库模块和外部服务模块之间的连接性。它可以通过冗余负载平衡交换机或软件负载平衡解决方案实现。分发模块的设计未在本文中述及。

1.1.3 内容服务模块

1.1.4 分发模块

管理器表示 Content Delivery Server 的逻辑视图。从组件的角度看，每个管理器的实现都包括数据库模式以及 Web 应用程序和服务的集合。Web 应用程序在应用程序服务器实例中执行，而服务则作为基于 Java 技术的独立应用程序（“Java 应用程序”）运行。《Sun Java System Content Delivery Server 安装指南》概述了各个组件并介绍了它们如何与三种管理器关联。

设计内容服务模块时，应首先确定每种管理器所需的数量以及每个管理器需要的应用程序组件，然后将应用程序组件组织到服务域中。每个服务域由多个计算机系统组成，每个计算机系统运行一个或多个 Content Delivery Server 应用程序组件。部署指定在单个实际计算机或虚拟计算机上的服务域所需的组件集合。部署是使用 cdsi deploy 命令创建的。《Sun Java System Content Delivery Server 安装指南》介绍了有关如何创建部署的详细信息。

服务域的理念与管理器的理念完全不同。也就是说，您可以确定在同一服务域中放置与不同管理器关联的组件，并在不同的服务域中放置与同一管理器关联的组件。

在最简单的配置中，内容服务模块包含一个服务域，其中运行内容传送系统所需的所有 Web 和服务应用程序组件。但是，在下文将会讲到，出于多种原因需要定义多个服务域，每个域运行 Content Delivery Server 提供的应用程序组件的子集。

对有关服务域所做的决策会对系统质量特性（例如安全性、可管理性和可靠性）产生很大的影响。要完成内容服务模块的设计，必须将每个服务域映射到实际资源。

1.2 主要设计注意事项

1.2.1 Catalog Manager 控制台

对于多数内容传送系统，包含 Catalog Manager 控制台 Web 应用程序的单个部署（即单个计算机上的单个应用程序服务器实例）就已足够。如果需要，此域可以纵向（通过添加 CPU 和内存资源）或横向（通过多个实例的服务器负载平衡）缩放。

如果多个管理员并行执行同样的任务，则会在他们操作同样的数据时出现混乱的状况。例如，两个管理员尝试发布同一内容项目。只有一个管理员能够发布成功，另一个会出错。由于高速缓存同步会有时间延迟，因此这种情况多在纵向缩放环境中发生。

要确保目录管理服务的可用性，可以部署两个或多个实例并通过负载共享或故障转移策略配置服务器负载平衡。或者，也可以使用群集或其他种类的管理解决方案配置自动重新启动或故障转移。

如果安全性注意事项允许，则可以在单个管理域中部署 Vending Manager 控制台和 Catalog Manager 控制台。如果将内容提交视为内部功能，则可能还需要包含 Developer Portal。

尽管可以这样做，但是您不应将面向外部的订户服务和开发者服务与面向内部的管理服务结合使用，而应该使用单独的服务域提供面向外部的服务。将面向外部和内部的服务结合使用会使防火墙配置变得复杂并可能破坏安全性。

1.2.2 Vending Manager 控制台

Vending Manager 控制台的部署指南与 Catalog Manager 控制台的部署指南相同。您可以在一个服务域中将单个 Vending Manager 控制台与 Catalog Manager 控制台结合使用。但是，如果有多个 Vending Manager，则必须为每个 Vending Manager 控制台创建单独的服务域。

1.2.3 Developer Portal

对于多数服务传送系统，Developer Portal 的指南都与 Catalog Manager 及 Vending Manager 管理控制台的指南类似。通常一个提供 Developer Portal Web 应用程序的实例即足够，但为了提供可伸缩性和可用性，可能需要多个负载平衡实例。

如果将内容提交视为内部功能，则需要在同一服务域中包含 Developer Portal 和 Catalog Manager 控制台。

1.2.4 Subscriber Portal

每个 Vending Manager 需要一个或多个 Subscriber Portal。很多内容传送系统至少有两个 Subscriber Portal。多数部署都具有使用桌面客户机的 Internet 用户 Web 门户以及至少一个设备门户。您可能需要多个设备门户，原因是设备可以通过多种方式访问门户，各种方式的验证要求各不相同。例如，设备可以通过 WAP 网关访问门户，使用 WAP 网关用于验证的 HTTP 头进行访问。如果门户还可以通过 HTTP（使用用户名和密码验证）直接访问，则必须防止设备欺诈。虽然防火墙可以滤除包含 WAP 网关进行验证时使用的 HTTP 头的 HTTP 请求，但是更简单更安全的解决方案是提供单独的服务域。这样，配置为接受基于 HTTP 头验证的服务域仅对 WAP 网关可见，并对 Internet 屏蔽。

Subscriber Portal 非常适用于纵向和横向缩放。这样易于添加资源，以便支持日益增长的订户群。横向缩放通过在不同的服务器或系统域中运行实例可以很容易地确保可用性。它为中小型部署提供了成本合理的解决方案。结合使用横向可缩放性和垂直可缩放性是较为大型的部署的良好解决方案。将很多小型服务器合并到少量较为大型的服务器中，可以减少空间和能量消耗并简化系统管理。

1.2.5 Fulfillment Manager

与 Subscriber Portal 类似，Fulfillment Manager 应用程序非常适用于纵向或横向可缩放性。为了更好地利用资源，您可能需要结合使用 Fulfillment Manager 应用程序和为 HTTP 访问配置的 Subscriber Portal。

1.2.6 Java 消息服务和服务配置

每个 Vending Manager 至少需要一个 Java 消息服务 (JMS) 代理，对于 Catalog Manager 也同样如此。Catalog Manager 可以与一个 Vending Manager 共享 JMS 代理。缺省情况下，包括至少一个 Web 应用程序的任何部署都有自己的 JMS 代理。此配置用于保证最大程度的可用性，但是会使与记帐系统的集成复杂化，因为每个部署都成为事件的单独源。这在横向缩放的环境中尤为复杂。要简化集成，可以选择使用共享的代理配置。例如，每个服务域使用一个代理，或者每个 Vending Manager 也使用一个代理。

可以为每个部署指定要使用的 JMS 代理。如果使用的是 WebLogic 应用程序服务器，可以通过在部署配置文件中指定 Java Naming and Directory Interface™ ("J.N.D.I.") API 服务地址来执行此操作。如果运行的是 Sun Java System Application Server，则可以通过在运行 deploymq.sh 公用程序时指定外部 JMS 代理来执行此操作。有关部署配置的详细资料，请参见《Sun Java System Content Delivery Server 安装指南》。

如果使用缺省的 JMS 配置，则可以包含每个应用程序并将其作为每个服务域的每个部署部分执行。

但是，如果已经选择使用共享的代理配置，每个 JMS 代理最多只能运行每个应用程序的一个实例。

对于每个 JMS 代理，都应该选择代理为缺省代理的部署并添加所需的服务（后付费和消息传送依赖于事件服务）。如果使用的是 Sun Java System Application Server 和外部 JMS 代理，可能无法执行此操作。在这种情况下，应该为这些服务定义服务域，并可能为每个适用 JMS 代理部署策略的情况定义其他应用程序组件。

1.2.7 推送监听器和确认监听器服务

对于每个 Vending Manager，都可以将推送监听器和确认监听器服务添加到包含对应 Subscriber Portal、Fulfillment Manager 或 Vending Manager 控制台的任一服务域，这取决于哪个服务域最能满足特定监听器实现的可缩放性要求。或者，也可以创建单独的服务域。

如果监听器实现不支持多个实例同时运行，则应该进行特殊操作。在这种情况下，应注意不要将监听器添加到要横向缩放的服务域中（至少应确保不会在域中将监听器作为多个部署的一部分执行）。

1.2.8 通知服务

必须每个 Vending Manager 正确运行通知服务的一个实例。例如，只要注意不复制此服务，即可将其添加到包含 Vending Manager 控制台的服务域中。

1.2.9 监视服务应用程序

无论如何设计服务域，也无论 JMS 配置的内容如何，始终可以包含监视服务应用程序并将其作为每个服务域的每个部署部分执行。但是，如果要作为映射到同一实际计算机的多个服务域的部分运行监视服务，则必须为每个域配置不同的端口设置。

第 1 章