摘自我那本6月份要上市的，但目前名字還沒完全確定的書，由於書中涵蓋的更多的為構建高性能分布式Java應用所需要的基礎知識，也許改成了《通往高性能分布式Java應用之路》，摘取的這段內容主要是闡述下為什麼大型應用需要SOA，以及eBay的例子。
當應用獲得用戶的認可後，會不斷的發展，以豆瓣 為例，早期豆瓣只有書評的功能，隨著大家對豆瓣的認可以及使用的用戶越來越多，豆瓣發展到了今天的豆瓣社區、豆瓣讀書、豆瓣電影和豆瓣音樂等功能，這四個大塊的功能有各自的特色，但又有很多可公用的業務邏輯，例如用戶信息、評價等，如這四個系統都維護自己的用戶信息讀寫或評價業務邏輯，此時會造成的問題一方面是當需要修改評價邏輯時，所有系統有可能都需要修改，當需要修改用戶信息的讀取方式時，也是所有系統都需要修改，會相當的復雜；另一方面是每個系統上都有很多種類的業務邏輯，這就像在一個小超市中，一個人負責收銀、清潔、擺貨、咨詢等各種各樣的事情，當來超市買東西的人多了後，這個人就沒有辦法再負責這麼多的事情了，系統也同樣如此。
第一個現象為系統多元化後帶來的問題，可采用的方法為對共用邏輯的部分進行抽象，形成多個按領域劃分的共用業務邏輯系統；第二個現象為系統訪問量、數據量上漲後帶來的典型問題，當超市的顧客不斷增加時，通常超市會采取分工的方式來更好的服務顧客，同樣，對於系統而言，也會采取拆分系統的方式來解決。
在構建了共用業務邏輯系統和拆分系統後，最明顯的問題就是系統之間如何進行交互，如不做控制，會出現的現象是多個系統之間出現多種多樣的交互方式，Http、TCP/IP+NIO、Hessian、RMI、Webservice等；同步、異步等方式可能都會出現，這會導致開發人員在每訪問一個共用業務邏輯系統或拆分出來的系統後，都有可能要學習不同的交互方式；同時也會造成各開發團隊重復造輪子，提供不同交互方式用的框架，這對於應用的性能、可用性而言也帶來了極大的挑戰。
對於上面的問題，很容易想到的一種解決方法就是統一交互的方式，SOA無疑是實現這種方式的首選指導思想。
SOA全稱為面向服務架構，其強調系統之間以標准的服務方式進行交互，各系統可采用不同的語言、不同的框架進行實現，需要交互時則全部通過服務的方式來進行。
eBay也實現了一個SOA平台來支撐其業務的多元化發展 ，eBay認為SOA能給其帶來的最大好處為提升業務的重用以及靈敏性，SOA平台除了要實現統一的交互外，還會碰到其他多方面的挑戰，來看看eBay眼中SOA平台會帶來哪些挑戰：
服務多級調用帶來的延時；
當出現一個功能需要調用服務A，服務A又需要調用服務B，服務B又需要調用服務C時，這個時候會帶來大幅度的延時，解決延時需要做到的是高性能的服務交互，以及完善的服務調用過程控制，例如當調用在服務B執行時已超時，那麼則沒必要繼續調用服務C，而應該直接拋出超時異常給調用端。
調試/跟蹤困難
例如當調用服務A，服務A報錯時，調用者通常會去找服務A的開發人員來解決，服務A的開發人員去查問題，有可能會發現是由於服務B報錯，服務B的開發人員去查，有可能發現是網絡有問題，在這樣的情況下，就會導致出現問題時調試/跟蹤非常困難。
更高的安全/監測的要求
在未拆分系統時，對系統的安全和監測都只需要在一個系統上做即可，當拆分後，就必須在每個系統上都有相應的安全控制以及監測。
現有應用移植
這一點是SOA平台在推廣時的大挑戰，需要移植的應用上的功能越多，就需要花費越多的時間來完成移植。
QoS的支持
每個服務提供者能夠支撐的訪問量必然是有限的，因此設定服務的QoS非常重要，並且應盡可能采取一系列的措施來保障QoS，例如流量控制、機器資源分配等。
高可用和高度可伸縮
這是互聯網應用必須做到的兩點，SOA平台承擔了所有服務的交互，因此其可用性以及伸縮性就更會影響巨大。
多版本和依賴管理
隨著服務不斷發展，以及使用面不斷擴大，服務多版本的存在會成為一個大的需求，同時由於服務眾多，這些服務的依賴關系也需要管理起來，以便在升級時能進行相應的安排。
eBay根據這些挑戰自行實現了一個SOA平台，這個SOA平台主要包含了以下幾點：
高性能、可擴展的輕量級框架；
監測、安全控制、流量控制的支持；
服務注冊和服務倉庫；
開發工具；
在推行SOA平台時，eBay采取的為按領域驅動的方式劃分服務，同時不斷的培訓開發人員，以便讓開發人員明確服務化後和之前單系統的方式的區別，例如可能會產生網絡通信錯誤、超時等。
綜合上面的內容來看，對於一個大型應用中的SOA平台，至少應包含以下幾點功能：
統一的服務交互方式，並可實現和現有應用的無縫集成；
提供調試/跟蹤的支持；
依賴管理；
高性能以及高可用。
在實現SOA時，可參考的標准或概念有SCA、ESB，同時業界也有一些實現了SCA、ESB的框架，下面就來具體的看看SCA、ESB、SCA框架以及ESB框架。
