对于大部分公司来说，要保持竞争优势就要使用最新的技术。而实际上，对于部分公司来说，面向服务即是取得商务成功的支柱。作为一家财富百强公司的首席架构师，我在SOA方面遇到了不少挑战。

　　我们的SOA部署项目差不多刚刚开始一年有余，已经有纯SOA应用在运行中。作为世界上最大的技术供应商和主要的技术销售、市场规划和物流公司，我们主要依靠自动化来管理我们国际性的供应链站点。通过这个站点，我们在为近400家供应商分发数不清的IT产品的同时向150个国家的约17万代理商提供了各种服务和方案。许多小型到中等规模的公司希望从代理商处而不是制造商处购买技术产品，因为这样他们可能会获得更宽松的许可和支持条款。

　　我们的任务是成为这个技术价值链中的关键的一环，通过独特的营销程序、外包物流服务、技术支持、金融服务和产品聚合与分发等手段为硬件和软件供应商、技术方案提供商和代理商创建销售和赢利的机遇。

　　我们必须对获取技术采取谨慎的态度，因为我们还要将其提供给我们的VAR和代理客户。任何部署在国内或国外商业站点上的方案都不能违背我们的中心原则：帮助我们的商务合作伙伴提高利润并扩大他们的市场份额。比如我们有一项非常重要的业务就是为世界各地的代理商提供当前可获得的技术产品商标。因此，我们面向服务的应用也变得越来越成熟。这个复杂的服务链目前包括定单管理和执行、委托制造、委托存储、产品采购、产品拆包和装盒、逆向物流、运输管理、客户关怀、信贷与收款管理服务等等。

　　挑战：保证服务交付不会受到脆弱应用的影响

 　　越来越多的IT部门部署了用于实现业务关键应用服务的多层中间件平台和框架，因此他们也希望能够获得面向服务的架构(SOA)所带来的优势：敏捷性、灵活性、生产力和扩展性。但是正在进行中的SOA需要非常的警戒心才能避免面向服务所带来的应用性能管理上的缺陷。

　　虽然我们是一个市值350亿美元的公司，我们的SOA展望仍然和其它公司一样充满了挑战。部署一个能够允许IT在既有应用的基础上添加额外服务而无需频繁改变低层结构的应用设施是很关键的。敏捷和扩展性，我们不仅希望当今的组合应用能够与部署中的业务过程保持一致，还希望它们能够根据市场压力迅速而动态地进行调整。获得并向客户群提供网络服务再整合到我们的应用站点的时候，所需做出的代码改动越少越好。但是这”最后一英里”的调整–通常意味着所部署的应用要以周甚至天为单位进行重新配置–是为了保证实现以一些非常不稳定的应用为基础的业务关键服务的连续交付。

　　对SOA所固有的这种不稳定性进行控制是实现我们保持以更快的速度推出新服务并更好地满足客户要求的唯一方式。比如，在过去几年里我们添加了一个更先进的购物车，更方便的产品搜索功能和定单状态查询功能。

　　但是在部署SOA的过程中，我们发现了在传统的系统管理工具和应用性能管理方案中的一个重要的”可视性空白”。当然，这些工具在追踪IT资产方面是非常优秀的，比如它们在干什么，运行是否正常，以及是谁在使用它们，但是SOA构建并交付应用的复杂方式使得诸如SNMP监控、交易跟踪、设备映射工具发现机制变得非常低效，因为各个企业投资了大量资金的非常重要的中间件技术恰恰隐藏了业务功能之间的关键关系–比如库存、订单执行和应收账款等之间的关系。

