网络的全新角色 -

2006年6月30日
第4卷，第4期

网络的全新角色

面向应用的网络可以帮助弥合企业之间的差距。

TAF ANTHIAS 和 KRISHNA SANKAR，思科系统

公司一直面临着跨组织边界集成系统的挑战。随着互联网原生系统的出现，这种集成对于现代组织而言变得至关重要，但也变得越来越复杂，尤其是当下一代业务系统依赖于敏捷、灵活、可互操作、可靠和安全的跨企业系统时。

本文描述了跨企业领域中各种严苛的场景，并为应对这些挑战提供了视角。我们审视了跨企业系统的轨迹和 locus，现在解决各种复杂性的多种方式，以及未来如何简化它们。正是在这种背景下，网络作为一种替代方案出现，充当联合业务服务跨企业集成的中介，并具有面向应用的特性。

面向应用——网络的全新角色

面向服务的应用网络的需求和要求正在改变网络的设计、部署和运营。一些面向服务的应用的交叉需求最好放在网络中。这些需求包括服务虚拟化、基于消息语义的路由、策略中介和安全性。

AON（面向应用的网络）在其基本形式中，可以是网络设备（如路由器或交换机）中的一个刀片，也可以是充当网络或服务器场前端的专用设备。AON 设备的两个主要功能是通用应用功能（如 XML 处理、转换和数字签名验证）的加速，以及控制路径功能（如策略中介、路由和服务虚拟化）。

AON 利用其战术足迹，同时保持网络结构无处不在和普遍存在的特性。图 1 显示了 AON 的概念模型。

纯粹的传输网络是充当数据包搬运工的比特管道，而 AON 不仅理解网络的语法，还通过跨越较低的应用层和较高的网络层来理解应用的语义。图 2 显示了面向应用的网络的功能范围。在这种背景下，网络扮演着集成服务中介（透明与否）的角色，充当协议转换器、策略调解器、解析器和安全设备。从概念上讲，在这个作为应用感知网络的新角色中，中介有助于将领域复杂性与偶然复杂性分开——应用层实现领域复杂性，而网络处理将它们连接在一起并提供灵活耦合所产生的复杂性——在真实和虚拟意义上都是如此。

AON 的另一个方面是其作为正交可扩展平台的角色。AON 平台通过 bladelet（即应用于消息或消息组的逻辑集合）、信息模型和类似机制来促进高级可编程性。

基于 AON 的服务虚拟化

为了理解 AON 世界中的编排、拓扑和事件序列，让我们看看服务虚拟化以及基于 AON 基础架构实现这种范例的挑战。

虚拟化在不同级别完成，即服务器虚拟化（诸如 InfiniBand 和 VFrame 之类的机制）、进程虚拟化（通过虚拟机监控器和 Xen）以及容器虚拟化（通过应用服务器）。AON 将服务虚拟化层添加到此组合中。服务虚拟化是敏捷、灵活、可扩展的跨组织服务结构的关键。

为了更快地扩展跨企业系统，企业需要敏捷性、弹性、响应能力和灵活性。这使得将业务和基础设施策略与编程分离非常重要。业务策略不应硬编码；跨领域的业务能力需要与编程分离。另一个业务目标是通过开发可以在不同场景中动态部署的可重用服务来降低 TCO（总拥有成本）。

例如，在零售组织中，一个需求可能是在营业时间内提供更多的 POS（销售点）服务，而在非营业时间提供更多的后端数据传输服务。一家中型商店在一天中的不同时间总共需要 30 个 POS 服务和 30 个后端服务。如果没有虚拟化和动态路由，我们将需要 90 个服务的静态容量：（30+30）* 1.5。但我们并非在所有时间都需要所有服务（即，不需要 30 个 POS 服务和 30 个后端服务永久运行）。实际上，在营业时间内只需要 30 个 POS + 5 个后端服务，而在非营业时间需要 2 个 POS + 30 个后端服务。当您可以使用基于应用感知网络机制的服务虚拟化来规划 45 个服务时，为什么要规划 90 个服务？服务虚拟化功能将基于各种策略启动、停止并在所需服务之间路由。请注意，此问题是可扩展性问题，而不是并行性问题。我们可以使用相同的技术来解决需要并行计算的并发问题。

