17、CORBA与互联网应用架构部署全解析

CORBA与互联网应用架构部署全解析

1. CORBA与互联网的融合现状与趋势

CORBA（Common Object Request Broker Architecture）在互联网应用中有着广泛的应用。从基于CORBA的互联网应用所采用的架构类型，到互联网技术与CORBA的关系，都展现出了其重要性。同时，防火墙以及互联网的安全因素也对CORBA产生着影响。

在未来几年，基于CORBA的Web应用架构将会增多。目前，已经有许多CORBA产品被嵌入到应用服务器和电子商务产品中，例如BEA的Tengha和Broadvision的电子商务套件。一些网站也已经采用“Web服务器/ORB网关”的方法进行部署，像美国航空和CNN互动。而且，在下一代基于CORBA的互联网应用中，预计会融入基于XML的技术。

2. 分布式系统部署的必要特性

分布式系统在部署后要可靠运行，必须具备一些特定的特性，这些特性大多与服务质量的维护相关，以应对操作流程中不可预见的中断。
- 稳定性 ：系统的一个部分出现故障可能会导致其他部分也出现故障。即使故障的子系统重新启动，如果它依赖的其他系统元素也出现故障，可能无法正确初始化。因此，可靠的系统必须稳定。
- 故障时的服务连续性 ：在一些传统系统中，部分系统出现故障后，即使需要一小时甚至一天才能恢复，损失也不大。但对于持续向客户端提供服务的分布式系统，应避免可感知的中断。例如，在Web系统中，自动重新提交登录信息并切换到应急服务器，虽然会导致60秒的数据传输延迟，但比让客户端在延迟一分钟后重新登录要好得多。
- 升级时的服务连续性 ：许多传统系统在升级时必须停机。理想情况下，升级不应导致服务中断。
- 故障严重程度的感知 ：系统会遇到内部可处理的小问题和无法处理的大问题。系统需要能够区分这两种情况，在必要时暂停服务并寻求人工干预。
- 实现透明性 ：就像安全和事务处理一样，如果系统的运行时环境能够自动处理故障转移和负载均衡，而无需在业务逻辑中显式编码实现这些功能，那将是理想的。
- 优化 ：当一天中的某个时段有大量用户访问系统时，可以利用进行批处理的机器来分担部分用户负载。负载均衡与故障转移相关，不可接受的响应时间可以被视为故障，需要加以解决。同时，减轻单个进程的负载是重要的预防措施，许多负载均衡技术也可用于同步和切换到应急服务器以实现故障转移。
- 可跟踪性 ：系统及其管理员必须了解系统的运行情况，才能进行有效管理。跟踪可以采取多种形式，从审计纯业务功能到跟踪分布式堆栈跟踪。收集的信息可以用于通知和升级机制，或为负载均衡提供指标。跟踪机制不仅对开发和测试至关重要，对生产环境也同样重要。

3. 系统跟踪机制

了解系统在任何给定时间的运行情况是管理系统的第一步。大多数系统实体都可以且应该被监控，但通常不可能一直跟踪所有内容，因为生成跟踪消息的开销可能会在正常操作期间使系统变慢。可以通过多种方式减少这种开销，例如在需要检查系统的特定方面之前，让跟踪处于休眠状态或低级别运行。

系统跟踪主要有三种形式：
- 日志记录 ：捕获运行时数据和控制流信息，通常进行存档，并且通常一次关注一个服务。
- 监控 ：提供运行时信息，这些信息在运行时处理（也可以存档），并捕获系统的整体状态。只有在有全局监控机制的情况下，才能捕获影响多个服务的实体（如用户）的信息。
- 审计 ：记录整个系统中纯粹与业务相关的信息。

3.1 日志记录

日志记录最简单的形式是捕获开发人员在调试时认为有用的发送到标准输出的消息。更复杂的方法是将消息发送到syslog（UNIX）或事件日志（Windows NT），这样可以在系统标准位置以更具扩展性的方式捕获消息。

为了使日志信息更有用，需要统一的格式，并且所有消息除了特定于消息的数据外，还应包含相同的基本信息，包括：
- 正在处理的事务
- 安全上下文，包括请求所针对的用户ID（注意不包含任何敏感信息，即使是临时的）
- 事件类型，如生命周期（创建、删除）、业务逻辑（计算）、通信协议（servlet或ORB开销）和数据访问（SQL生成或执行）
- 实现上下文，由线程名称等描述
- 消息是否代表异常，以及是否可恢复
- 信息“重要性”的优先级度量（用于排序或过滤）
- 日期和时间戳

