POSA2 第一章 并发网络对象（概述与1.1动机）

概述

 

本章介绍了并发和网络对象相关的话题。我们首先讨论一下需要在这方面使用高级软件开发技术的动机。接下来，我们看一下开发并发网络对象应用程序和中间件的开发者所面临的设计难题。为了演示怎样应用模式解决这些问题，我们用一个面向对象的框架和一个使用了该框架的高性能Web Server作为学习案例。在案例学习中，我们将精力集中在本书所描述的在以下四个方面能够帮助简化并发网络程序的模式上：

l        服务访问和配置

l        事件处理

l        同步

l        并发

1.1 动机

在过去的十年里，VLSI（译注：超大规模集成电路）技术和光纤技术发展使计算机的处理能力增加了3到4个数量级，网络速度增加了6到7个数量级。如果按照这个趋势，再过十年：

l        桌面计算机的时钟速度会达到10G赫兹

l        局域网速度会达到100G/s

l        无线网速度会达到100M/s

l        Internet主干网速度会达到10T/s

而且，全世界会有数十亿的交互式和嵌入式计算和通信设备在运转。这些功能强大的各种价位的计算机和网络，通常由健壮、公共的现成组件组成，并通过不断增加的汇聚再蔓延的Internet基础设施进行交互。

为了最大限度的从这些硬件技术的发展中获益，开发并发网络的中间件及应用软件的技术也必须提高质量和生产力。从历史的观点看，硬件正趋于更小，更快，更可靠。根据摩尔定律，很明显也会越来越廉价，并会可预测的发展。相反，并发网络软件却常常变得更庞大，更缓慢并且更容易出错。而且开发，验证，维护，增强也更昂贵，更费时间。

尽管硬件的发展缓解了一些底层软件优化的需要，开发软件（特别是关键的并发网络应用程序）所需要的生命周期成本[Boe81]和努力仍在持续增长。硬件的快速发展和软件缓慢的进度之间的不同来自于很多方面，包括：

l        软件固有的（inherent）和随机的（accidental）复杂性。固有的和随机的复杂性导致了并发网络软件中令人厌烦的问题。软件固有的问题起因于基础领域内的挑战，如处理部分失败（partial failures），分布式死锁（distributed deadlock），和端到端（end-to-end）服务质量（Qos）需求等。随着网络系统在规模和功能上的增长，他们现在必须应付更多更难的复杂性。

随机的复杂性来自于软件工具和开发技术的限制，例如不方便的编程接口和稀缺的分布式调试器。有讽刺意味的是，很多随机的复杂性来自于偏爱那些对并发和网络开发没有什么帮助的低级语言和工具的开发者做出的慎重的选择。

l        不足的方法和技术。流行的软件分析方法[SM88][CY91][RBPEL91]和设计技术将精力集中在构建单进程，单线程，在QoS需求方面只是“尽力而为”的应用程序上。高质量并发网络系统，特别是那些像视频会议这样有严格QoS需求的系统的开发被留给那些熟练的架构师和工程师靠他们的直觉和专长完成。而且，如果不花费相当多的时间通过不断实验，犯错，对各种平台相关的细节苦思冥想来学习，很难获得并发网络软件技术的经验。

l        不断重新发明和重新发现核心的概念和技术。软件行业有很长的为已经解决的问题重新创建不兼容解决方案的历史。例如，有数十种管理同样硬件资源的非标准的通用实时操作系统。类似的，有数十种不兼容的操作系统封装类库，它们提供只有细微不同的API，实现基本上完全相同特性的服务。如果这些努力集中在增强和优化少量方案的话，并发软件开发者会和硬件开发者一样受益。通过使用公共的CAD工具和标准指令集，总线和网络协议快速的开发。

没有唯一的银弹可以杀死所有烦扰并发网络软件开发的恶魔。然而经过过去的十年，模式和模式语言很明显能够帮助减轻很多固有的和随机的软件复杂性。

模式是在某个特定的环境下解决标准问题时可以重用的解决方案[POSA1]。模式帮助捕捉和重用软件设计的关键参与者（类和对象）的静态和动态结构（类图对象图等）以及它们的合作方式（协作图）。它们对记录可重用小型架构很有用，这些小型架构是有经验的开发者用来解决普通设计和实现问题的软件组件的描述[GoF95]。

当相关的模式交织在一起，它们形成了一种“语言”，这种语言既能够

l        为谈论软件开发问题定义一个词汇表[SFJ96]，也能

l        为这些问题[Ale79][AIS77]的有序解决提供一个过程。

通过学习和应用模式和模式语言，开发者通常能够避免陷阱和缺陷，而这些缺陷据说只有经过长时间的昂贵的学徒生涯才能避免[PLoPD1]。

直到最近[Lea99a]为止，开发并发网络软件的模式只存在于编程的传说中，专业研究者的大脑里，或者深深埋藏在复杂的源码里。这些地方都不理想，主要是三个原因：

l        从源码中重新发现模式很昂贵，并且很费时间，因为很难从实现细节中分离出核心的设计决策。

l        如果经验丰富的设计者的见解和理论没有被记录，它们在经过一段时间后就会被遗忘，因此就不能给接下来的软件维护和增强活动提供指导和帮助。

l        没有前期工作的指导，并发和网络软件开发者将面临从头构建复杂系统的庞大任务[SeSch70]，而不是复用经过证实的解决方案。

这些导致了很多并发网络软件系统从头开始开发。而在今天充满竞争的，市场驱动的环境下，这经常产生出不理想的“特殊”的解决方案。这些方案很难定制和调整，因为所有大量的努力都只为了使软件能够运作。而且，随着时间的推移需求发生变化时，发展“特殊”软件方案的费用会高的惊人。然而，最终用户认为，或者至少希望软件被支付得起，健壮，高效并且快速，而这些如果没有坚实的架构支撑是很难达成的。

为了帮助解决这些问题，本书记录了并发网络软件的关键架构和设计模式。这些模式可以并且已经用来解决很多开发面向对象中间件框架和应用程序时的常见问题。当作为文档的辅助时，这些模式保留了重要的设计信息，这些信息能够帮助开发者更健壮的发展现有软件。当作为设计的辅助时，这些模式帮助引导开发者更高效的创建新的软件。

当然，模式，对象，组件和框架都不是万能药。它们不能将开发者从解决所有并发网络软件的分析，设计，实现，确认和优化问题的职责中解脱出来。最终，没有什么能够替代人的创造力，经验，纪律，勤奋和判断。

然而，如果使用得当，本书所描述的模式能够减少很多前边列出的复杂性。特别是，这些模式

l        指引开发者将注意力集中在上层的软件应用程序架构和设计关注问题上，如适当的服务访问配置的规格说明，事件处理和线程模型等。这些是并发网络软件的一些关键策略问题。如果它们被恰当处理，很多令人烦恼的复杂性的影响会在很大程度上被减弱。

将开发者的注意力从底层操作系统，网络相关协议和底层工作机制上移开。然而对这些话题有一个牢固的掌握是很重要的，它们要在一定的范围内使用，并且必须从整个软件架构和开发出发，放在在合适的环境中。