另一个例子是业务 SLA（服务级别协议）；一个组织将拥有不同级别的合作伙伴（如金牌、银牌和普通），其中高等级合作伙伴（金牌）将具有更高的响应时间级别。在这种情况下，我们需要一个虚拟化层，它不仅可以区分服务，还可以监控不同等级的响应时间，并根据业务级别的服务区分策略进行路由。在一个季度的末尾，一家公司可能会实施一项服务区分器，优先考虑金牌合作伙伴而不是银牌合作伙伴。通过监控流量，网络中介可能会决定添加更多服务以满足组织与其金牌合作伙伴的 SLA。

在拓扑结构上，一组 AON 设备将放置在客户端（服务请求者）侧、网络云中或服务器（服务提供商）侧。为简单起见，我们假设服务由 WSDL 定义，并使用 SOAP/HTTP 作为传输。首先，策略将被配置到 AON 刀片中，这将说明当它遇到特定消息时该怎么做。AON 将监控消息流量，当它“看到”它感兴趣的消息时，它会激活逻辑。一种逻辑是基于网络原语（我们这次不会深入探讨）监控响应时间（客户端到服务器和返回），并将它们存储在 DNS 中。另一种逻辑是与其他虚拟化层（如服务器、进程和容器）接口，并记录特定服务何时启动和停止。第三种逻辑是通过与服务器/进程/容器软件交互来主动启动或停止服务。

有了这些原语，AON 可以在多个同构服务之间进行负载均衡，在异构服务之间路由，并通过策略中介和动态端点解析来监控业务 SLA。

通过网络实现服务虚拟化（相对于服务器、进程或容器虚拟化）的一个挑战是设计时间/配置时间/运行时划分（即，谁在何时以及如何做）。服务在应用服务器中设计和托管；应用服务器定义策略，但网络在运行时成为中介，通过管理路由、虚拟化（传输、服务器、服务和端点）以及其他相关功能来执行策略。

在设计时，开发人员和架构师致力于虚拟化传输上的抽象服务（即，传输不可知且位置无关）。在配置时，应用和网络管理员配置虚拟化层（服务器、进程、容器）和策略。最后，在运行时，AON 动态解析端点引用，为虚拟化服务部署和调用以及服务之间的优化路由提供机制，从而实现敏捷性、响应能力和降低的运营费用。当业务扩展并需要更多服务时，基础设施可以扩展。然后，网络将在更多服务之间路由。事实上，我们将从“脆弱的确定性硬编码”应用基础设施转变为“弹性灵活”的服务基础设施。

我们可以进一步推广这种架构，传输协议可以根据策略动态更改，但这不会导致任何开发更改。从这个意义上讲，我们通过添加网络中介将领域复杂性与偶然复杂性分开了。

另一个挑战是中介的透明性。实现此目的的一种方法是从编程中隐藏网络中介，并让 WDSL 定义普通端点——例如，www.url1.com/service-x。然后在 AON 设备中，我们可以配置一个策略，该策略说：“当您看到 www.url1.com/service-x 时，运行逻辑集，应用虚拟化策略，并相应地路由。”另一种方法是要求开发人员将端点编写为 www.url-of-AON-blade.com/service-x，然后应用虚拟化和策略逻辑。

第三个挑战是端到端安全性的使用，尤其是 SSL，它将加密流量，因此 AON 将无法解密。在这种情况下，您需要添加安全中介和作为可信安全中介的 AON。

跨企业集成格局

