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

　　1、所有團(tuán)隊(duì)的程序模塊都要以通過(guò)Service Interface 方式將其數(shù)據(jù)與功能開(kāi)放出來(lái)。

　　2、團(tuán)隊(duì)間的程序模塊的信息通信，都要通過(guò)這些接口。

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

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

　　5、所有的Service Interface，毫無(wú)例外，都必須從骨子里到表面上設(shè)計(jì)成能對(duì)外界開(kāi)放的。也就是說(shuō)，團(tuán)隊(duì)必須做好規(guī)劃與設(shè)計(jì)，以便未來(lái)把接口開(kāi)放給全世界的程序員，沒(méi)有任何例外。

　　6、不這樣的做的人會(huì)被炒魷魚(yú)。

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

　　Steve還提到：

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

　　那時(shí)，如果沒(méi)有被解雇的的恐懼他們一定不會(huì)去做。我是說(shuō)，他們今天仍然怕被解雇，因?yàn)檫@基本上是那兒每天的生活，為那恐怖的海盜頭子貝佐斯工作。不過(guò)，他們這么做的確是因?yàn)樗麄円呀?jīng)相信Service這就是正確的方向。他們對(duì)于SOA的優(yōu)點(diǎn)和缺點(diǎn)沒(méi)有疑問(wèn)，某些缺點(diǎn)還很大，也不疑問(wèn)。但總的來(lái)說(shuō)，這是正確的，因?yàn)�，SOA驅(qū)動(dòng)出來(lái)的設(shè)計(jì)會(huì)產(chǎn)生出平臺(tái)(Platform)。

　　今天，我們都知道亞馬遜從世界上最大圖書(shū)賣場(chǎng)進(jìn)化為了世界上最成功的云平臺(tái)……

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

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

　　SOA漫談：宏觀與微觀

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

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

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

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

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

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

　　SOA定義

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

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

　　String echo(String text);

　　}

　　public class EchoImpl implements Echo {

　　public String echo(String text) {

　　return text;

　　}

　　}

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

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

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

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

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

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

　　淺析松耦合原則

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

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

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

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

　　版本的松耦合：消費(fèi)端不需要依賴服務(wù)契約的某個(gè)特定版本來(lái)工作，這就要求服務(wù)的契約在升級(jí)時(shí)要盡可能的提供向下兼容性。

　　SOA與傳統(tǒng)軟件設(shè)計(jì)

　　我們可以認(rèn)為：SOA ≈ 模塊化開(kāi)發(fā) + 分布式計(jì)算

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

　　SOA原則的應(yīng)用

　　基于SOA的原則，也許我們很難說(shuō)什么應(yīng)用是絕對(duì)符合SOA的，但是卻能剔除明顯不符合SOA的應(yīng)用。

　　用上述標(biāo)準(zhǔn)化契約，松耦合和可重用這幾個(gè)原則來(lái)嘗試分析一下上面Echo示例：

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

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

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

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

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

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

　　public class EchoImpl implements Echo {

　　public String echo(String text) {

　　return text;

　　}

　　}

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

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

　　將一個(gè)普通的Java對(duì)象通過(guò)添加注解“透明的”變成WebServices就完成了從面向?qū)ο蟮矫嫦蚍��?wù)的跨越?

　　通過(guò)Java接口生成WSDL服務(wù)契約是好的方式嗎?

　　WebServices是最合適遠(yuǎn)程訪問(wèn)技術(shù)嗎?

　　面向?qū)ο蠛兔嫦蚍��?wù)的對(duì)比

　　面向?qū)ο?OO)和面向服務(wù)(SO)在基礎(chǔ)理念上有大量共通之處，比如都盡可能追求抽象、封裝和低耦合。

　　但SO相對(duì)于OO，又有非常不同的典型應(yīng)用場(chǎng)景，比如：

　　多數(shù)OO接口(interface)都只被有限的人使用(比如團(tuán)隊(duì)和部門內(nèi))，而SO接口(或者叫契約)一般來(lái)說(shuō)都不應(yīng)該對(duì)使用者的范圍作出太多的限定和假設(shè)(可以是不同部門，不同企業(yè)，不同國(guó)家)。還記得貝佐斯原則嗎?“團(tuán)隊(duì)必須做好規(guī)劃與設(shè)計(jì)，以便未來(lái)把接口開(kāi)放給全世界的程序員，沒(méi)有任何例外”。

　　多數(shù)OO接口都只在進(jìn)程內(nèi)被訪問(wèn)，而SO接口通常都是被遠(yuǎn)程調(diào)用。

　　簡(jiǎn)單講，就是SO接口使用范圍比一般OO接口可能廣泛得多。我們用網(wǎng)站打個(gè)比方：一個(gè)大型網(wǎng)站的web界面就是它整個(gè)系統(tǒng)入口點(diǎn)和邊界，可能要面對(duì)全世界的訪問(wèn)者(所以經(jīng)常會(huì)做國(guó)際化之類的工作)，而系統(tǒng)內(nèi)部傳統(tǒng)的OO接口和程序則被隱藏在web界面之后，只被內(nèi)部較小范圍使用。而理想的SO接口和web界面一樣，也是變成系統(tǒng)入口和邊界，可能要對(duì)全世界開(kāi)發(fā)者開(kāi)放，因此SO在設(shè)計(jì)開(kāi)發(fā)之中與OO相比其實(shí)會(huì)有很多不同。

　　小結(jié)

　　在前述比較抽象的SOA大原則的基礎(chǔ)上，我們可嘗試推導(dǎo)一些較細(xì)化和可操作的原則，在具體實(shí)踐中體現(xiàn)SO的獨(dú)特之處。請(qǐng)關(guān)注本系列文章的下篇! 

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標(biāo)題：微觀SOA：服務(wù)設(shè)計(jì)原則及其實(shí)踐方式（上篇）

本文網(wǎng)址：http://www.oesoe.com/html/consultation/10839316742.html