自从1958年发明集成电路以来处理速度和存储容量
直在以每两年翻倍
速度增长
但是软件Software系统发展速度貌似不可避免地超过了这切指数增长速度SOA应用越来越广泛而且随的还有服务的间XML数据传递方式及增长更为迅速网络应用虽然你取得了成功但是你系统很可能会马上超载而且是在你最意想不到时候如何解决这场危机呢?鉴于企业计算
内存和存储需求持续增长软件Software也需要维持相应步伐我们从开始就要使用正确思路方法以取得可控制延迟线性可扩展性数据文件和信息容量也在持续增长需要更多处理能力也使那些在使用前需要先将其具体化软件Software显得更为笨重在某些情况下这些操作在执行前还需要多个输入那些构建极限事务处理(XTP)类应用——比如电话公司呼叫建立和计费、网络游戏、安全交易、风险管理和在线旅游订票服务——
人对这方面应该很有了解还有更广泛用例就是网络应用需要根据网络容量增长而提高但是后台系统却无法应对这样迅猛流量边界成本
在和客户讨论对SOA进行延迟可控
扩展时我们经常使用个称为"边界成本"(BoundaryCosts)术语为便于理解请考虑以下情景:由个网络应用(或数据库、外部业务伙伴、从EDI文档转换而来)生成XML文档需要经过多个服务处理而这个过程由BPEL或ESB进行协调通常思路方法是把XML交给总线由总线根据处理定义
相应服务并将XML文档作为服务请求负载部分传递给服务需要对数据进行处理服务将依此对XML进行读取还有需要和数据库交互情况这种思路方法看起来非常简单但是
在实际中使用这种思路方法时候却会遇到扩展性上问题从个服务穿到另个服务成本是多少呢?在个简单业务过程时候这个成本消耗要发生多少次呢?如果XML文档非常大达到几M范围、数量成百上千或者两种情况同时发生呢?而且考虑到大多IT环境是多平台和多种技术
复合体因此又给这种情况增加了新困难即使处理引擎或服务总线性能非常出色服务终端处理过程仍然会成为瓶颈最近在家客户网站WebSite上显示个原来通过需要15秒处理时间业务过程最近在峰值负载时经常超过其SLA协议约定30秒在过去两年里开发人员把大部分时间都用在了优化调整这15个服务每处细节但是最后揪出黑手却是各服务的间边界成本他们进行次详细检测显示这15个服务都要花费1到2秒时间在个开源网络服务工具包里对XML进行解析处理这并不是有意污蔑开源网络服务工具包只是简单地介绍说明下在终端解析处理XML会增加延迟并且相加效果非常可观所
各个服务都需要从XML在线串行化形式中读取其有效内容并解析为本地Java或.NET对象形式然后才能被业务逻辑处理并且如果还涉及到和数据库交互那么还会发生额外相关匹配对象最后还要发生相反过程产生和服务请求相应响应并根据业务过程将其发送到下游服务在SOA中
比较常用处理XML方式是使用网络服务和XMLBeans通过XMLBeans可把输入和输出完全具体化然后再生成对象这样可以最大化可用性和处理性能内存处理可能包括分类、过滤、合并等操作而所有这些操作都会增加处理每次所需整体内存容量这种方式缺乏扩展性而且无法应用到这个领域许多场景中许多产品支持XML流但这种方式也有局限性即如果不先存放数据可能就无法进行任何有意义操作那么
能不能设计种方式把信息储存在个可以忽略数据大小和单机处理能力应用网格中呢?该应用网格可以利用多台机器组合内存和处理能力来完成项操作比如处理个复杂公式或对海量数据进行过滤该应用网格还可将数据生命周期延长到服务请求周期的外持续到服务器重启甚至跨越网络边界如果你能将网格数据存储
能力和高效流处理结合到起就能够产生个处理能力远大于以前、高度、可扩展系统通过将些补充技术结合到起我们就能取得把计算操作扩展到分布式计算网络中减少SOA服务、应用服务器和客户应用等数据消费者处理和内存需求我们还消除了数据处理过程中对中间存储数据库需求通过应用网格我们还可以传送数据参数而不是数据本身这样可以极大地提高通信层效率并且减少甚至消除边界成本本文还有
段显示应用网格中处理大型XML文件代码举例在典型XML文件中通常有些元素在没有任何预定义限制情况下重复通过STAX解析器对XML进行处理并且用JAXB处理XML和Java对象的间会话我们可以将这些重复元素从XML流中提取出来然后放到应用网格中作为单独对象这样对象便填充到了网格中并且只需消耗有限内存资源填充到网格的后网格便可以使用构成网格多台机器对数据进行处理每个网格成员进行项操作或过虑然后将中间结果传递给网格客户端并由其处理成最终结果="xspace-totlerecord">5="xspace-totlepages">1/5="xspace-current">12345>
最新评论