SOA带来的性能思考

做性能测试的一个项目，仔细观察了sotown的框架，有了一个思考，soa的性能如何？

SOA 的优点

我已经在前面几个关于soa的文章中，其中soa优点也是ibm soa 架构师认证考试中重点提到的SOA的优点。

敏捷性。 组 成 SOA 应用程序的代码是模块化的；换句话说，代码被包含在可重用的块中，可以用这些代码块构建其他应用程序。可以通过抽象进一步提高编程生产力，抽象把技术细节 （比如编程语言、服务器平台和操作系统、应用服务器类型、DBMS、数据库模式等）隐藏在提供服务的程序后面，服务消费程序的开发人员看不到，也不需要了 解这些细节。当发现新的应用程序功能需求时，SOA 使组织的 IT 人员能够快速地做出反应。

质量。 复 杂应用程序的结构就像是一团乱麻，在程序和数据库对象之间存在着许许多多点到点连接。（一团乱麻这个比喻不是我说的，我最初是听一家金融公司的 IT 执行官这么说的。）SOA 会大大减少应用程序中连接点的数量，并大量使用标准语言描述应用程序提供的服务（Web Services Description Language[WSDL] 是用来描述服务的一种 XML 格式）和调用服务（常常通过另一种 XML 格式 Simple Object Access Protocol[SOAP] 来实现）。简化的 SOA 结构会降低应用程序的脆弱性；也就是说，代码修改不容易损坏应用程序。

运营灵活性。 在 SOA 中会使用抽象和标准接口，这意味着 IT 系统人员可以为应用程序基础结构的不同部分使用不同的平台和操作系统。还可以混合使用不同的编程语言、DBMS 和应用服务器。

听起来不错，不是吗？

SOA 的性能可能会成为问题，这是因为抽象要通过额外的代码来实现，这通常会增加机器指令路径长度。减少应用程序组件接口也会增加路径长度（为了处理一团乱麻的 点到点连接，必须增加集中式服务访问基础结构）。因此，就出现了一个问题：基于 SOA 的应用程序能够产生良好的性能吗？我的答案是 “可以”。我相信产生良好的性能取决于三个关键措施：对修改数据的操作使用异步处理，对数据获取请求进行缓存，对批作业进行事务化处理。

异步处理。 在 本文中，我将讨论如何解除应用程序的客户端与后端数据库修改之间的关联。例如，假设一位用户通过零售商的基于 Web 的销售应用程序提交了一个订单。这个操作会在应用程序所用的数据库中进行一些修改。如果应用程序是基于 SOA 的，那么与老式的整体式体系结构的应用程序相比，使这些数据修改生效所需的时间会长一些。但是，这是否意味着在单击 “Submit” 之后用户必须等待更长时间呢？不一定。

假设当把用户的订单信息放到一个消息队列中之后（队列可能由 IBM 的 WebSphere MQ 管理），订单输入应用程序就认为事务已经结束。这个过程会非常快。队列可以配置为可恢复的资源，所以即使整个应用程序系统崩溃了，仍然可以保留订单输入数 据。用户可以做其他事情，与此同时一个过程从队列中取出订单信息消息并适当地修改数据库。

这样做会有风险吗？是 的，但是我认为风险不大。因为订单输入数据库的更新对于最终用户对 “Submit” 的单击操作是异步的，所以如果用户马上单击订单确认页面上的 “View Order History” 链接，那么产生的视图很可能不包含刚才提交的订单。如果还没有用 MQ 队列中刚才提交的订单信息更新（获取 “订单历史” 信息的）数据库，就会发生这种情况。我相信这种风险变成现实的可能性相当小，因为用户很可能过几秒才会想要查看订单历史，他还要花时间找到并单击 “View Order History” 链接。对于订单输入应用程序的后端从 MQ 队列中获取订单信息消息并相应地修改数据库来说，几秒时间应该足够了。

通过对数据库更新操作使用异步处理，可以 改进性能（从用户的角度来看）；另外，MQ 还会提高应用程序的可用性（同样是从用户的角度来看）。如果后端数据库系统无法执行更新处理（可能由于服务器或操作系统故障、程序逻辑错误或数据库维护操 作），前端队列仍然能够接收消息，应用程序仍然可以向单击 “Submit” 按钮的用户显示 “Order received”。消息会保存在队列中；当数据库恢复正常时，就会继续处理消息。同样，在用户的 “Submit” 单击操作和对应的后端数据库更新之间增加一个队列，也有助于避免后端服务器负载过大，服务器负载过大可能导致系统崩溃和非常显著的应用程序服务停顿。（在 这种情况下，消息队列的作用相当于汽车引擎的膨胀罐，这个装置有助于避免引擎过热。）

