1 摘要
在上一篇“应用网格”中谈到了SOA和应用网格的关系，这一篇我们将以最佳实践场景来讨论如何给SOA加入网格功能。不管是正在学习SOA架构或者已经在实施中，我们都会关心如何建立IT基础架构来支撑SOA的运行。中间层，大负荷的XML文件，可靠性及跨多个异构系统的可衡量性是SOA的先行者关注的比较多问题。
在本文中，我们将讨论几个SOA可测量性的关键问题，比如中间缓存层，负载均衡，及高可用性（HA），这些我们称作是SOA网格。SOA网格可以提供企业IT跨越包括Web 服务，消息，企业信息系统，遗留框架的SLAs保证。
2 SOA性能面临的挑战
基于SOA的项目，需要涉及构建自动化流程来组合多个服务为复合应用。这些可能产生不可预见的性能问题。SOA项目通常都是分步实施的，只有一个项目成功了之后，后续的项目自然会继续施行，通过使用已经存在的服务及利用复合流程来产生新的价值，企业才能清楚的认识SOA的价值。但是这种复杂的服务调用和编排可以在企业内部和外部产生系统的性能问题，对于自动交易系统几毫秒的差别可能对整个系统的吞吐和性能带来很大的不同。在讨论具体的SOA网格架构之前，这一章我们主要描述几种可能存在的潜在影响性能的问题。
可衡量性，吞吐量，及阻塞点
在面向服务的计算环境中，可能发生瓶颈的场合：
² 共享中介的服务：这些服务通常需要处理集成任务比如：数据转化，基于内容的路由，过滤。
² 服务本身：将原有的应用代码暴露成服务的方式，然后其他的服务直接通过网络调用或通过编排引擎调用。
² SOA基础架构操作：这些操作保证了服务的质量，比如：BPEL流程通过“dehydration store”来处理状态数据或者使用JMS时使用“store-and-forward”技术来保证消息只传输一次或者使用Web Services Reliable Messaging (WSRM)来执行交付操作。
在大多数的情况下，SOA组件可测量性的瓶颈主要集中在硬盘 I/O，内存，CPU的饱和度。
大负载及内存限制
大于10MB的负载，特别是搞频率的交付，会导致端到端的响应变慢。所以如果一个服务需要大量的超过它存储于的机器内存限制的情况下，典型的解决方案是将这个服务部署在多台机器上来负载均衡对服务的调用请求。
文档流、批处理、请求检查和文件参考等通常都需要处理大文档，结合智能负载均衡及以跨越分布式缓存群集的流程逻辑的协同定位是对于内存敏感的服务的一种推荐的方法。比如哪些需要处理大文档的服务。
高可用性及可靠性
SOA高可用性(HA)指不管部署这个服务的机器如何，这个服务都持续可用。服务器的冗余是传统方案的主要问题，通常都是一组服务器采用点对点的技术进行。如果一个服务器挂掉，服务能自动的转到备份服务器，一般基于active-active 失效转移模式。
多数的群集通过静态的分割来提供了HA及可靠性，一个单一的备份服务器被预先指定以便处理失效问题。这种方法需要在很多服务器上的高级配置来应付系统失效。一般基于硬件的群集方案需要所有的机器都具有相同的操作系统版本。
一个更好的方法是采用智能群集，定义为内存访问，负载均衡和SOA环境的HA，这种类型的群集是基于异构的， 低成本的普通硬件，由群集根据需求自动的来分配一个或多个备份系统。
3 给SOA加入网格功能
对于有状态服务的中间缓存
具有网格功能的SOA环境的一个重要的部分是中间的缓存层。这一层面提供了自适应的JCahce，内存中的分布式数据网格方案以处理SOA中被服务所使用的有状态的数据。
这个中间的缓存层使得服务实例的内存存储可以跨越网格中的物理机器。这就有效的提供了一个分布式的共享的建立在异构网格机器之上的内存池。（这些机器可以是高性能的，大内存盒或其他低成本的常用机型）。
在一个有网格功能的，有状态面向服务的环境中所有的由应用或者是服务产生的对象然后存放在网格上的数据都可以被其他的应用或服务访问，在一个机器产生故障的情况下所有的数据对象都不会丢失。一组持续的协同运转的缓存服务器会使用群集级别的一致控制来协调数据对象的协调和共享。
这种方式的关键是保证每一个数据片段都一直被一个主要的宿主所管理加一个备份的服务。这里所说的数据可以是任何从简单的变量到复杂对象甚至很大的XML文档。从开发者的视角而言服务只是一个操作的履行，而不是如Java map或.net字典那样复杂的编程接口。
如下图所展示的，在SOA网格中发生的放数据的请求通过高效的网格协议传递到宿主主实例数据网格节点P。主节点的轮流Copy更新的数据到第二个备份节点B，完成后将控制权还给Service。
相反的，当一个Service需要访问实例数据的时候，SOA网格可以自动的定位到对数据是宿主的主节点，然后把数据返回给请求的Service或业务对象。这样的方式的操作包括很多种，比如并行的处理请求，事件和交易。在更高级的部署模式中，一组数据集合可以一次提交给网格，然后网格可以自动的将数据分散到多个宿主和备份节点来满足平衡和扩展的需求。
基于内存的高速访问保证了持续可用性
对于实例数据的主从节点的方式可以保证数据的高可用及失效转移。如果主节点不可用，SOA 网格可以自动的检测并立刻路由数据请求访问到备份的一个节点，（并有效的将备份节点转成主节点），并设定一个新的备份节点。
要想使得这样的可靠性的方式能很好的工作，就必须有基于群集的内置于网络的协议来保证正面的和负面的握手响应。为了避免在多个节点上更新数据的冲突，就必须具有锁定和一致性的方式，在网格中的每个节点必须能够意识到其他节点的存在。这就是接下去要讨论的基于主从节点的方式更高级的配置方式，以交付持续的，可预见性能的，不管负载或服务器损坏的系统。
数据如何更新到数据库？
以上我们所讨论的数据缓存具备了高速的，基于内存的存储的，持续可用的 特性。这些方式是不需要依赖传统的数据库技术的，但是有时候我们需要支持数据库更新，比如：如果需要对实时数据产生规则报表，或者需要建立一个额外的数据层来长期的存放数据。
SOA网格采用了异步队列的方式，在适当的时机来更新到后台数据库的模式，对于数据库的更新不会影响网格中缓存的应用和服务的状态数据的更新。这样就避免了持久层的数据处理的负荷问题，解决了大负荷处理数据的瓶颈问题。
对于有状态服务的负载均衡
通常开展SOA以满足不断增长的业务需要的办法是部署一个服务的多个实例并使用负载均衡来分发请求。如果服务是完全无状态的这种方法是非常典型的，也就是说在服务的调用之间没有任何的“粘滞性”因为这里没有任何的本地数据和服务状态需要被服务保持以用于下一次的服务调用。
但是如果服务的状态需要在单次调用之后继续被保存，那我们在什么地方放置这些状态数据呢？通常的答案是将服务请求本身设置成粘滞的，这就以为这保证请求序列是在一个相同的逻辑回话中（比如callback 操作）。或者需要将所有可能的状态价打包在一个服务请求中然后在总线上传输。但这两种方法都比较难以实现，成本也会比较高。
在一个SOA网格中，负载均衡调用任意的服务实例，服务总是定位并访问到最新更新的实例数据，不管负载均衡将请求委派为哪个服务。如下图中所示：企业服务总线（ESB）在Service A和Server A1之间进行任务的分配，ServiceA更新的数据对象被SOA网格所管理。后来并发的系列请求到Service A1的访问（再次，透明）的到相同的数据片段。
对于有状态服务的持续可用
同样的，如果一个特定的服务实例失败了，当一个服务实例被调用的时候最新更新的服务的状态数据仍然可以被访问。在下图中，Service A1是Service A的备份，当Service A失败后，ESB自动的路由到Service A1。
因为 SOA网格就是被设计成维护单一版本的实例数据，备份的Service A1不需要恢复任何东西，有状态的数据就在网格中。
优化SOA基础架构及BPEL流程的Dehydration Store
上面我们谈论了网格可以为我们的Services所能提供的功能。接下去我们分析SOA的基础架构本身，比如ESB和BPEL服务器，同样可以利用网格来提供性能输出，可扩展性及可用性能。以BPEL dehydration store为例：
我们都知道当流程对于当前状态进行检查然后写入数据库的操作使得业务流程效率降低。写入数据库的目的是为了可复原的目的及外部的异步调用过程。 那么当流程的复杂性越高，就需要越多的检查点，流程执行的潜在威胁就越大。SOA网格可以取代这些数据的检查点，并具有以下的优势：
² 快速的存储及多次重新获取流程的状态
对于发生在群集中分离节点的回掉和恢复，可以容易的实现状态的分布
一个样例：基于基础架构的数据网格
下面是一个基本的但是强大的使用案例展示了如何使用数据网格基础架构来提供快速的可靠的分布式内存缓存的SOA解决方案。
BPEL引擎处理多个服务调用的交互。在BPEL流程的定义中，BPEL引擎可能进行一系列的服务调用流程，或者等待外部第三方系统的一个事件发生。在BPEL的回话中包含了receive, invoke, wait, and onAlarm。在这期间，BPEL引擎需要暂时的休眠（dehydrate）流程，然后将当前的一些内容写于到持久层存储，这也是我们所说的dehydration store。这些流程的内容可以包含了当前编排流程的服务请求消息的有效负荷，可能是很大的信息。另外流程内训可以包含以下的值：
² 任何定义成全局状态变量或本地范围的变量
被BPEL引擎所使用的内部信息（比如：当前流程流的当前状态，交易范围等信息）
通常对于dehydration store的持久层机制我们总是通过部署关系型数据库来实现。大数据量的负载下就可能成为流程处理的瓶颈，而不管这个关系型数据库如何的好。一个解决方案就是使用SOA网格作为BEPL的dehydration store来取代关系型数据库。
数据的序列化和流程逻辑定位
SOA网格的一个深层次的优势在于网格的缓存不仅可以存储数据对象并且可以包含程序逻辑操作。相对与数据的获取模型这实现了逻辑的协同定位。协同定位的优势在于使得流程逻辑操作发生在数据存储的哪个节点，这样就排除了如果服务需要从远程的节点来获取数据序列到当前的内存中，对于操作大数据对象是很有优势的，因为减小了网络的负载。BPEL流程的重新定位
一个BPEL流程可以dehydrates然后在网格中的其他地方rehydrates自己，以在它操作的实例数据之上执行服务。
这样做的原因如下：
² 服务的状态数据特别大，在网格中序列化的成本很高
² 使用BPEL流程来调用一个只是存在于一个特定机器上的ERP系统的适配器，如果对于连同BPEL流程和适配器的协同定位可以减小在BPEL Server和适配器/ERP系统之间的网络资源消耗。
下图中，一个轻量级的notification/signaling机器用来触发SOA网格中合适的节点来激活并rehydrate BPEL流程
这种做法BPEL流程的执行不需要使用hub-and-spoke方式介入BPEL引擎和服务之间网络消耗，另外明显的降低了主网格和从网格之间内存管理所涉及的大数据对象。
4 小结
SOA
网格可以解决分布式环境中与高可用，可靠，扩展和高性能有关的很多难题。SOA的架构可以充分的利用网格来建立QoS架构。有状态的服务是SOA网格的主要关心的，因为对于这些状态持久化的需求是一个主要的瓶颈，不仅仅是性能还包括了可复原性。总之，SOA网格可以帮助我们获得可预见的QoS及快速的响应时间，这些可以通过自行管理的自动调整服务器损耗之上的最小化配置来实现。将SOA网格作为基础架构的一部分可以排除很多传统的难题，并使得SOA能够顺利的进行推行。本文仅代表作者本人观点，如有转载，请与作者联系：http://space.itpub.net/16184648/ vooscn@gmail.com
image005.jpg来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16184648/viewspace-483843/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/16184648/viewspace-483843/
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
