企业SOA：Service可用性与XML兼容性
企业SOA：Service可用性与XML兼容性
2007.01.04 来自：IT168
在企业级SOA建设中，对于容量和和吞吐率（Capacity &Throughput）的设计，是每个架构师都谨慎考虑的。由于实际的处理是逐个元素积累，并最终会聚到企业数据总线的，因此这里笔者对于整体SOA环境中每个元素的处理量分解，采用将企业数据总线作为根节点的树来讨论，其他的相干元素按照依赖关系作为其子孙节点。
在企业级SOA建设中，对于容量和和吞吐率（Capacity & Throughput）的设计，是每个架构师都谨慎考虑的。在未来几年里SOA（或者其进一步定义框架）将在很大程度上主导企业信息系统建设，这对容量和和吞吐率的设计提出了更高的要求。
虽然SOA的理念是通过集成达到资源整合的目标，但是鉴于大家普遍采用的XML Web Service实现方式，所以在企业级SOA建设中，更需要考虑与XML的兼容性问题。
Service的可用性
对于系统吞吐率的考虑也是很容易被忽略的部分，相信各位架构师在进行企业内部应用设计的时候对容量和吞吐率（Capacity & Throughput）的考虑都会很谨慎。对于相对松散的SOA企业服务总线部分，现在看很多应用还处于非密集数据交互的阶段。但是可以预见的是，在未来几年里SOA（或者其进一步定义框架）将在很大程度上主导企业信息系统建设。到那个时候，企业服务总线上运行的就不是几十K Transaction / day的业务，很可能就会达到数M Transaction / day的业务。包括我们的合作方在内，随着业务的发展合作方之间也会更多地利用企业服务总线的外部Service接口。
如果在此番设计中没有充分的准备，或者说企业服务总线设计得过于要求自身主控的话，那么将会在快速变化的业务面前不堪重负。毕竟，建立以XML Web Service为基础的企业SOA环境目的是为业务运行提供互联方案。无论SOA设计本身如何先进，如果最终的可用性存在问题，那么这个企业SOA环境自身也就无任何价值可言，因此就要求SOA中的每个关键元素都是可靠的，至少应该包括下面的元素：
每个Service Endpoint。
对于遗留系统包装所使用的封装Service接口。
用于连接每个Service Endpoint到企业服务总线的Adapter。
企业服务总线和服务Registry。
企业最主要的几个Service Provider。例如：企业数据服务Provider、企业证书和目录服务Provider。
总体来说，一个企业SOA环境的整体可用性是由其中可用性最薄弱的那个环节决定的，但是考虑到企业IT投入成本的关系，每个SOA元素又不能无限度的投入以增加其可用性。为了确定并找出瓶颈环节，并确定其吞吐率（Throughput）的下限，最简单的办法就是测试。由于SOA的外部服务接口一般运行在互联网上，因此对于国际性的企业而言它的运行是7 ×24小时的。不过下限 吞吐率的确定不可以用24小时来平均计算，更不可以用7×24或者 30 × 7× 24来计算，而一般应该采用其峰值× 的计算方法。
根据笔者的经验，这个峰值点的确定需要按照如下几个步骤来完成：
（1）确定高峰日的峰值处理吞吐率
例如，下图是一个进出口企业在业务繁忙阶段一天通过SOA环境的运转的单位小时（为了简化讨论，每个小时内视为比较平均）交易量。
图：每日的交易量变化
那么从上图看，应该采用16时的处理量作为这一阶段的峰值。
（2）确定并分割高峰处理阶段
图：不同月份的交易量
从图中不难看出，第四季度到次年的第一季度这半年是企业相对较忙的时期，而2~3季度则是相对比较闲的时间。为了考虑整体的运行成本，这里可以分阶段采取两套运行吞吐率，繁忙阶段以最高点12月的交易量为基准峰值，闲暇阶段以最高点9月的交易量为基准峰值。
（3）分解处理元素
由于实际的处理是逐个元素积累，并最终会聚到企业数据总线的，因此这里笔者对于整体SOA环境中每个元素的处理量分解，采用将企业数据总线作为根节点的树来讨论，其他的相干元素按照依赖关系作为其子孙节点。该方法尤其对于具有多个Service Endpoint、多个Service Provider、多个外部服务访问节点的SOA环境有效。一个静态的逻辑的分界视图如下：
图：一个企业SOA环境的分解示例
在这个分解下，每个上层节点的交易量就是下层实际向其发送数据量的总和。因此，在了解了每个Service Endpoint的峰值后，综合了时间段分布，可以为其上层节点计算出一个峰值，最终确定根节点，即企业服务总线的吞吐率要求。
在确定了企业服务总线的交易量后，就可以对现有企业服务总线进行评估。如果可以满足，那么就可以投入生产环境。但如果不能够满足或者可以预见在不远的未来不能够满足，那么就需要扩展（其他的元素也可以参考处理），扩展的办法可能有三种，如下：
（1）节流和优化：优化并最终减少实际的交易量，优化企业服务总线的运行环境。
（2）提升：扩展企业服务总线设备的处理能力。
（3）扩展：采用Cluster模式，横向地扩展企业服务总线。
前两种措施与处理一般的Web应用基本上相似，这里笔者不做展开，对于企业服务总线的扩展，这里有些设计上（或者产品选型上）需要注意企业服务总线本身不能够太过自治。如果一个企业服务总线自身设计上，要求全部采用自己特别定制的所有Service Registry系统和BPEL系统，那么它本身就不具备与其他企业服务总线产品并联合做的能力。从企业长期的IT需要看性能扩展，必将受到它的限制，同时对于运行维护的管理上也会因为每个企业服务总线产品需要独立的配置系统而带来很多人员和培训上的花销。
下面是一个渐进的过程：
（1）最不利于扩展的选择：由于现有企业服务总线没有被明确的标准化，导致设计上没有类似的考虑，所以最终的产品完全自治，只能自己单个产品运行。即便展开也要重复进行每个产品的独立配置，但是这个层次的实现本身不具备Cluster中Load Balance的特性。
图：仅能全部自治运转的企业服务总线
（2）好一些的选择：设计上一个企业服务总线产品的配置内容可以独立加载，而且这个加载的部分支持多个实例并发使用，自身支持Cluster中Load Balance。
（3）更好一些的选择：不仅自己的企业服务总线产品间可以真正地并行，并且可以和其他最主流产品并行。如果达到这个阶段，对于企业而言，一个最明显的经济效益将可以预期到达。毕竟未来的产品会更加完善，而价格会因为市场的竞争趋于降低。
如果能够达到2+层次的话，那么企业的SOA环境从可用性上说，一方面可以基于历史数据和元素分解对于现有情况下的吞吐量作出一个比较科学的评价；另一方面可以在更长一段时间里通过元素的Scale Out、Scale Up、性能调优不断适于新的业务容量，而且总体上还继续保持企业SOA架构的稳定。
企业服务总线的技术实现必须是标准的，而不能是某某企业以前的所谓某某CORBA中间件平台，或COM+中间件平台简单的“新瓶装旧酒”。虽然对于提供商而言它们是以比较小的成本快速地切入企业服务总线市场，但是对于企业自身而言，基于这些所谓中间件平台搭建出来的企业服务总线，首先要受到标准化的很多限制，它们本身采用的很多技术不是这个时代的产品。虽然说SOA是个概念，但是如果基于这些平台的中间件，在实现完全XML化的各个SOA组成的新的版本上就需要更多的时间。
同样的，对于企业服务总线产品本身使用的持久层数据库选择上也要慎重。毕竟在SOA环境中SOAP、XML、XSD、WSDL、BPEL的本质上都是XML，采用具有“双核”特性的XML数据库产品才可以更好地检索和使用它们，通过压缩XPath和XQuery的执行时间来从整体上确保每一个组成元素的更高运行效率。如果相应的企业服务总线采用遗留产品的中间件平台，那么它们的持久层也由于历史的原因一般会使用纯关系数据库完成。这种做法首先在XML的解析上就很可能存在一定的差距，更不用说XPath和XQuery查询。
虽然SOA的理念是通过集成达到资源整合的目标，但是鉴于大家普遍采用的XML Web Service实现方式，笔者还是建议在SOA的调度层开发或者产品购买上要选择Native支持XML的新开发技术和新数据库产品。
同样，对于XML兼容性的考虑也要在确定每个Service Endpoint的集成方式上。下面笔者以一个.NET Remoting + SQL Server 2005，一个COM+ + SQL Server 2000和一个J2EE的EJB + Oracle 8i应用的集成为例，讨论XML兼容问题对于集成过程的影响，三个应用的功能如下：
（1）.NET Remoting应用是企业的统一授权平台，负责用户的认证和授权检查。
（2）COM+应用是企业的财务系统。
（3）J2EE应用是企业的内部生产系统，负责处理业务单据。
它们最后封装的Service Endpoint是提供给企业合作方，通过在线银行做在线的小额订单自动核销。流程如下：
（1）合作方的应用系统把自身的身份、合同号、银行回执号发送到小额订单和小服务的接口。
（2）该服务首先调用.NET Remoting应用做用户认证和全县检查。
（3）确认后，调度COM+应用划账，并调用J2EE应用修改订单的工作流和处理状态。
（4）最后，服务接口反馈合作方应用的Web Service，确认核销成功。
相对而言，效率较差的实现就是为每一个应用独立设计一个基于应用内置组件功能的Web Service，最后在其上再开发出一个协调的Service。
图：纯Web Service调用方式
一个效率上改进的方法就是把.NET Remoting与COM+应用做一个整合，通过互操作在.NET Remoting应用中增加一个新的接口，把步骤1与步骤2作为一个内部的步骤完成。
图：内部面向性能集成后的结果
上述两个方法不仅仅有处理上的性能差异，而且对于不同开发技术对于XML的集成支持上也有一定意义。简单的通过.NET Remoting的HTPP Channel + SOAP Formatter，就可以将需要COM+通过较为繁琐的SOAP Toolkit开发旁路过去。
对于不同消息模式的考虑
注：由于笔者所在行业习惯于称事务性为交易性，所以下文笔者也将继续采用“交易性”的称呼。
一般而言，企业的绝大多数处理都是必须有交易性保证的，但是针对具体的应用点，还是可以具体分析的，起码来说消息模式上最少就有如下三种方式：
（1）单项的One way（Simplex）：
图：Simplex消息模式
（2）异步的双向One way（Duplex）：
图：Duplex消息模式
（3）质询——响应（Request – Response）：
图：Request – Response消息模式
三种模式下，其实仅有Request – Response 模式可能会需要交易性的保证。从实际的使用上，查询操作本身也不需要交易性保证，只有涉及到DML操作的时候才真正需要启动交易。因此在企业SOA环境的设计上，WS-Transaction、 WS-Coordination这些较为重磅的协议要考虑独立配置到具体的SOAP调用上，而不是一股脑的建立一个“凡是”的SOA 交易性环境。并且从安全设计上考虑，单纯的查询与设计DML的操作，也完全可以通过拆分服务，并为其配置不同访问权限的账号来进一步加强系统的安全性。
后记
文中笔者仅仅根据自身经验，对于企业SOA环境建设中几个技术设计考虑的要点进行了讨论，随着类似工作的继续进行，笔者会将更多的设计要点拿出来与各位架构师探讨。
http://news.csdn.net/n/20070104/100288.html