在QCon SF 2009的SOA分会场上，eBay的架构师讲了一个SOA @ eBay的PPT，http://qconsf.com/sf2009/file?path=/qcon-sanfran-2009/slides/SastryMalladi_SOAEBayHowIsItAHit.pdf ，在这个PPT可以看到eBay对于SOA的看法以及他们目前的做法.。先来介绍下这个PPT的内容，PPT内容主要分成以下几部分： 简单来说，就是一种架构思想，有助于提升系统的重用性。
SOA是一种应用程序体系结构的演变，而不是技术革命
 

2.         SOA Benefits

提升业务的灵敏性，降低失败需要付出的代价。

3.         SOA挑战

  • 由于服务多级调用带来的延时；
  • 调试/跟踪问题困难；
  • 需要高效的请求/会话级别的cache；
  • 更高的安全/监测的要求；
  • 现有应用移植；
  • 部署和回滚；
  • 演变阶段新老技术的共存；
  • QoS和SLA的支持；
  • 集成测试；
  • 高可用和高度可伸缩性；
  • 版本和依赖管理。

4.         应对挑战的措施

  • 轻量、高性能的SOA平台（自己写+开源+商业）；
  • 单元测试框架和服务虚拟化；
  • 领域驱动的服务划分方式；
  • 支持REST风格；
  • 服务生命周期管理；
  • 增量的服务部署；
  • 管理工具；
  • 开发人员的培训。

5.         eBay的SOA平台

  • 高性能、可扩展（pipeline方式）的轻量级框架；
  • 监测、安全控制、流量限制；
  • 服务注册和服务仓库；
  • ESB；
  • 业务流程引擎；
  • 开发工具和管理工具。

6.         SOA治理

  • 设计阶段，接口和类型的review、确认，从而遵循约束；
  • 运行阶段，部署/安全/缓存/监测/可用性策略，并根据运行状况和设计阶段对比，看看是否符合设计；
  • 变更管理，做到依赖或版本的变更不影响现有应用。

7.         eBay的SOA治理

  • 服务仓库，用于记录服务元信息、生命周期信息以及消费者信息以及进行服务依赖的分析；
  • 服务注册，支持通过UDDI方式，主要用于路由；
  • 基本实现6中SOA治理的设计阶段、运行阶段的要求。

 8.         总结

最重要的是：服务层的规划、版本和依赖的管理，目前eBay的SOA化正在进展中。

看完PPT，可以看出，eBay负责这个部分的架构师确实拥有不错的全局观，考虑到的点已经比较全面了，尤其是各种SOA平台落地时会碰到的问题，按照这样的控制让eBay步入SOA化问题应该不大，技术方面而言，eBay的SOA平台应该是基于http方式，实现同步和异步交互，另外就是有专门的开发工具和管理工具，这点是eBay的特色，平台在发展初期就为开发人员的易用做出了充分的考虑，其他技术点看不太出来，希望以后能看到更多eBay SOA平台技术细节的介绍，例如如何实现QoS、部署等，不过SOA，确实是各人有各人的想法，因此做出来都会有些差别，下面就按照这个PPT的结构讲讲自己的一些看法


1.         What is SOA

简单来说，我认为SOA就是要做到系统内或系统间以标准的service方式进行交互。

2.         SOA Benefits

  1. 标准的交互方式----不管你需要的功能是以什么方式实现的、怎么部署的，都可以用一种统一的方式去发布服务、调用服务，避免出现调这个功能要用webservice、调另外个功能需要用hessian这样的现象。
  2. 屏蔽交互细节-----功能交互时同步还是异步、通信方式（调用的服务在哪、通信协议、数据交互协议等）是怎么样的，开发人员都可以不用考虑，这将使得开发人员能更加专注于业务功能的实现。
  3. 功能重用-----一个应用必然会有很多可公用的功能，如果没有一种好的方式提供，搞不成就会折腾成这个系统里有一个类似的业务功能，另外个系统里也有一个，最后要维护起来就痛苦了，这个时候功能的重用就显得非常的重要了。
  4. 对互联网应用而言-----性能、可用性、伸缩性问题可以更集中精力的去解决，同时也是在对应用进行划分时产生的必须的基础平台，现在外部很多声音是SOA死了吗，但其实N多家互联网公司就是SOA平台的实现以及实施者，SOA是一种应用程序体系结构的演变，而不是技术革命