事件发生的系统位置首先指的是类、对象实例和服务名称。代码引用（行/文件）可能有用，但不够充分。本地和分布式堆栈跟踪也有助于跟踪。

为了确保日志信息格式的一致性，使用系统标准的日志记录类是一个好的做法。例如，下面的调用：

Log.msg(this,1,"CTR:BusinessObject","Starting to build relations");

第一个参数是对象引用本身，可用于跟踪单个实例；第二个参数是优先级级别，可对消息进行排序，也可以在生产环境中关闭低于某个级别的日志记录；第三个参数是预定义的标签集，用于描述所涉及的操作；最后一个参数是特定于消息的文本。 msg() 方法可以在内部添加日期和时间、线程名称、进程ID等信息。

日志输出可以采用任何所需的格式，XML是一种非常有用的格式，易于解析，例如：

<L0GMSG>
    <DateTime date="l/l/1999" time="3:45:04 pm"/>
    <Service name="fundsservice" host="hostid" pid="lll" />
    <Priority level="l"/>
    <Thread name="pricerthread"/>
    <Object class="com.xenotrope.CalcEngine">objinstdesc</Object>
    <Type> <tag name="CTR"/> <tag name="BusinessObject"/> </Type>
    <MSG> Starting to build relations </MSG>
</L0GMSG>

这种方法可以实现丰富的过滤和跟踪技术，例如监视特定对象或对象类型、跟踪生命周期和服务活动。此外， Log 对象可以实现远程接口或调用其他远程接口，这样相同的日志记录调用可以用于打印到标准输出、写入本地日志、写入分布式日志服务或进行任意组合。

在分布式日志记录中，时间戳差异是一个问题。如果消息在本地进行时间戳标记，由于机器时钟时间的差异，在日志服务端点可能难以解释消息。但如果 Log 对象将消息发送到远程服务，该服务可以负责同步消息，使它们的时间戳具有相对意义。

为了避免消息处理顺序问题，可以设置一个所有日志记录调用都阻塞的单一管道。使用同步调用和单线程日志服务，消息将按接收顺序记录，服务在消息处理完成之前不能继续。但这种方法可能会使日志记录机制成为瓶颈，因此需要进行权衡分析并谨慎实现。

3.2 监控

监控捕获系统的全局状态，虽然可以存档，但它的强大之处在于提供实时性能指标。整体的实时视图可以跟踪系统实体并进行管理更改，是系统管理的关键组成部分。

进行监控需要解决两个关键问题：系统中哪些元素构成系统状态，以及可以使用哪些指标。可能的响应粒度差异很大，监控可以低至指令级别，但这样会带来很大的开销且收益甚微。需要捕获更高级别的方面，但也不能过于宽泛。被监控的实体可以是系统中隐式的，例如服务请求的上下文。指标通常基于系统中对象的数量和类型来确定，但也可以使用许多其他有趣的指标。不同的系统将从不同形式的监控中受益。

以下是监控的几个方面：
- 进程 ：运行系统最明显的指标之一是正在运行的进程数量。在面向对象编程中，跟踪和管理进程的方法有很多，其中一种著名的方法是通过SNMP（简单网络管理协议）。许多ORB供应商仍然提供专有的产品来跟踪和管理进程，通常是按服务级别进行，并且几乎总是与他们的专有对象定位（命名）服务相关联。例如，对象激活守护进程（OAD）会在数据存储中保存服务名称到可执行文件及其命令行参数的映射。当对象定位服务收到服务请求时，会询问OAD该服务的进程是否正在运行，如果没有运行则启动该进程。然而，这些服务通常缺乏联邦化，许多情况下仍需要自行开发解决方案。
- 服务和对象 ：OAD可用于监控服务的存在，但在处理服务和对象的复杂性时，标准的OAD存在不足，例如对服务属性和重新初始化策略的支持不足，并且只能在客户端请求时采取行动，且行动范围局限于单个机器。因此，可能需要自行开发解决方案。服务本身可以分布在多个位置，在使用中央监控器跟踪服务活动时，服务注册时需要提供自身信息。为了解决监控对象时的表示和规模问题，可以在服务内部集中管理表示，创建类似外观的结构。例如，对于为每个用户会话生成新对象的服务，可以让工厂实体支持监控，这样监控器只需与工厂/管理实体通信，即可获取服务内部跟踪的信息。
- 用户 ：捕获特定用户与系统的交互是常见的设计目标。可以通过跟踪为用户分配的对象来实现这一点。如果使用允许用户身份委托的安全服务，要求所有服务都需要安全上下文，就可以访问用户信息。为了避免让服务开发人员处理记录用户请求的问题，可以使用ORB供应商提供的拦截器。在多线程环境中，为了解决用户同时发出多个请求时的跟踪问题，需要设置标签机制。

