一直以來，看了很多東西自己知道就完了，而我覺得作為互聯網的一份子，應該懂得分享。
最近看了很多關于程立的一些演講，學習到了soa實踐中非常寶貴的經驗。
最開始支付寶架構是單應用系統，采用分層架構模式（展現層+業務層+持久層），用過分層架構模式的人都很清楚業務層是最關鍵的一層，也是最容易造成臃腫和龐大的一層，所以需要合理的分離。而最佳實踐應該是把業務層分為：facade層和業務邏輯層，也符合現在比較熱的領域模型驅動，業務邏輯層主要負責業務本身的實現，facade層區分產品功能和決策。對于中小型而且項目業務需求也不怎么變的應用來說，是比較合理的架構。無論從學習成本和人力成本來說，都相對較低。但是業務不斷擴張的應用來說，到最后開發成本和維護將會逐步提高。支付寶也是這個時候就開始著手對“對象”進行“組件”化，也就是接下來的第二個過程了。
從對象到組件化，我們首先要來看看組件這個概念。組件是功能職責相近類的集合。組件本身需要以下幾點功能：1、屬性 2、運行級別 3、引用 4、擴展 等。而那時比較符合支付寶這一思想的規范有osgi。具體關于osgi的相關內容可以自行google。如果用osgi會出現如下三個問題：
1、osgi平臺如何在tomcat，jboss下運行。（現在tomcat，jboss等應用服務器都已經支持了，以前需要自己來擴展tomcat）
2、osgi使用起來比較麻煩和復雜，如何跟spring整合起來使用也是需要解決的問題，不過spring就是spring，05左右好像就對這方面開始研究了，現在作為一個子項目（Spring Dynamic Modules）。
3、osgi規范沒有擴展這種功能，所以需要自己來對osgi的一些框架進行擴展，可以參照eclipse的一個osgi框架，或者也可以直接用此框架（Equinox）。
這些問題都解決了，那么“對象”進行“組件”過程就完成了。但是這個時候需要對企業內部的系統能夠配合起來，那么可以對業務層進行服務化。也就是第三個過程了。
把組件都以服務方式部署出來，同時也需要管理好這些服務，那么此時可以引入esb（企業服務總線）中間件了。商業的和開源的都有，支付寶用的是開源的mule，不過對于某些方面，支付寶進行改造過，為了確保消息能夠百分百不丟失，畢竟跟錢打交道嘛需要嚴謹。
其實這些基礎平臺搭建好后，還需要解決一個特別難的難題。功能服務化后，數據庫也不再是集中式了，本地事務也不能保證了。這個時候需要引入分布式事務，數據庫軟件本身也提供分布式事務，但是對于需要高訪問量和高性能的網站來說，可能需要換一種方式了。cap和base理論告訴我們可以適當放棄強一致性來達到其他兩項性能。ws-transaction是分布式中間件，但是完成一個事務需要很多消息來溝通，至少大大增大了事務的中間過程會被中斷掉。支付寶公司研究出了一些分布式事務模式，比如冪等性模式，補償性模式，tcc模式等等。每個模式都有不同的應用場景，大家可以根據自己的業務特點來進行選取。
以上即是我最近學習的一些總結。讓更多的人能學習好的技術和經驗。讓我們一起來分享吧。