在QCon SF 2009的SOA分會場上，eBay的架構師講了一個SOA @
eBay的PPT，正好和我的工作有很多的交叉點，于是比較認真的看了下這個PPT，感興趣的同學可以從這里下載：http://qconsf.com/sf2009/file?path=/qcon-sanfran-2009/slides/SastryMalladi_SOAEBayHowIsItAHit.pdf，在這個PPT中可以看到eBay對于SOA的看法以及他們目前的做法，自己也是做這方面工作的，就在這篇blog中介紹下這個PPT以及自己對于SOA的一些看法。
先來介紹下這個PPT的內容，PPT內容主要分成以下幾部分：
1.
What is SOA
簡單來說，就是一種架構思想，有助于提升系統的重用性。
2.
SOA Benefits
提升業務的靈敏性，降低失敗需要付出的代價。
3.
SOA挑戰
l 由于服務多級調用帶來的延時；
l 調試/跟蹤問題困難；
l 需要高效的請求/會話級別的cache；
l 更高的安全/監測的要求；
l 現有應用移植；
l 部署和回滾；
l 演變階段新老技術的共存；
l QoS和SLA的支持；
l 集成測試；
l 高可用和高度可伸縮性；
l 版本和依賴管理。
4.
應對挑戰的措施
l 輕量、高性能的SOA平臺（自己寫+開源+商業）；
l 單元測試框架和服務虛擬化；
l 領域驅動的服務劃分方式；
l 支持REST風格；
l 服務生命周期管理；
l 增量的服務部署；
l 管理工具；
l 開發人員的培訓。
5.
eBay的SOA平臺
l 高性能、可擴展（pipeline方式）的輕量級框架；
l 監測、安全控制、流量限制；
l 服務注冊和服務倉庫；
l ESB；
l 業務流程引擎；
l 開發工具和管理工具。
6.
SOA治理
l 設計階段，接口和類型的review、確認，從而遵循約束；
l 運行階段，部署/安全/緩存/監測/可用性策略，并根據運行狀況和設計階段對比，看看是否符合設計；
l 變更管理，做到依賴或版本的變更不影響現有應用。
7.
eBay的SOA治理
l 服務倉庫，用于記錄服務元信息、生命周期信息以及消費者信息以及進行服務依賴的分析；
l 服務注冊，支持通過UDDI方式，主要用于路由；
l 基本實現6中SOA治理的設計階段、運行階段的要求。
8.
總結
最重要的為：服務層的規劃、版本和依賴的管理，目前eBay的SOA化正在進展中。
看完PPT，可以看出，eBay負責這個部分的架構師確實擁有不錯的全局觀，考慮到的點已經比較全面了，尤其是各種SOA平臺落地時會碰到的問題，按照這樣的控制讓eBay步入SOA化問題應該不大，技術方面而言，eBay的SOA平臺應該是基于http方式，實現同步和異步交互，另外就是有專門的開發工具和管理工具，這點是eBay的特色，平臺在發展初期就為開發人員的易用做出了充分的考慮，其他技術點看不太出來，希望以后能看到更多eBay SOA平臺技術細節的介紹，例如如何實現QoS、部署等，不過SOA，確實是各人有各人的想法，因此做出來都會有些差別，下面就按照這個PPT的結構講講自己的一些看法，J
1.
What is SOA
簡單來說，我認為SOA就是要做到系統內或系統間以標準的service方式進行交互。
2.
SOA Benefits
l 標準的交互方式
不管你需要的功能是以什么方式實現的、怎么部署的，都可以用一種統一的方式去發布服務、調用服務，避免出現調這個功能要用webservice、調另外個功能需要用hessian這樣的現象。
l 屏蔽交互細節
功能交互時同步還是異步、通信方式（調用的服務在哪、通信協議、數據交互協議等）是怎么樣的，開發人員都可以不用考慮，這將使得開發人員能更加專注于業務功能的實現。
l 功能重用
一個應用必然會有很多可公用的功能，如果沒有一種好的方式提供，搞不成就會折騰成這個系統里有一個類似的業務功能，另外個系統里也有一個，最后要維護起來就痛苦了，這個時候功能的重用就顯得非常的重要了。
l 對互聯網應用而言
性能、可用性、伸縮性問題可以更集中精力的去解決，同時也是在對應用進行劃分時產生的必須的基礎平臺，現在外部很多聲音是SOA死了嗎，但其實N多家互聯網公司就是SOA平臺的實現以及實施者，J
3.
SOA挑戰
l 通信方面的性能、可用性以及可伸縮性的挑戰，這是互聯網應用必須的，沒太多可說的；
l 服務路由，這點其實看要實現到什么程度，簡單的話就是個隨機或順序的地址選擇，復雜的話就是怎么樣才能選擇到最佳的服務目標地址，這里面就有很多學問了，這點貌似目前eBay還沒重視，不過以后它強調QoS的時候自然要考慮的，J；
l 給開發階段帶來的挑戰，主要是開發人員習慣的轉變，以及調試、查錯的復雜，一出問題會很難查問題到底在哪，畢竟有可能一個功能是跳了好幾個系統的，這點說起來貌似eBay做的不錯，這個在實施SOA平臺時會碰到很多麻煩；
l 多版本共存的挑戰，尤其是服務多了以后；
l 根據QoS有效分配服務資源，這個難度可想而知，之前貌似有看到過IBM的藍云的demo里貌似能做到；
l SOA平臺自身的可管理和升級，這個問題也會不小，隨著SOA平臺部署到所有的應用上，可想而知，要升級一次是什么概念；
l 服務粒度的掌控，這個是最難的，因為沒標準，eBay的那個領域驅動劃分聽起來貌似還行，但沒細節，也無法評判；
l 現有應用移植，這個基本都是共同的頭疼點，貌似基本上也沒什么好辦法，要的就是時間了。
4.
看重的SOA平臺的關鍵點
如果有一個現成的SOA平臺擺在我的面前，我想我最關注的是它在以下幾點的表現：
l Service的定義
這不用說，SOA平臺必備，但服務的定義至少應包括版本、擴展的服務屬性聲明等。
l 支持多種交互方式以及可擴展
這個基本也不用說，至少傳輸協議上多支持幾種、數據交互協議上也多支持幾種吧，還有就是交互方式，例如同步、異步等，不用說的就是還是要能擴展的，這樣實在不行就自己上了。
l 高性能、高可用、高度可伸縮
互聯網應用，沒什么說的，這三點是必須的，因此好歹要有個benchmark、有個網站應用的例子最好了，高度可伸縮嘛，至少SOA平臺本身不能成為伸縮路上的攔路者。
l 服務路由
服務路由，我自己還是很看重的，因為這對于做到按QoS來分配服務資源非常重要，否則就得應用自己折騰了。
l 強大的SOA治理
由于PPT上eBay把SOA治理單獨說了，我也單獨說吧，對我而言，強大的SOA治理也是重要的因素，主要是治理的很多基礎其實就是平臺要先做好的，否則平臺沒有，自己開發會發現根本沒法做，如果治理需要的基礎都有了，那難度是不大的。
5.
SOA治理
隨著服務的增多，治理會變得非常重要，簡單說說我對SOA治理的一些需求，J
l 服務依賴關系分析，這個現在已經成治理的基本話題了，所以不必多說；
l 服務運行狀況監測，至少要顯示下現在服務的響應時間、請求狀況吧；
l 服務路由調整，這是調整服務資源的重要手法；
l 服務流量控制，能適當控制下服務能接受的請求的上限，能給不同機器分配不同的流量；
l 服務請求的全程跟蹤，例如可以動態打開track，跟蹤其中例如執行失敗的某一條的全程，從而迅速判斷性能瓶頸、錯誤根源等，并可同時基于此來做請求的放棄以及響應的丟棄；
l 服務降級，降級這個貌似現在都成國外幾家互聯網公司的入門級武器了，所以沒得說，咱們也追隨下，J。
貌似現在商業的、開源的都還沒有這樣的吧，如果什么時候能出現個就好了，好歹也能去膜拜下，好了，我已羅嗦完畢，接下來就是大家的時間了，期待期待。