面向服務架構的思想在整個軟體的架構中已經不是什麼新鮮的東西。我簡單的認為服務化是模組化的延伸，所以服務化有著和模組化類似的優點和缺點。這裡不再討論這些服務定義服務與服務之間的通訊協議（像WSDL等等），我並不認為這是服務化的本質所在。即使Java語言用RMI進行服務與服務之間的通訊也仍然不違背服務化的宗旨。

一.為什麼需要面向服務架構

        1.我覺得面向服務的根本好處是便於管理，也是應用大到一定時候的必然產物。這往往和組織架構之間相契合。其實不合理的服務劃分也會帶來服務之間的混亂。

        2.面向服務是一個解耦的過程，鬆耦合降低了服務之間的依賴，也意味著服務一個服務出現故障的時候不容易引起連鎖反應，也能更好的控制服務與服務之間的關係與優先順序。

        3.不同語言之間的通訊。

二.面向服務架構的好處

        在為什麼要面向服務架構裡面已經講到了這樣的好處。這裡再舉一些簡單的例子來闡述。比如說一個應用部署在一臺機器上，然而不管如何優化單機是無法撐起整個應用。這時候有兩種思路。

        水平擴充套件，即整個應用作為一個整體，然後水平擴充套件到多臺機器上。

圖A

        服務拆分，這是解耦的過程，也符合軟體工程中“高內聚，低耦合”的思想。往往第一步會進行模組化。這樣做可能還不夠，我們需要讓它們能夠獨立生存。這樣一個大的服務“分裂”成一個一個比較小能夠獨立生成的服務，這裡的關鍵是可以獨立生存，意味著它們可以部署在不同的機器上，一定程度上達到了“分散式”的效果。

圖B

三.總結

        上面從兩個維度講到了機器擴充套件。這兩者在系統的拆分中會同時存在。從純效能的角度講應該採用第一種方案。兩第二種方案並不當作解決效能的總體方案。而主要從軟體管理的角度來講進行拆分。這種拆分使得整個業務的粒度越來越細，也會越來越好控制，保證每個服務的高內聚，有清晰的邊界。

        面向服務架構是一種思想，當然對於大系統而言其利必大於弊，而系統比較小的時候盲目的拆分和服務化其實會導致整個維護成本上升。系統架構並沒有一層不變的套路，也不必完全遵循某種模式。一切都在實際應用中結合具體的應用場景。應該說是“方法論”的具體產物。