下面用mermaid流程图展示系统跟踪机制：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([系统跟踪机制]):::startend --> B(日志记录):::process
    A --> C(监控):::process
    A --> D(审计):::process
    B --> B1(捕获运行时数据和控制流信息):::process
    B --> B2(存档):::process
    B --> B3(关注单个服务):::process
    C --> C1(捕获系统全局状态):::process
    C --> C2(提供实时性能指标):::process
    C --> C3(进行系统管理):::process
    D --> D1(记录业务相关信息):::process

4. 审计

审计是对纯粹业务相关信息的捕获。存档的信息高度专业化，通常是业务特定的。它与日志记录和监控不同，专注于业务层面的数据，为企业的业务决策和合规性检查提供重要依据。例如，在金融系统中，审计可以记录每一笔交易的详细信息，包括交易金额、交易时间、交易双方等，以便进行财务审查和风险评估。

综上所述，在分布式系统的部署和管理中，CORBA与互联网的融合以及系统的各种特性和跟踪机制都起着至关重要的作用。通过合理设计和实现这些方面，可以提高系统的可靠性、可维护性和性能，满足不断变化的业务需求。

CORBA与互联网应用架构部署全解析（续）

5. 审计的重要性及实施要点

审计在分布式系统中扮演着不可或缺的角色，它聚焦于业务层面的数据，为企业的运营和管理提供了关键支持。
- 业务决策依据 ：审计所记录的信息能够反映业务的实际运行情况，帮助企业管理层了解业务的优势和不足，从而做出更明智的决策。例如，通过分析销售数据的审计记录，企业可以发现哪些产品畅销，哪些地区的市场潜力较大，进而调整生产和营销策略。
- 合规性检查 ：在许多行业中，企业需要遵守各种法规和标准。审计可以确保企业的业务操作符合这些要求，避免因违规而面临的法律风险。例如，金融机构需要遵守严格的监管规定，审计可以帮助它们检查交易是否合规，是否存在洗钱等违法行为。

为了有效地实施审计，需要注意以下几点：
- 明确审计目标 ：在进行审计之前，需要明确审计的目标和范围，确定要记录哪些业务信息。例如，如果是对财务系统进行审计，需要记录每一笔交易的详细信息；如果是对人力资源系统进行审计，需要记录员工的入职、离职、晋升等信息。
- 选择合适的审计工具 ：可以使用专门的审计软件来记录和分析业务信息。这些工具通常具有强大的功能，能够自动收集、整理和分析数据，提高审计的效率和准确性。
- 定期进行审计 ：审计不是一次性的工作，需要定期进行，以确保业务信息的准确性和完整性。定期审计还可以及时发现潜在的问题，并采取相应的措施加以解决。

6. 分布式系统部署特性的综合考量

分布式系统的各个部署特性之间相互关联、相互影响，需要综合考量，以实现系统的最佳性能和可靠性。
- 稳定性与服务连续性的关系 ：系统的稳定性是服务连续性的基础。只有系统稳定，才能在故障和升级时保证服务的连续性。例如，如果系统的某个部分不稳定，经常出现故障，那么在故障发生时，服务的连续性就很难保证。
- 优化与可跟踪性的协同作用 ：优化可以提高系统的性能，而可跟踪性可以帮助我们了解系统的运行情况，发现性能瓶颈。通过跟踪系统的性能指标，我们可以找出哪些部分需要优化，从而采取相应的措施提高系统的整体性能。例如，如果发现某个服务的响应时间过长，通过跟踪可以找出是哪个环节导致的问题，然后进行优化。
- 故障严重程度感知与人工干预的时机 ：系统对故障严重程度的感知能力决定了何时需要人工干预。当系统遇到无法自行处理的大问题时，及时暂停服务并寻求人工干预可以避免问题进一步恶化。例如，在数据库出现严重故障时，系统能够及时感知并暂停服务，通知管理员进行修复，避免数据丢失和业务中断。

