由于SOA有相當?shù)碾y度和門檻，不妨先從一個小故事說起，從中可以管窺一點SOA的大意和作用。按照亞馬遜前著名員工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO貝佐斯就在亞馬遜強制推行了以下六個原則：

　　1、所有團隊的程序模塊都要以通過Service Interface 方式將其數(shù)據(jù)與功能開放出來。

　　2、團隊間的程序模塊的信息通信，都要通過這些接口。

　　3、除此之外沒有其它的通信方式。其他形式一概不允許：不能使用直接鏈結(jié)程序、不能直接讀取其他團隊的數(shù)據(jù)庫、不能使用共享內(nèi)存模式、不能使用別人模塊的后門、等等，等等，唯一允許的通信方式只能是能過調(diào)用 Service Interface。

　　4、任何技術(shù)都可以使用。比如：HTTP、Corba、Pubsub、自定義的網(wǎng)絡協(xié)議、等等，都可以，貝佐斯不管這些。

　　5、所有的Service Interface，毫無例外，都必須從骨子里到表面上設計成能對外界開放的。也就是說，團隊必須做好規(guī)劃與設計，以便未來把接口開放給全世界的程序員，沒有任何例外。

　　6、不這樣的做的人會被炒魷魚。

　　據(jù)說，亞馬遜網(wǎng)站展示一個產(chǎn)品明細的頁面，可能要調(diào)用200-300個Service，以便生成高度個性化的內(nèi)容。

　　Steve還提到：

　　Amazon已經(jīng)把文化轉(zhuǎn)變成了“一切以Service第一”為系統(tǒng)架構(gòu)的公司，今天，這已經(jīng)成為他們進行所有設計時的基礎(chǔ)，包括那些絕不會被外界所知的僅在內(nèi)部使用的功能。

　　那時，如果沒有被解雇的的恐懼他們一定不會去做。我是說，他們今天仍然怕被解雇，因為這基本上是那兒每天的生活，為那恐怖的海盜頭子貝佐斯工作。不過，他們這么做的確是因為他們已經(jīng)相信Service這就是正確的方向。他們對于SOA的優(yōu)點和缺點沒有疑問，某些缺點還很大，也不疑問。但總的來說，這是正確的，因為，SOA驅(qū)動出來的設計會產(chǎn)生出平臺(Platform)。

　　今天，我們都知道亞馬遜從世界上最大圖書賣場進化為了世界上最成功的云平臺……

　　貝佐斯的六原則展示出高度的遠見和超強的信念，即使放到十幾年后的今天，依然覺得振聾發(fā)聵……想起一句老話：“不謀萬世者，不足以謀一時;不謀全局者，不足以謀一隅。”

　　當然，像貝佐斯這種將神性與魔性集于一身的專橫人物，既可能創(chuàng)造劃時代的進步，也可能制造前所未有的災難。

　　SOA漫談：宏觀與微觀

　　SOA即面向服務架構(gòu)，是一個特別大的話題。為了方便討論，我在此先草率的將SOA分為兩個層面(大概模仿宏觀和微觀經(jīng)濟學，但這里的劃分沒有絕對界限)：

　　宏觀SOA：面向高層次的部門級別、公司級別甚至行業(yè)級別;涉及商業(yè)、管理、技術(shù)等方面的綜合的、全局的考慮;架構(gòu)體系上包括服務治理(governance，如服務注冊，服務監(jiān)控)，服務編排(orchestration，如BPM，ESB)，服務協(xié)同(choreography，更多面向跨企業(yè)集成)等等。我認為SOA本身最主要是面向宏觀層面的架構(gòu)，其帶來益處也最能在宏觀高層次上體現(xiàn)出來，同時大部分SOA的業(yè)界討論也集中在這方面。

　　微觀SOA：面向有限的、局部的團隊和個人;涉及獨立的、具體的服務在業(yè)務、架構(gòu)、開發(fā)上的考慮。

　　很多業(yè)界專家都認為SOA概念過于抽象，不接地氣，我認為主要是宏觀SOA涉及面太廣，經(jīng)常需要做通盤考慮，而其中很多方面距離一般人又比較遠。而在微觀層面的SOA更容易達到濤哥過去提出的“三貼近”：貼近實際、貼近生活、貼近群眾。

　　同時，宏觀SOA要取得成功，通常的前提也是SOA在微觀層面的落地與落實，正如宏觀經(jīng)濟學一般要有堅實的微觀基礎(chǔ)(比如大名鼎鼎的凱恩斯主義曾廣受詬病的一點就是缺乏微觀基礎(chǔ))

　　因此，我們著眼于SOA落地的目的，著重來分析微觀SOA，也算是對業(yè)界主流探討的一個小小的補充。

　　SOA定義

　　按照英文維基百科定義：SOA是一種“軟件”和“軟件架構(gòu)”的設計模式(或者叫設計原則)。它是基于相互獨立的軟件片段要將自身的功能通過“服務”提供給其他應用。

　　什么是“服務”?按照OASIS的定義：Service是一種按照既定“接口“來訪問一個或多個軟件功能的機制(另外這種訪問要符合“服務描述”中策略和限制)Service示例(代碼通常以java示例)public interface Echo {

　　String echo(String text);

　　}

　　public class EchoImpl implements Echo {

　　public String echo(String text) {

　　return text;

　　}

　　}