现在让我们看看我们在跨企业格局中可能遇到的一些场景。我们还将看看当前处理这些场景的方法，并讨论一些简化方案。更重要的是，我们将指出使用网络的棘手和具有挑战性的地方——务实实施的痛苦和欣喜——基于我们与客户的经验。

法律和内部公司要求需要统一的策略中介。 组织要求统一应用业务策略，而与技术平台和应用领域无关。（例如，可能有一项策略规定，对于前往俄罗斯的国际银行交易，加密类型应更改为 GOST，这是俄罗斯银行使用的；对于前往韩国的国际银行交易，加密应为 SEED。）统一的动态策略评估和执行是一项重要的业务级别功能。该要求不仅源于法律环境，还源于时间和空间的业务能力。此外，普遍的策略执行可以根据领域采取不同的形式，例如企业对企业、分支机构对总部、DMZ、企业内部和服务提供商。

目前存在多个策略评估和执行点，它们之间的协调很困难。为了统一实施此策略，要么必须将所有应用设计为理解策略，要么网络必须成为评估和执行策略的中介。从可扩展性、灵活性和可用性的角度来看，网络中介是一个不错的选择。由于网络的普遍性，在“云”中的中心策略中介可以实现所需的统一性、治理和可见性。

AON 可以“知道”消息中的内容，也可以通过多种方式“学习”应用协议。AON 将监视所有数据包——以内联或离线模式。在 XML 世界中，感兴趣的元素将在 bladelet 中定义，当 AON 识别出这些元素时，它将执行所需的操作——可能是转换实际消息或引发事件或路由消息，具体取决于策略。AON 还具有各种应用级协议的适配器。

传输和交互模式的多样性。 另一种场景发生在组织拥有多种传输机制以及相关的 SLA 和要求时。在大多数情况下，将根据消息、源、目标、系统负载以及许多其他因素（例如，内部使用 Tibco，但外部使用 HTTP）选择传输。在这种情况下，基于网络的多协议应用路由器可以充当传输网关或服务虚拟化机制。

此示例类似于服务虚拟化示例。基于 SLA 的路由策略选择不同的传输，并可能根据实际 SLA 的衰减启动新服务，但传输也将成为决定选择哪些服务器以及在何处启动它们的属性。

传输的下一层是交互模式——常见的模式是同步或异步或发布-订阅。开发复杂的跨企业系统的一个影响是，通常会混合使用同步和异步服务；有时服务也具有长期事务。

在这种情况下，不同的功能需要在应用层和网络层之间分配。棘手的是找到应用和网络之间的正确划分以及正确的功能集。一个重要的指导原则是，任何事务状态（尤其是长期事务状态）都应由应用层的应用负责。嵌入在应用感知网络中的将是基于内容的路由和上下文跟踪。例如，各种 XML 文档（如 PO 编号、工单 ID 甚至事务编号）中的嵌入式 ID 可用于路由消息。

数千种服务的可扩展性和性能。 随着跨企业服务的使用成倍增加，并且组织拥有许多服务和服务消费者，主要的挑战是可扩展性和性能。这可能需要硬件加速和性能卸载到面向应用的网络。AON 设备通过多种方式提高性能：通过硬件加速、使用网络处理器以及使用并行性和分布式。很多时候，即使对一组数据包执行多个操作，性能也是 O(1)。

在这种情况下，挑战是将通用计算和网络操作分开，并找到嵌入在 AON 中的正确组合。

通用功能和专用功能都有其位置。然而，性能加速来自激光聚焦（即，仅执行一些常见操作并将其做得非常好）。在网络中嵌入通用功能并期望性能提高是不可行的。正如我们之前看到的，一个主要的挑战是纯粹的应用和面向应用的网络之间的划分。找到足够多的通用功能以实现系统范围的优化仍然是一门艺术，而不是一门科学。在当前技术（硅、微码、网络处理器等）的水平上，网络中介可以提高性能的功能包括 XML 转换、XML 安全性和路由。