下面用表格展示分布式系统部署特性之间的关系：
|特性|与其他特性的关系|
|----|----|
|稳定性|是故障时和升级时服务连续性的基础，影响系统整体可靠性|
|故障时的服务连续性|依赖于系统的稳定性，与优化和可跟踪性共同保障业务正常运行|
|升级时的服务连续性|需要系统稳定，与优化和可跟踪性协同确保升级过程中服务不受影响|
|故障严重程度的感知|为人工干预提供依据，与稳定性、服务连续性相关，影响系统的恢复能力|
|实现透明性|有助于提高系统的可维护性，与优化和可跟踪性共同提升系统的整体性能|
|优化|与可跟踪性协同，提高系统性能，保障服务连续性，减轻系统压力|
|可跟踪性|为其他特性的实现提供数据支持，帮助发现问题并进行优化，保障系统的可靠性|

7. 跟踪机制的实际应用案例

以下是几个跟踪机制在实际系统中的应用案例，展示了它们在解决实际问题中的作用。

7.1 日志记录在电商系统中的应用

在电商系统中，日志记录可以帮助我们了解用户的行为和系统的运行情况。例如，通过记录用户的浏览记录、购买记录等信息，我们可以分析用户的偏好和消费习惯，为用户提供个性化的推荐服务。同时，日志记录还可以帮助我们发现系统中的问题，如服务器故障、数据库错误等。

假设一个电商系统使用了前面提到的标准日志记录类进行日志记录。当用户登录系统时，会生成如下的日志记录：

<L0GMSG>
    <DateTime date="2/1/2024" time="10:30:00 am"/>
    <Service name="userservice" host="host1" pid="222" />
    <Priority level="2"/>
    <Thread name="loginthread"/>
    <Object class="com.ecommerce.User">user123</Object>
    <Type> <tag name="LOGIN"/> <tag name="User"/> </Type>
    <MSG> User user123 logged in </MSG>
</L0GMSG>

通过分析这些日志记录，我们可以统计每天的登录用户数量，了解用户的登录时间分布，还可以发现是否存在异常的登录行为，如多次登录失败等。

7.2 监控在云计算系统中的应用

在云计算系统中，监控可以帮助我们实时了解系统的性能和资源使用情况。例如，通过监控服务器的CPU使用率、内存使用率、网络带宽等指标，我们可以及时发现系统的性能瓶颈，并采取相应的措施进行优化。

假设一个云计算系统使用了SNMP协议和ORB供应商提供的专有监控工具进行监控。当服务器的CPU使用率超过80%时，监控系统会发出警报，通知管理员进行处理。同时，监控系统还可以记录服务器的性能指标历史数据，帮助管理员分析系统的性能趋势。

下面用mermaid流程图展示监控在云计算系统中的应用流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([云计算系统监控]):::startend --> B(收集服务器性能指标):::process
    B --> C{CPU使用率是否超过80%?}:::decision
    C -->|是| D(发出警报):::process
    C -->|否| E(继续监控):::process
    D --> F(管理员处理):::process
    F --> E

8. 总结与展望

在分布式系统的部署和管理中，CORBA与互联网的融合为我们带来了新的机遇和挑战。通过具备稳定性、服务连续性、优化、可跟踪性等必要特性，以及采用日志记录、监控、审计等跟踪机制，我们可以提高系统的可靠性、可维护性和性能，满足不断变化的业务需求。

未来，随着技术的不断发展，分布式系统将会变得更加复杂和庞大。我们需要不断探索新的技术和方法，进一步完善分布式系统的部署和管理。例如，随着人工智能和机器学习的发展，我们可以利用这些技术来实现自动化的故障诊断和修复，提高系统的自愈能力；随着区块链技术的应用，我们可以提高系统的安全性和可信性。总之，分布式系统的发展前景广阔，我们需要不断努力，以适应未来的挑战。