　　产业分析公司企业管理协会(EMA)最近一次对150位IT主管的调查显示，对于异质分布式应用的管理，最大的挑战即是高额支持费用和缺乏可用的管理工具。很少企业能够跟踪到工作组服务器、数据库、网络服务和企业服务总线与元数据库之间变化的关系。据EMA统计，他们能够看到整体的一部分，但是可视性的空白仍然存在，这表示他们必须无法跟踪到端对端的性能或者对变化进行管理，并且他们也不做应用服务建模。EMA发现，仅仅是处理变化管理所带来的影响就可以给任何企业当头一棒了。报告员称：“对于一个拥有高度结构化的IT管理环境的企业来说，其变化的25%都会带来生产方面的问题。而对于那些非结构化的企业，这个数字更可能高达80%。”

　　虽然对于简单的J2EE应用来说仅仅使用APM方法可能就足够了，但是在监控和管理SOA与其它复杂的组合应用的时候已经很少单独使用APM了。这些工具无法对与特殊应用或处理相关的服务入口和出口进行操作。如果你有运行在三个不同服务器上的应用组件服务，那么你知道是哪一个负责处理与报价功能相关的运输管理呢？如果应用使用了中间件平台上的共享组件，这个问题会更难处理。这些逻辑工具为编码组件提供了可视性，但是它们却无法提供组件性能与所交付的应用服务性能的关系。

　　为什么这一点很重要呢？服务相关性是非常关键的，因为它可以为特定的服务或业务功能提供性能参数，然后根据服务相关性作出诊断并最优化应用的性能。企业应用恰恰是为了提供业务服务而存在的，因此如果性能上有问题或者共享应用组件所支持的某个特定的应用服务无法及时投入使用，那么应用的价值很快就会被停机、性能低下、以及与频繁维护相关的各种费用消耗所淹没。面向服务的应用的复杂性使性能的检测与调整、问题根源的追踪、和负载规划变得更加困难。

　　服务建模是为解决常见SOA问题而生

　　读者应该也有所了解，最常用的应用程序分析技术是字节码技术。其工作原理是使用分析工具将字节码插入到各个类中。对于CPU性能分析，这些字节码通常是methodEntry()和methodExit()调用。对于内存分析，则是把字节码插入到每个(新)构造函数的后面。这些字节码插入操作是通过后编译器或自定义类加载器完成的。

　　这种技术的主要缺陷是，一旦对类作了修改便无法再发生改变。这种灵活性的缺乏经常会导致在将来产生某种问题。如果你选择对整个应用进行分析，那么这种技术的开支常常会导致非常严重的性能问题。但如果使用封包或基于类的过滤器来对此做出一些限制，又有可能无法对应用的重要部分进行分析。而且，如果技术上的改变需要重新启动应用程序，还会极大地延长分析过程所花费的时间。

　　我们曾经遇到的情况是，当前使用的应用管理系统只能使用字节码技术。所以我们开始研究如何选择一种更好的方式来对面向服务的应用的健康状态进行监控：剔除已知我们不需要的并定义我们所需要的环境。字节码技术其本身是一种优秀的技术，但是如果不能根据应用服务的环境进行部署那就会像是在无灯光的地方穿衣服一样。你可以穿上衣服，但是你无法看清你现在的模样。

　　寻找可视性问题的解决方案有许多条件限制。我们知道我们需要什么。除了一般条件，我们还需要一个直观的管理控制台、深层处理的映射与建模、所有组件的持续性的性能参数、高级诊断与分辨能力、以及历史与趋势报告。我们是一家IBM工作室，所以我们所选择的方案必须能够运行在WebSphere及相关的中间件上。最后，这个方案还必须符合外包供应商的要求，并能够在无需开发人员或额外的专家资源参与的情况下进行快速部署。

　　根据这些独特的需求，我们考虑了几种方案，并最终决定应用服务建模是能够解决我们的问题的最佳方案。应用服务建模提供了所需的环境可视性。它能够动态地将应用提供的服务联系到支持这些服务的低层代码，从而提供了对其进行有效的管理所必须的环境可视性。最近的一份福里斯特报告指出，“基于模型的方法对于较复杂的组合应用(比如SOA应用与门户)来说是一种’必须’的方法。”