扩展服务的另一个挑战是将负载均衡和服务虚拟化等功能与业务需求和角色相匹配。即使这一点可能是显而易见的，但其基本原理可能并非如此。仅仅投入负载均衡或虚拟化并不能解决问题。

在客户端和服务器端实现负载均衡略有不同。在客户端，许多请求可能会被聚合、联合或联合，并发送到一个服务——更像是反向负载均衡。在服务器端，负载均衡有多种形式——通常的轮询类型或一些加权平均方案；还有端点虚拟化和自适应负载均衡（基于上下文和消息内容）。

互联网规模的系统遵循互联网规则。 当跨企业服务拥抱互联网并为互联网规模或接近互联网规模的范例架构时，它们也受互联网的三大规则约束

无标度网络原则（即，某些服务将比其他服务更受欢迎，并且服务的使用模式不遵循正态曲线）。
长尾消费原则（即，不使用传统应用的应用和用户将开始消费分布式服务）。
颠覆性技术规则（即，随着服务变得易于访问和精细，它们将变得更加普及，因此将被过度使用）。

二阶和三阶扩展复杂性（即，在 SOA 的多个属性方面进行扩展，增长率在设计时可能无法预测，尤其是在流行服务方面）需要具有服务虚拟化的分布式网络架构。

当无标度属性也是时间性的时，服务虚拟化（以及基于动态策略启动和停止服务的能力）是必需的。时间性无标度服务的示例包括身份验证/登录服务（在早上非常繁忙），以及在跨企业场景中，企业对企业系统中的订单录入服务（在一个季度末非常繁忙）。

对未来的思考和趋势

组织正在慢慢适应现代跨企业系统的现实，并正在寻找将网络的新角色融入其企业系统的方法。让我们看看将塑造面向应用的网络发展的趋势。

传感器网络导致非对称信息流。 行业最近的发展包括基于 RFID 和传感器网络的应用。这些应用导致来自边缘的非对称流量模式；在边缘生成的内容和服务会给传统的核心-分发-访问层带来变化。这种难以处理的扩展边缘可能是智能边缘（例如，传感器网络）或跨生态系统的服务消费者和生产者角色中的二分法的结果。例如，在 HR 应用中，需要向外部发出服务调用以进行安全检查并返回；信用卡验证中也存在类似的二分法。这种情况需要充当边缘智能聚合器的网络中介。

RFID 和类似应用需要复杂事件处理。 在许多领域（如物流）中，需要识别和响应事件，这需要零延迟或接近零延迟的组织。事实上，这些事件中的大多数都将发生在组织外部——典型的跨企业事件流场景。

EPC（电子产品代码）全球网络是该领域的一个极佳示例。诸如 RFID 之类的新技术需要以下功能

跨不同组织（例如，宝洁和沃尔玛之间或强生和沃尔格林之间）的跟踪和追溯
跨多个站点的货物方向和速度
容器层次结构，其中包裹或容器与其内部的货物之间存在关系
存在和位置，这是跨组织的正常资产跟踪

在这些云用例中，事件发生在多个组织中，并且发生在不同的时间和频率。人们不可能期望数百台专用应用服务器。这种情况适用于可以执行复杂事件处理（即，非线性事件传播）和网络到应用事件关联的应用网络基础架构。

目前，此类用例并不常见，但企业已经实施了孤立的 Web 服务，并且正在朝着组织内部及其合作伙伴生态系统中的联合 SOA 模型发展。

网络集成需要在网络层中提供适当的接口。 大多数网络协议都设计为在一个层中工作（这是专业化的副作用），并且没有提供足够的接口来充分利用应用。为了从应用的角度充分利用网络，我们需要新的协议。

