Service的可用性
在企业级SOA建设中，对于容量和和吞吐率（Capacity & Throughput）的设计，是每个架构师都谨慎考虑的。在未来几年里SOA（或者其进一步定义框架）将在很大程度上主导企业信息系统建设，这对容量和和吞吐率的设计提出了更高的要求。
虽然SOA的理念是通过集成达到资源整合的目标，但是鉴于大家普遍采用的XML Web Service实现方式，所以在企业级SOA建设中，更需要考虑与XML的兼容性问题。
对于系统吞吐率的考虑也是很容易被忽略的部分，相信各位架构师在进行企业内部应用设计的时候对容量和吞吐率（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架构的稳定。
网友评论