　　应用服务建模可以提供更优秀的服务

　　基于模型的面向服务的应用监控是用来提高环境可视性的。应用服务建模把可视性带入了面向服务的应用，可以让我们知道哪一个业务服务是由SOA设备中的哪一个应用组件支持的。一旦IT有了所需的环境可视度，我们就能够管理一个甚至更多的组件来优化服务交付。

　　应用层次的建模为我们提供了各应用服务下的设备的可视性拓扑图，因此各服务所必须的依赖性也显露无遗。其原理是解析Java文件、配置文件和数据库中的元数据以检测入口点。这个过程结束之后，服务便被建模，参数确定，然后两者都在模型上表示出来。

　　这个工具所生成的任何模型都会随低层组件的相关变动进行自动更新，因此不需要手工干预或为这些更新工作而费心。自动化能够让你的业务关键服务运行在更好的状态上。此外，IT组织还需要一个可靠的工具来做影响分析。比如，如果确定了一个即将进行的变化，那么IT操作必须能够对所有应用过程、应用组件、系统等可能受到变化的影响的各个方面进行验证。如果没有添补这个IT可视性空白的手段的话可能就无法取得如此显著的优势了。

　　应用服务建模提供了一定程度的可视性和辅助解决未知问题的能力。比如系统在五分钟后显示了我们花了八个星期尚未得出结论的问题的根源。那是个什么问题？

　　我们网站上的一个搜索功能，它可以让客户寻找并购买产品。但是这个功能出了故障–相当大的故障。我们的工作人员花了六个星期尝试确定问题的根源所在。这个任务非常复杂，因为我们的数据中心集成了太多的第三方软件。我们启动了一个新的客户端商务站点，可是直到交易量提升到一定程序后才再次发现这个问题，并且影响了我们整个网络结构。起初我们认为这是数据库的连接缓存的问题，是因为特定的应用引起的。

　　使用了应用服务建模之后，我们在24小时之内便跟踪到问题不仅出现在我们开发的系统中，第三方结构和应用中也有问题。这样我们的问题便解决了。这是一件非常有意义的事，因为我们花费了许多时间和供应商争论到底谁应该负责处理这个问题。服务建模可以让我们进行调整和测试、过度调整和测试，并同时监控能发挥其最佳性能的位置。要正确地实施SOA就需要一种准确的问题源诊断手段，在虚拟化和共享资源的环境下更是如此。

　　由于应用服务建模这种方式确实非常卓越，我们已经在我们国内外所有的业务关键的商务站点上采用了这种技术。目前已经实现的优势包括更短的修复周期、更高性能的应用服务、以及在面向服务的应用上的投资的更高回报。我们发现了可以提高主站商务应用代码质量的新方法，从而为我们带来更高的稳定性和运行性能。我们有一位SOA开发人员甚至相信如果能更早地使用应用服务建模，我们就能节省好几年的部署时间了(我没有开玩笑)。但是最重要的可能还是它可以帮助我们完成最主要的任务–通过更高的价值和更优的服务赢得业务伙伴的尊重和忠诚度。

　　总结

　　应用服务建模可以填补当前动态组合应用中的IT可视性空白。如果没有这种环境意义的可视性，就不可能有效地诊断使用不断变化中的多层中间件的企业应用中的应用服务问题。不管一个应用有多成熟或功能有多丰富，如果无法管理，那么它对企业的价值就是非常有限的。并且，一个IT运营团队必须了解应用逻辑才能有效地进行影响分析并预防可能产生的应用问题。通过在应用服务层对复杂的组合应用进行管理，IT组织可以最大程度地发挥应用的性能、减少分析问题的平均时间、并使生产效率最大化。为了使IT与业务取得一致并让企业从对组合应用的投资中取得预期的投资回报率，进而完成这”最后一英里”的任务，使用一种更成熟的方式是非常有必要的。