一个这样的例子是 SCTP（流控制传输协议），它是一种比 TCP 更新的协议。TCP 作为数据包搬运协议非常出色，但对于需要应用传输语义的协议，SCTP 更好。SCTP 处理消息流而不是数据包；它可以携带多个流，而 TCP 仅携带一个流；SCTP 可以多宿主，因此比 TCP 提供更多的弹性。此外，SCTP 具有 TCP 中不可用的控制通道。这个例子说明了 AON 需要与纯粹的面向数据包的网络有何不同。另请记住，SCTP 在 IP 上工作（如 TCP）——因此我们仍然需要硬金属线速数据包搬运能力，但我们还需要网络协议中面向应用的语义。

AON 结构对拓扑结构、各种可用的最佳路径、拥塞和其他因素具有足够的可见性，同时对网络工件（如 QoS 位）和路由协议（如 OSPF（开放最短路径优先）和 BGP（边界网关协议））施加足够的控制。AON 可以调整足够的位来与网络以及应用实现协同作用。我们一直在努力在面向应用的世界中利用网络协议，但那是另一个讨论的主题。

面向应用的网络的概念将利用企业以外的领域。 本文的大部分内容都集中在企业领域，但其他领域和问题类别将通过相同的跨企业模式来解决。例如，我们正在努力将这些模式和想法应用于非事务性 Web，例如网络娱乐和移动自组网。

在网络娱乐领域，内容分发、内容移动性、消除中介、“转录”（即，转码和加密）和其他类似功能存在机会。在家庭网络中，用户希望获得透明的体验和“只需工作的东西”——这与企业系统用户的期望没有什么不同。

移动自组网涉及巨大的挑战，我们在跨企业领域中使用的范例也可以应用于此处。例如，在移动环境中管理 VoIP 目录需要服务、接口、虚拟化、统一策略和安全性。

结论

开发和维护跨企业系统带来了许多挑战，但在应用层和网络层都有简化的机会，以实现业务所需的可互操作性、可扩展性、可用性和安全性。面向应用的网络利用网络的定位和操作特性，同时将选定的应用原语嵌入到网络中。当然，也存在局限性。并非所有功能都可以并且应该迁移到网络。从这个意义上讲，应用层和网络层的各种机制之间存在微妙的平衡。

建议进一步阅读

Bosworth, A. mySQL 会议； http://www.itconversations.com/shows/detail571.html。

http://oakleafblog.blogspot.com/2005/11/adam-bosworth-learning-from-web-and.html.

http://weblog.infoworld.com/udell/2003/04/01.html.

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

http://www.adaptivepath.com/publications/essays/archives/000547.php.

致谢

我们要感谢 John McDowall、Dan Kearns 和 Sunil Potti 的想法、概念和见解；以及 Peter Linkin、Neal Novotny 和 Karen Brighton 尽管日程繁忙，仍抽出时间审查和编辑本文。非常感谢 Nancy Darma 促成了快速周转。

TAF ANTHIAS 是思科系统公司面向应用的网络副总裁兼总经理。他是消息传递和集成中间件领域公认的行业领导者。他曾在 IBM 担任关键技术职位，并帮助塑造了多项软件技术，包括消息传递、事务处理、分布式系统、图形子系统和编程语言。Anthias 在消息传递、集群、对象模型、显示处理器和窗口系统中拥有多项专利。他毕业于英国剑桥大学，获得数学学位。

KRISHNA SANKAR 是思科系统公司的杰出工程师。他的经验涵盖从软件架构和开发到工业工程。他是一位作家、演讲者、企业家和技术传播者。他曾参与多个标准组织，包括 W3C、OASIS、JCP 执行委员会、WS-I、ZigBee 和欧盟的安全机构。

网络结构集成的原则

将网络用作跨企业集成器、中介和面向应用的网络既有优点也有缺点。在网络层中嵌入应用原语既有逻辑和理由支持，也有反对。