对数据获取操作进行缓存。 同 样，这个思想也是使用技术和应用程序体系结构让 SOA 发挥其优势（敏捷性、质量和灵活性），同时产生用户满意的性能。数据缓存的概念相当简单：把经常获取的数据拷贝存储在接近应用程序体系结构边界的缓存服务 器上，这样的话数据获取请求就不必通过很长的路径访问后端数据库（记录数据库）。在数据缓存技术中，比较复杂的问题是如何以及时精确的方式把后端数据库的 更新传播到缓存服务器。这个问题是可以解决的，而且不同的组织采用不同的方法更新数据缓存服务器。一些组织采取 “自产” 的办法，利用自行开发的代码使中间层数据存储与后端记录数据库保持近似同步（从技术上说，可以让缓存数据存储与后端数据库保持绝对同步，但是近似同步的开 销通常比较小，而且常常足以满足用户的需要）。其他组织使用不同厂商提供的数据缓存解决方案。无论数据缓存实现是自行开发的，还是购买的，组织都能够通过 使用数据缓存显著改进数据获取性能。在 SOA 环境中，不同的功能层、抽象和基于标准的应用程序子系统接口以及与 SOA 特有数据的关联都会增加事务响应时间，数据缓存产生的速度收益可以抵消这些时间开销，所以在 SOA 环境中尤其有意义。

对批作业进行事务化处理。 我 在以前的专栏文章 “Do You MQ?” 中讨论过批量事务化（参见参考资料）。这种技术的基本思想是，对于一个批量输入文件包含的所有记录，按照事务程序输入的形式来处理。这通常需要在批作业开 始时增加一个步骤，读取输入文件记录并把包含的信息放到一个队列中的消息中。连接这个队列的应用程序可以读取消息并执行程序逻辑来处理输入信息（这个处理 过程可以包括数据库更新）。与这个消息处理过程相关联的输出数据也可以放到一个队列中的消息中，输出最终可以组合成一个文件并传输给客户机。

当然，与传统的批处理形式相比，以这种事务化方式处理批文件的 CPU 效率并不高；而且如果事务以串行方式运行，采用事务化方式会增加处理输入文件所需的时间。并行地执行事务（也就是，让多个同时运行的事务处理输入文件记 录，而不是在一个事务内实现并行）可以显著减少所需的时间，但是这要求服务器上的 CPU 足以支持多线程（如果主机服务器的空闲处理能力很少，进程就难以实现有效的并行）。

我并不担心事务化批处理会导致在特定的时间段内集中过大的负载，相反，我认为事务化是消除传统批处理时间窗的好方法。如果批处理已经事务化了，就不再需要以文件形式接收输入。一个队 列包含来自文件的输入记录，这个队列可以（以可靠的方式）作为 Web 服务向最初发送文件的客户机公开。这样做的好处是，客户机可以在生成输入记录时随时发送它们，而不必把记录集中在一个文件中并在特定时间发送。由于采用事 务化处理，与处理客户机输入记录相关联的输出可以在生成时及时地返回给客户机。因此，如果客户机在上午 9 点生成输入记录并发送给您的组织，那么在上午 9:05 就能够收到响应（甚至更快），而不需要等待 24 小时才收到包含其他许多响应输出的批量响应输出文件。用户会对组织离线地（也就是以异步方式）处理输入记录的能力感到吃惊。这个特色会给您的组织提供重大 的竞争优势。

思考 —— 但是要以不同的方式思考

SOA 看起来似乎会损害性能，但这往往是一种误解，在我的前一篇文章中也认为soa会有性能的开销，比如esb。因为人们习惯于按照老式应用程序的思路考虑 SOA 应用程序的性能。如果把 SOA 应用程序看作完全不同于老式应用程序的工作方式，您就会发现不但能够实现相似的性能，而且通过改进服务质量，客户机的性能水平甚至可能出现重大突破。实现这个目标容易吗？当然不。这涉及许多步骤：决定应用程序处理应该异步执行还是同步执行，确定实现数据缓存的方式和位置，决定如何在事务化环境中处理传统的批功能，评估和实现企业服务总线和工作流组合技术以帮助设计和执行复杂的离线事务处理