　　可能每個開發(fā)人員每天都在寫類似的面向?qū)ο蟮腟ervice，難道這就是在實施SOA嗎?

　　SOA設計原則既然SOA是設計原則(模式)，那么它包含哪些內(nèi)容呢?事實上，這方面并沒有最標準的答案，多數(shù)是遵從著名SOA專家Thomas Erl的歸納：

　　標準化的服務契約 Standardized service contract 服務的松耦合 Service loose coupling 服務的抽象 Service abstraction 服務的可重用性 Service reusability 服務的自治性 Service autonomy 服務的無狀態(tài)性 Service statelessness 服務的可發(fā)現(xiàn)性 Service discoverability 服務的可組合性 Service composability ....

　　這些原則總的來說要達到的目的是：提高軟件的重用性，減少開發(fā)和維護的成本，最終增加一個公司業(yè)務的敏捷度。

　　但是，業(yè)界著名專家如Don Box，David Orchard等人對SOA又有各自不同的總結(jié)和側(cè)重。

　　SOA不但沒有絕對統(tǒng)一的原則，而且很多原則本身的內(nèi)容也具備相當模糊性和寬泛性：例如，所謂松耦合原則需要松散到什么程度才算是符合標準的呢?這就好比一個人要帥到什么程度才算是帥哥呢?一棟樓要高到多少米才算是高樓呢?可能不同人心中都有自己的一桿秤……部分由于這些理論上的不確定因素，不同的人理解或者實施的SOA事實上也可能有比較大的差別。

　　淺析松耦合原則

　　SOA原則比較多，真正的理解往往需要逐步的積累和體會，所以在此不詳細展開。這里僅以服務的松耦合為例，從不同維度來簡單剖析一下這個原則，以說明SOA原則內(nèi)涵的豐富性：

　　實現(xiàn)的松耦合：這是最基本的松耦合，即服務消費端不需要依賴服務契約的某個特定實現(xiàn)，這樣服務提供端的內(nèi)部變更就不會影響到消費端，而且消費端未來還可以自由切換到該契約的其他提供方。

　　時間的松耦合：典型就是異步消息隊列系統(tǒng)，由于有中介者(broker)，所以生產(chǎn)者和消費者不必在同一時間都保持可用性以及相同的吞吐量，而且生產(chǎn)者也不需要馬上等到回復。

　　位置的松耦合：典型就是服務注冊中心和企業(yè)服務總線(ESB)，消費端完全不需要直接知道提供端的具體位置，而都通過注冊中心來查找或者服務總線來路由。

　　版本的松耦合：消費端不需要依賴服務契約的某個特定版本來工作，這就要求服務的契約在升級時要盡可能的提供向下兼容性。

　　SOA與傳統(tǒng)軟件設計

　　我們可以認為：SOA ≈ 模塊化開發(fā) + 分布式計算

　　將兩者傳統(tǒng)上的最佳實踐結(jié)合在一起，基本上可以推導出SOA的多數(shù)設計原則。SOA從軟件設計(暫不考慮業(yè)務架構(gòu)之類)上來講，自身的新東西其實不算很多。

　　SOA原則的應用

　　基于SOA的原則，也許我們很難說什么應用是絕對符合SOA的，但是卻能剔除明顯不符合SOA的應用。

　　用上述標準化契約，松耦合和可重用這幾個原則來嘗試分析一下上面Echo示例：

　　Echo的服務契約是用Java接口定義，而不是一種與平臺和語言無關(guān)的標準化協(xié)議，如WSDL，CORBA IDL。當然可以抬杠，Java也是行業(yè)標準，甚至全國牙防組一致認定的東西也是行業(yè)標準。

　　Java接口大大加重了與Service客戶端的耦合度，即要求客戶端必須也是Java，或者JVM上的動態(tài)語言(如Groovy、Jython)等等……

　　同時，Echo是一個Java的本地接口，就要求調(diào)用者最好在同一個JVM進程之內(nèi)……

　　Echo的業(yè)務邏輯雖然簡單獨立，但以上技術(shù)方面的局限就導致它無法以后在其他場合被輕易重用，比如分布式環(huán)境，異構(gòu)平臺等等。因此，我們可以認為Echo并不太符合SOA的基本設計原則。

　　透明化的轉(zhuǎn)向SOA?

　　修改一下上面的Echo，添加Java EE的注解

　　public class EchoImpl implements Echo {

　　public String echo(String text) {

　　return text;

　　}

　　}

　　現(xiàn)在將Echo發(fā)布為Java WebServices，并由底層框架自動生成WSDL來作為標準化的服務契約，這樣就能與遠程的各種語言和平臺互操作了，較好的解決了上面提到的松耦合和可重用的問題。按照一般的理解，Echo似乎就成為比較理想的SOA service了。

　　但是……即使這個極端簡化的例子，也會引出不少很關(guān)鍵的問題，它們決定SOA設計開發(fā)的某些難度：

　　將一個普通的Java對象通過添加注解“透明的”變成WebServices就完成了從面向?qū)ο蟮矫嫦蚍�務的跨�?

　　通過Java接口生成WSDL服務契約是好的方式嗎?

　　WebServices是最合適遠程訪問技術(shù)嗎?

　　面向?qū)ο蠛兔嫦蚍�務的對�?/strong>