首要原则是：“不要仅仅为了做而做。”您不应仅仅因为可以做到就嵌入原语——不加区分地嵌入原语需要在上层中添加更多逻辑。路由、XML 加速和安全性等功能适合作为网络中介，但事务或服务容器不适合网络。
尽可能在最低层嵌入功能，不要更低或更高；更低会错过上下文和总体目标，更高则需要补偿在所需粒度上缺乏可见性和控制。
附加服务不应同时需要对网络堆栈、新的基础设施和应用进行更改。这个主题源于 IETF（互联网工程任务组）小组之一的讨论——“叉车式”升级已经过时，增量扩展正在兴起。
当对功能适合的位置有疑问时，请从互操作性、可扩展性、性能和可用性方面考虑。
网络的功能应提供正交可扩展平台和网络中有限不确定性的原则。网络基础设施必须支持任意行为，同时提供协调一致的结果。可扩展性的另一个原因是部署环境差异很大，我们需要允许变化的，从而在压力下弯曲并生存的设计。作为平台的网络应分离出随着时间推移会发生变化并需要改进的接口。
网络平台应模块化并提供在具有冲突利益的子系统之间的隔离。
寻求跨领域的协同作用，并利用已完成的工作。工作应基于扩展开放标准——为了互操作性以及利用来自知识渊博的来源的工作和进行协作。
嵌入在网络中的任何功能都应不仅提高可扩展性和可用性，还应提高流量结构——即，传输不可知性和位置独立性。该指令特定于服务-
面向架构的领域。
传统的企业和企业内部系统是重量级平台，而 Web 2.0 范例开创了一个允许松耦合系统的轻量级编程模型的时代。来自亚马逊、谷歌和 eBay 的 Web 服务平台基于轻量级业务模型，这些模型需要一个促进通过轻量级连接进行轻量级编程的平台。
在 Web 2.0 世界中，联合（和联盟）比协调更常见。
即使我们可能不这样认为，我们也确实需要为“可破解性”和“可混搭性”而设计。
最终的网络化平台将支持“草率可扩展”的格式、软件的社会维度、简单性，以及最重要的是松耦合。这将成为 Web 2.0，甚至可能是 Web 3.0。

通过应用这些原则，应用层和网络层之间的划分对于从业者来说变得更加清晰明了。虽然策略中介和执行、安全性、路由和服务虚拟化等功能迁移到网络，但策略定义、业务流程编排和事务状态等功能在应用服务器上变得至关重要。

即使我们在此处专注于跨企业集成，相同的原则也同样适用于内部集成。事实上，大多数组织都有需要跨集成的系统孤岛——跨企业集成原则非常适合此处。

最初发表于 Queue 第 4 卷，第 4 期—
在数字图书馆中评论本文

更多相关文章

David Collier-Brown - 你根本不懂带宽
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有大约 50 到 100 Mbps 的带宽，问题就是延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是 ISP 并且所有客户都讨厌您，请鼓起勇气。这现在是一个可以解决的问题，这要归功于一群敬业的人，他们找到了它，消灭了它，然后在家庭路由器中验证了他们的解决方案。

Geoffrey H. Cooper - 使用 FDO 和不受信任的安装程序模型的设备入网
设备的自动入网是处理日益增多的“边缘”和物联网设备安装的一种重要技术。设备的入网与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入网加速这一过程，供应链中的信任关系必须在设备中正式化，以允许自动化过渡。

Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 分布式延迟分析：通过关键路径追踪
低延迟是许多 Google 应用程序（如搜索）的重要特性，延迟分析工具在维持大规模低延迟方面起着关键作用。对于包含功能和数据不断演变的服务的复杂分布式系统，将整体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中，现有的工具（如 RPC 遥测、CPU 性能分析和分布式追踪）对于理解整个系统的子组件很有价值，但不足以在实践中执行端到端延迟分析。

David Crawshaw - VPN 一切焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也随之增长和变化。在 2000 年代的互联网中，VPN 经历了一个尴尬的青春期，与其他广受欢迎的抽象概念互动不佳。在过去的十年中，互联网再次发生了变化，这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新的 VPN 提供了技术基础。