软件管道规则
本文节选自《多核应用架构关键技术--软件管道与SOA》 第2章“管道定律”第2.6~2.9节
2.6 软件管道规则
让我们来看看软件管道的规则：
- 规则1：输入等于输出。
- 规则2：下游组件或处理过程的能力（处理事务速率）要等于或超过上游组件或过程的输入速率。如果不是这种情况，你就必须优化下游的组件或过程，或者使用管道分配器来支持并发处理与控制负载。
- 规则3：管道分配器的处理速率必须远远超过下游处理速率。
在接下来的章节中，我们会看到每个规则的细节之处，你会了解到一些用来分析软件管道系统的简单公式。
2.7 规则1
输入等于输出。
当然，上面是对管道定律自身的描述，你也可以将你从管道定律学来的所有知识设计软件管道系统。为了在你的设计中使用规则1，需要进行如下的操作：
- 确定输入事务的供应是充足的。这是使用软件管道之前首先需要调整的。
- 识别系统中哪个组件或过程的处理速率最慢，那么该组件/过程控制了这个系统的吞吐率与性能，所以你必须对它进行优化。
- 识别不能承担负载的外部系统或应用程序。这些系统/应用程序会成为瓶颈，正如你处理最慢的组件/过程那样，你需要对它们进行优化处理。
- 预测并去除系统中的任何瓶颈点。为了达到目标你需要做如下工作：找到你系统中的所有组件，分析它们的特点，一旦需要，就对它们进行优化。
规则1的公式是：
输入率（）= 输出率（）
不管你处理多少事务，输入率与输出率总是相同的。换句话说，软件管道系统或任何软件系统，不能接受超过它所能处理（）的事务（潜在的输出率），这可表达为：
可获得的输入率（）=潜在的输出率（）
例如，如果可获得的输入率是每秒10个事务（transactions per second，TPS），不管下游的处理速率有多快，它的处理能力不会超过10 TPS。
让我们来看看输出端。如果可获得的输入率是1 000 TPS或者更多，你可能很容易断定潜在的输出率也是1 000 TPS。然而，如果下游的处理能力仅仅为500 TPS怎么办？你是让它们排队等待，还是丢掉这500 TPS的处理能力，当然这种举措不理想。
下一节，我们将会展示如何使用软件管道规则2来解决由下游较慢的处理过程带来的潜在系统瓶颈问题。
2.8 规则2
任何下游组件或过程的能力（事务处理速率）必须大于或等于任何上游组件或过程的输入速率。如果不是这种情况，你必须优化下游组件或过程，或者使用软件管道分配器来支持并发处理并控制负载。
如果你要最大化系统性能或者不得不满足服务等级协议（service-level agreements，SLA）与商业需求，那么这个规则是你成功的关键。你可以使用它分析软件管道系统的每一点，来识别存在的或者潜在的系统瓶颈。你也可以使用它来决定你是否需要更多的处理能力，如果你确实需要，你也可以通过使用管道分配器来增加并发处理能力。
规则2的公式是：
输入率（）必须"输出率（）
换句话说，下游的任何组件或过程的处理速率必须能够适应任何上游组件或过程所提供事务的输入率。如果不是这种情况，你必须使用多个管道或其他的优化方法来增加处理速率。
考虑如图2.5所示的组件处理流程。
在这个示例中，步骤B是系统的瓶颈。当事务离开步骤A到达步骤B时，事务会发生排队与积压的情况。这会减少进入步骤C的事务流，导致步骤C并没有被充分利用。此外，如果到达步骤B，没有缓存保存排队等候的事务，你可能会失去这些事务——对于像银行业务这样关键的任务应用来说这是不可接受的。
为了均衡事务流，你必须增加步骤B的吞吐性能。你可以使用管道分配器或者其他优化方法。如果你不能解决上述问题，整个系统只能具有步骤B的处理能力——500 TPS。
图2.5 下游组件带来系统瓶颈
如果将步骤B进行分配是安全的，你可以简单地为它创建两个管道，使它的性能加倍，如图2.6所示，这将解决上述问题并可均衡事务流。
图2.6 使用管道来增加处理能力
如果你没有充足的硬件资源来处理增加的事务量，创建两个管道不会使得步骤B的处理能力加倍。为了实际解决这个问题，你可能不得不添加硬件。拥有两个管道与充足的硬件资源，你可以利用并发的处理能力来加倍步骤B的处理能力。
然而如果你想要一个真正有效的解决方案，这里缺少了关键的一个环节：管道分配器。在多个管道实施并发处理需要一种分配事务的方法。在软件管道架构中，管道分配器就是完成这个工作的组件，将事务分配到多个硬件系统中或分配到一个系统的多个处理器上。
如图2.7所示，管道分配器分配事务，对步骤B的负载进行均衡处理。图2.7也展示了增添的硬件资源。
图2.7 使用管道分配器与附加的硬件资源增加系统处理能力
你可以从第1章回忆起管道分配器分配输入的消息到各个管道的过程。为了确定将每个消息向何处发送，它将会检验消息的内容，然后向匹配的、可处理该事务的管道发送。这种方法分配了负载，使你更多地控制了事物流。此外，分配器支持一些如同FIFO次序或优先级等关键业务需求。
另一个使用管道分配器的优点是能够可伸缩性。你可以赋予每个管道一个指定的硬件资源；分配器分配事务到每个管道中，每个管道独立且并发地执行各自的事务。如果硬件不足，这个管道就会成为系统瓶颈，你可以为这个管道添加资源。因为管道之间完全独立，添加更多的硬件资源也给管道带来了线性或近线性的扩展能力。
再进一步考虑，若分配器负担过多的管道，最终管道分配器自身会成为系统瓶颈。下一节，我们将展示如何使用规则3来避免这个问题。
2.9 规则3
管道分配器的处理速率要远远超过下游处理速率。
为了有效地实现管道分配器，你必须关注规则3。分配工作总是给系统带来一定的负担，因此管道分配器执行工作要比实际处理情况快很多才行。
规则3的公式是：
分配速率（）＞＞处理速率（）
换句话说，分配速率一定要比下游的处理速率快很多。如果不是，管道分配器自身将成为系统瓶颈，它会让整个软件管道架构失去意义。
在图2.8中，管道分配器为了避免成为系统瓶颈，必须拥有至少2000 TPS的吞吐能力。如果它能处理2000 TPS并且供给四个500TPS的管道，这样系统会工作的很不错。
图2.8 负载均衡良好的系统不存在瓶颈
然而，如果分配器含有复杂的路由事务逻辑，仅仅能处理1000 TPS那将会发生什么？如图2.9所示，管道分配器成了系统瓶颈。如果这样的情况发生，实现管道没有任何的好处，管道分配器浪费了宝贵的资源。
图2.9 拥有负载逻辑的管道分配器会成为系统的瓶颈
如果你分配了太多的管道可能导致相反的问题。假设分配器可以处理2000 TPS，然而将步骤B的四个管道扩展为八个管道，如图2.10所示。
这种情况下，每个管道只能处理250 TPS，但是每个管道的处理能力是500 TPS。所以，这也是浪费了资源而且你没能对系统进行优化。
为了避免上述两种问题，使用下面的公式来决定对于系统中给定部分管道的最优化个数。
管道数量（）=分配器TPS/处理TPS（）
图2.10 过多的管道会浪费系统资源
是理论下游执行管道的最大数目。你也可以认为这是对特定的处理过程做进一步的划分。是分配速率（管道分配器的处理速率），是下游处理速率（分配器供给的下游管道和组件的TPS总和）。对于系统某部，的比率是有效管道的理想数值。
当然，真实系统可能会出现一定的错误，因此你应做出一定冗余量，将管道数量提高10%到20%，确保系统有容错能力和足够流量。采用这种方式管道数量公式对于你的系统采用合适的管道数量和如何进行优化有着指导意义。
让我们看一个具体的例子。如果一个管道分配器的处理速率是1000 TPS，下游管道的处理速率为100 TPS，那么最大的管道数量是10。
这个系统将会比没有软件管道的系统快10倍。特别的是，在给定的时间内，这个系统将处理10倍于原来的事务数量。
管道数量公式向你展示重要的一点：系统必须以下游管道处理事务的速率向下游管道提供事务。否则，管道就会成为一个简单等待的没有任何收益的资源。
因此，最坏的场景是如果分配器评估和分配一个事务的时间比管道执行该事务的时间还长，你就不能从并发处理过程得到一点点的好处。事实上，分配器为处理过程带来一定不必要的消耗。当设计一个软件管道应用时，你的目的是最小化分配器带来的延迟（增加分配速率）并且尽可能多地为下游管道分派工作。
附加的一点是：第1章中提到你可以创建多层分配器与管道，任何管道都可以向分配器发送事务，为了从软件管道架构获得更多的益处，应用规则3与管道数量公式对于你的整个系统来说都很重要。
本书作者：
Cory Isaacson是Prelude Innovations公司（一个特别关注先进软件技术产品孵化和推荐的公司）的CEO。他积极参与领导信息技术工作20多年。Cory担任WebSphere Advisor杂志的技术编辑与专栏作家，在数百场的公众活动和研讨会上发表演说，并撰写关于架构和实用性技术的大量文章。Cory为数百个顶级架构师和专业开发人员（他们负责商业服务、娱乐、电信与软件行业的强大商业应用的开发与实现）提供指导。
最近Cory担任Rogue Wave Software公司的总裁，3年来担任公司管理，建立新产品战略，并在2007年中期被一家私人控股公司成功收购。Cory关注的重点是有效地解决诸如SOA、可视化和支持实际业务应用的商品化资源的新技术开发和部署的挑战性问题。Cory具有高性能的事务处理应用的专业知识，帮助先进IT企业对数据与业务数量上的急剧增长做出响应，同时还解除了经营成本的压力。最近，Cory一直是在多核架构上为了改善应用程序性能而使用并行处理和可伸缩的数据库技术的积极倡导者。
Cory在美国加州圣巴巴拉大学获得学士学位。
内容简介：
《多核应用架构关键技术--软件管道与SOA》 介绍软件管道如何工作，它们能完成什么样的任务，如何使用软件管道优化周期来应用它们。通过并行处理方法，扩展保证关键任务处理有序的应用程序。解决现存应用程序的性能问题，并且解决现存处理过程中的瓶颈问题。一个完整的、容易采用的管道参考框架。详细的代码示例反映了经过验证的管道模式。 本书适用于开发多核环境下软件的人员。