3.         SOA挑战

  1. 通信方面的性能、可用性以及可伸缩性的挑战，这是互联网应用必须的，没太多可说的；
  2. 服务路由，这点其实看要实现到什么程度，简单的话就是个随机或顺序的地址选择，复杂的话就是怎么样才能选择到最佳的服务目标地址，这里面就有很多学问了，这点貌似目前eBay还没重视，不过以后它强调QoS的时候自然要考虑的。
  3. 给开发阶段带来的挑战，主要是开发人员习惯的转变，以及调试、查错的复杂，一出问题会很难查问题到底在哪，毕竟有可能一个功能是跳了好几个系统的，这点说起来貌似eBay做的不错，这个在实施SOA平台时会碰到很多麻烦；
  4. 多版本共存的挑战，尤其是服务多了以后； 根据QoS有效分配服务资源，这个难度可想而知，之前貌似有看到过IBM的蓝云的demo里貌似能做到； SOA平台自身的可管理和升级，这个问题也会不小，随着SOA平台部署到所有的应用上，可想而知，要升级一次是什么概念；
  5. 服务粒度的掌控，这个是最难的，因为没标准，eBay的那个领域驱动划分听起来貌似还行，但没细节，也无法评判； 现有应用移植，这个基本都是共同的头疼点，貌似基本上也没什么好办法，要的就是时间了。

4.         看重的SOA平台的关键点

如果有一个现成的SOA平台摆在我的面前，我想我最关注的是它在以下几点的表现：
  1. Service的定义---这不用说，SOA平台必备，但服务的定义至少应包括版本、扩展的服务属性声明等。
  2. 支持多种交互方式以及可扩展---这个基本也不用说，至少传输协议上多支持几种、数据交互协议上也多支持几种吧，还有就是交互方式，例如同步、异步等，不用说的就是还是要能扩展的，这样实在不行就自己上了。
  3. 高性能、高可用、高度可伸缩---互联网应用，没什么说的，这三点是必须的，因此好歹要有个benchmark、有个网站应用的例子最好了，高度可伸缩嘛，至少SOA平台本身不能成为伸缩路上的拦路者。
  4. 服务路由---服务路由，我自己还是很看重的，因为这对于做到按QoS来分配服务资源非常重要，否则就得应用自己折腾了。
  5. 强大的SOA治理----由于PPT上eBay把SOA治理单独说了，我也单独说吧，对我而言，强大的SOA治理也是重要的因素，主要是治理的很多基础其实就是平台要先做好的，否则平台没有，自己开发会发现根本没法做，如果治理需要的基础都有了，那难度是不大的。

5.         SOA治理

随着服务的增多，治理会变得非常重要，简单说说我对SOA治理的一些需求，SOA是一种应用程序体系结构的演变，而不是技术革命
  1. 服务依赖关系分析，这个现在已经成治理的基本话题了，所以不必多说；
  2. 服务运行状况监测，至少要显示下现在服务的响应时间、请求状况吧；
  3. 服务路由调整，这是调整服务资源的重要手法；
  4. 服务流量控制，能适当控制下服务能接受的请求的上限，能给不同机器分配不同的流量；
  5. 服务请求的全程跟踪，例如可以动态打开track，跟踪其中例如执行失败的某一条的全程，从而迅速判断性能瓶颈、错误根源等，并可同时基于此来做请求的放弃以及响应的丢弃；
  6. 服务降级SOA是一种应用程序体系结构的演变，而不是技术革命，降级这个貌似现在都成国外几家互联网公司的入门级武器了，所以没得说，咱们也追随下.
貌似现在商业的、开源的都还没有这样的吧，如果什么时候能出现个就好了，好歹也能去膜拜下，好了，我已罗嗦完毕，接下来就是大家的时间了，期待期待。

—本文转自“BlueDavy之技术博客”[email protected]读后感