【IT168 技术文章】
对于大部分公司来说，要保持竞争优势就要使用最新的技术。而实际上，对于部分公司来说，面向服务即是取得商务成功的支柱。作为一家财富百强公司的首席架构师，我在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了。这些工具无法对与特殊应用或处理相关的服务入口和出口进行操作。如果你有运行在三个不同服务器上的应用组件服务，那么你知道是哪一个负责处理与报价功能相关的运输管理呢？如果应用使用了中间件平台上的共享组件，这个问题会更难处理。这些逻辑工具为编码组件提供了可视性，但是它们却无法提供组件性能与所交付的应用服务性能的关系。
为什么这一点很重要呢？服务相关性是非常关键的，因为它可以为特定的服务或业务功能提供性能参数，然后根据服务相关性作出诊断并最优化应用的性能。企业应用恰恰是为了提供业务服务而存在的，因此如果性能上有问题或者共享应用组件所支持的某个特定的应用服务无法及时投入使用，那么应用的价值很快就会被停机、性能低下、以及与频繁维护相关的各种费用消耗所淹没。面向服务的应用的复杂性使性能的检测与调整、问题根源的追踪、和负载规划变得更加困难。
