實施SOA的認識與心得 SOA架構
關鍵字：SOA 認識 心得
自05年開始接觸到分布式架構，06年在原先的基礎上從頭開始設計了一套分布式架構，當時SOA這個概念也沒這么火。整個大平臺的開發、性能和可擴展性都得到了考驗，覺得有一些東西想和大家一起分享。
我不知道我所說的這些算不算真正的SOA，我也沒讀過什么SOA的書籍，我覺得SOA這個概念非常抽象，任何概念的產生都是由原因的。因此，我也不會說一些抽象的原則，只是想說一些在過去幾年實施“SOA”過程中的一些心得和一些細節，希望對大家有用。
不說什么是SOA，先來說說我們現有架構遇到的一些問題：
同樣一個邏輯，A系統(ASP)使用COM實現一份(我們現在的JAVA庫)，B系統(.NET)在開發的時候覺得調用JAVA也是很麻煩的，索性自己實現一份邏輯，可能是存儲過程，也可能是在代碼中硬編碼SQL，C系統(由系統部門開發的.NET程序)也用到了相同的邏輯，由于和產品部門缺乏必要的溝通，也實現了一份邏輯。最后，如果這個相同的邏輯需要修改，則需要修改A、B、C三個系統，一份邏輯在三個地方實施有幾個缺點，一來是因為如果需要修改要改三個地方，二來是增加了工作量，三來是占用了不必要的資源(因為大家可能都實現了自己的緩存)。
所有網站全部部署在一個WEB服務器上，直接實現負載均衡。這樣的方案有幾個缺點，一是幾乎沒一個網站程序都有自己的緩存，每臺服務器的緩存是冗余的，而且甚至每個網站中的緩存都有重復，二是如果一個網站有問題會影響到其它網站(比如進程回收，應用程序池不能100%解決這個問題，而且我們現在并沒有注重應用程序池的劃分，又比如某些應用是長請求、過長時間占用線程)，三是不能有效利用服務器資源，這是因為不是每一個網站都具有相同的訪問量，不是每一個網站都需要相同的資源(有些需要特別多IO、有些需要特別多CPU、有些甚至是內存)。
雖然說我們現在是使用了三層架構，但并沒有什么重用，而且所有的層還是部署在相同的服務器上的。為了解決前面的2大問題，我們首先想到了：
是不是有什么方法可以讓相同的邏輯被其它系統重用?
是不是考慮把邏輯以服務的形式對外部(其他模塊)公開?
由此引入面向服務架構的概念，我們通過這些公開的服務進行邏輯的重用，提高系統性能也降低了模塊之間的耦合性。架構圖見我以前寫的文章http://www.cnblogs.com/lovecherry/archive/2008/06/18/1224496.html
如果確實采用這種架構，我們的開發方式會有什么改變呢?
在一般情況下，我們一般認為A系統對應A數據庫，B系統對應B數據庫，每一個系統都有自己的數據庫。傳統的方式是A系統和B系統在數據庫端直接使用JOIN進行交叉耦合。如果實施SOA的話，最佳實踐應該是對于大多數系統來說，禁止A系統直接訪問B系統的數據庫，反之亦然。我要你的數據，就必須調用你公開的服務。而且這個服務或者說接口或者說契約，盡量是粗粒度的。比如一個邏輯包括X和Y和Z三個過程，如果獨立提供三個方法的話，每一次方法調用都是網絡調用的過程，性能比較低，而且更重要的原因，這個模塊提供了這么細粒度的三個方法，如果這三個構成了一定邏輯的話，很有可能這個邏輯就在調用方和提供方兩個模塊都實現了相同的邏輯。雖然說確實是提供了服務，但是沒有達到封裝邏輯這個重要的目的，而且也產生了性能的下降，這種服務就顯得很不值得。
一個大系統有許多模塊或者說子系統，每一個都有自己的復雜邏輯和存儲結構。開發人員可能只熟悉自己的那一部分，如果我的系統確實要用到其它系統的數據，按道理是應該想到調用它提供的程序集。很多時候我們并沒有這么做，是因為我們并不知道對方有沒有提供我需要的功能，即使知道提供了也不知道怎么去使用，如果要去用的話可能熟悉對方系統的時間會比直接在數據庫中進行JOIN需要的時間還要長。這是一種惡性循環，因為這樣又導致了一個邏輯在多處出現，一份數據在多處取得、保存和緩存。有了SOA，我們應該能在SHAREPOINT或WIKI上看到一份清單，在哪個HTTP或TCP端點上具有什么服務，服務中有哪些方法，這些方法是干什么的，返回什么，傳入什么，使用的注意事項，如果我開發的系統需要用到外部的數據，我第一時間想到的不應該是去看數據庫中我需要的數據在哪里，而是應該是去看看是否對方系統提供了這樣的服務，如果沒有提供的話則和服務的提供者進行一些溝通。你可能會問，我作為系統的開發者，我也不知道要對外提供哪些服務，我也不知道別人需要用到什么，確實是，但是至少我們現在可以做的是把內部使用到的一些邏輯以服務形式對外公開，一般來說自己系統的這些函數如果能滿足自己要求的話從功能上來說可以滿足別人要求，只不過別人可能需要的并不是這么多罷了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/