【編者按】本文作者為 Matt McLarty，通過介紹 SOA 的興衰變化，總結(jié)了微服務(wù)應(yīng)該借鑒的5條經(jīng)驗(yàn)教訓(xùn)。文章系國(guó)內(nèi) ITOM 管理平臺(tái) OneAPM 編譯呈現(xiàn)。
SOA 的興衰變化讓我們更了解如何充分利用微服務(wù)
正如筆者在上文《微服務(wù)架構(gòu)是敏捷軟件架構(gòu)》中提到的，筆者對(duì)微服務(wù)架構(gòu)的第一反應(yīng)，就是質(zhì)疑它跟面向服務(wù)架構(gòu)（SOA）有何區(qū)別。還有很多人將這兩種架構(gòu)聯(lián)系在一起。詹姆斯·劉易斯和馬丁·福勒在他們的權(quán)威博客中包含了一個(gè)側(cè)邊欄，進(jìn)行微服務(wù)和 SOA 的對(duì)比。對(duì)此，懷疑派做出的回應(yīng)是二者之間并無不同。實(shí)際上，在“微服務(wù)”這個(gè)名詞出現(xiàn)之前，使用微服務(wù)的亞馬遜和 Netflix 都談到它們使用的是面向服務(wù)的架構(gòu)。兩年多之后，關(guān)于微服務(wù)架構(gòu)是不是 SOA 的爭(zhēng)辯帶來了大量的文章。
為什么人們這么熱衷于對(duì)比微服務(wù)和 SOA，而且還投入這么大的激情？雖然微服務(wù)和 SOA 在很多層面上可以相互區(qū)分——架構(gòu)風(fēng)格、實(shí)施案例、相關(guān)技術(shù)——但是它們?cè)诩夹g(shù)發(fā)展全景中起到了同樣驚人的作用。它們都有望轉(zhuǎn)變整個(gè)格局，而且都成功吸引了一大批擁護(hù)者。簡(jiǎn)單來說，微服務(wù)和 SOA 都以架構(gòu)開始，但是最終都成了一場(chǎng)運(yùn)動(dòng)。
可惜啊，現(xiàn)在 SOA 在 IT 業(yè)內(nèi)基本上被視為一場(chǎng)失敗的運(yùn)動(dòng)，而很多為它投入時(shí)間、金錢和精力的人的傷痛依然清晰可見。這就是為什么大家有這么大的熱情來對(duì)比較微服務(wù)和 SOA。要想了解微服務(wù)與 SOA 辯論的背景，回顧 SOA 運(yùn)動(dòng)的歷史非常重要：它的動(dòng)力是什么，以及最終導(dǎo)致失敗的原因是什么。
SOA 的興衰
1996年,高德納公司的分析員 Roy Schulte對(duì)面向服務(wù)架構(gòu)做出了如下定義：
面向服務(wù)架構(gòu)是一種多層信息處理技術(shù)，能幫助企業(yè)在多個(gè)應(yīng)用和使用模式之間分享邏輯和數(shù)據(jù)。
雖然 SOA 很早就獲得了這個(gè)定義，直到2002年，網(wǎng)絡(luò)服務(wù)出現(xiàn)之后，SOA 才在行業(yè)內(nèi)得到廣泛應(yīng)用。盡管 SOAP/XML 的初衷是為完全不同的企業(yè)之間提供服務(wù)器到服務(wù)器的網(wǎng)絡(luò)溝通，它們很快就被企業(yè)架構(gòu)師們選擇使用，他們一直在評(píng)估將網(wǎng)絡(luò)作為新渠道、并操控新技術(shù)的方法。作為一種連接應(yīng)用、互聯(lián)網(wǎng)友好、預(yù)計(jì)能節(jié)省大量開支的方法，網(wǎng)絡(luò)服務(wù)在這些企業(yè)中迅速風(fēng)靡。這種方法被貼上了“面向服務(wù)架構(gòu)”的標(biāo)簽，SOA 運(yùn)動(dòng)就此誕生。
隨著 SOA 運(yùn)動(dòng)的興起，一個(gè)新的集成模式出現(xiàn)了，用于推動(dòng) SOA 松散的連接原則：企業(yè)服務(wù)總線（ESB）。很多人現(xiàn)在已經(jīng)忘了 ESB 模式旨在輕便、無處不在，這與當(dāng)時(shí)通用的軸輻式企業(yè)應(yīng)用集成（EAI）是截然不同的。實(shí)際上，ESB 概念本身就是為了應(yīng)對(duì) EAI 代理的整體式特征帶來的問題而生的，例如軟件交付變慢，過于依賴其他團(tuán)隊(duì)以及可管理性太差等。
最初的 ESB 部署版本是個(gè)恰當(dāng)?shù)?a target="_blank" rel="nofollow">集成協(xié)作服務(wù)節(jié)點(diǎn)的網(wǎng)絡(luò)，讓人聯(lián)想到微服務(wù)運(yùn)動(dòng)采用的“智能端點(diǎn)啞管道（smart endpoints and dumb pipes）”原則。然而，隨著 ESB 的理念得到更加廣泛的使用，它引發(fā)了一個(gè)新的含義。2002年高德納公司預(yù)言 ESB 模式將在2005年被絕大多數(shù)公司采用，軸輻式 EAI 中間件的代理商們得以說服很多業(yè)內(nèi)人士，ESB 不是一種模式，而是用于企業(yè)軟件集成的一個(gè)中間件產(chǎn)品。他們把 EAI 代理產(chǎn)品包裝成 EBS，消費(fèi)者們還真的愿意買賬。
正如高德納公司的預(yù)言，到了2005年，實(shí)施 EBS 成了必不可少的事。IT 公司成立了集中的交付部門來管理 EBS 基礎(chǔ)架構(gòu)，并且參與公司各部門的集成項(xiàng)目。ESB 為那些主張 SOA 的企業(yè)架構(gòu)師提供了改造應(yīng)用環(huán)境任務(wù)的立足點(diǎn)。他們利用這個(gè)立足點(diǎn)要實(shí)現(xiàn)兩個(gè)目的：控制和保持一致性。
SOA 項(xiàng)目領(lǐng)導(dǎo)為控制需求辯護(hù)的理由是要確保那些支撐企業(yè)商業(yè)目標(biāo)的服務(wù)的開發(fā)和使用。這就催生了 SOA 管理的分支運(yùn)動(dòng)，由此誕生了自有軟件產(chǎn)品類別。建立一致性的努力包括嘗試定義標(biāo)準(zhǔn)的企業(yè)數(shù)據(jù)模式，還有一套擴(kuò)展的代理導(dǎo)向標(biāo)準(zhǔn)（總體的網(wǎng)絡(luò)服務(wù)），旨在減少網(wǎng)絡(luò)服務(wù)平臺(tái)之間的內(nèi)部操作。技術(shù)模板、規(guī)范標(biāo)準(zhǔn)、集中的命令和控制文化，所有這些都讓本該輕量化的 EAI 替代者越來越沉重。SOA 迷失了發(fā)展方向。
SOA 的設(shè)計(jì)初衷是加速項(xiàng)目交付，提高 IT 敏捷性，減少集成成本。然而，SOA 使用者，也就是使用發(fā)展到現(xiàn)在的 SOA 的人們，發(fā)現(xiàn)它實(shí)際上帶來了更多復(fù)雜性和瓶頸，而且部署 SOA 基礎(chǔ)構(gòu)架的費(fèi)用（基于 ESB、注冊(cè)和服務(wù)平臺(tái)模板）過多。
到了2009年，人們不再質(zhì)疑 SOA 方法，而是直接棄用。RESTful Web API——一種連接網(wǎng)絡(luò)有機(jī)進(jìn)化的應(yīng)用的方式——作為 SOAP 服務(wù)的輕量級(jí)備選出現(xiàn)了。云架構(gòu)的分布式本質(zhì)對(duì)集中的 ESB 拓?fù)浒仓檬莻€(gè)挑戰(zhàn)。從公司層面和文化層面來說，敏捷運(yùn)動(dòng)在促進(jìn)分散化和團(tuán)隊(duì)自治。這些因素加起來，和其他因素一起讓 SOA 退出了主流。
SOA 經(jīng)驗(yàn)教訓(xùn)
討論微服務(wù)和 SOA 是否相同是個(gè)錯(cuò)誤的問題。那有什么關(guān)系呢？正確的問題應(yīng)該是問微服務(wù)運(yùn)動(dòng)能夠從 SOA 借鑒什么。出了什么問題？以下是五條重要的經(jīng)驗(yàn)教訓(xùn)。
堅(jiān)守目標(biāo)。SOA 運(yùn)動(dòng)在偏離了最初的增加敏捷性和降低成本的目標(biāo)之后，偏離了正途。實(shí)施者們過度關(guān)注 SOA 的技術(shù)，忽略了他們?cè)噲D解決的商業(yè)問題。2009年發(fā)布的 SOA 宣言只是對(duì)主流 SOA 運(yùn)動(dòng)做出的回應(yīng)，而不是它的原則的具體體現(xiàn)。雖然業(yè)務(wù)排列是微服務(wù)運(yùn)動(dòng)宣稱的特征，但是它也面臨偏離軌道的風(fēng)險(xiǎn)。已經(jīng)有實(shí)例表明，技術(shù)專家總結(jié)說，如果他們把應(yīng)用集裝箱化，就是在“實(shí)施微服務(wù)”了。為了成功實(shí)施微服務(wù)，在考慮實(shí)際可用的技術(shù)之前，我們必須專注于目標(biāo)、希望實(shí)現(xiàn)的益處和原則。
從成功開始。盡管 SOA 在全盛時(shí)期使用率之高空前絕后，但是并沒有什么公共實(shí)例可以證明它的承諾。很明顯，SOA 最開始是由一個(gè)行業(yè)分析員提出的純概念模型。與之相反，微服務(wù)架構(gòu)是根據(jù)對(duì)無數(shù)企業(yè)的實(shí)際軟件開發(fā)的觀察提取出來的。亞馬遜和 Netflix 只是這種風(fēng)格的兩個(gè)旗手。而且，微服務(wù)的范圍非常廣泛，除了技術(shù)之外，還包括模型、原則、文化和企業(yè)特征。這樣很健康，因?yàn)樗瞥绲牟皇且粋€(gè)理想化的模型，而是真實(shí)模型。隨著微服務(wù)實(shí)施的參考內(nèi)容變更，模型也應(yīng)該隨之進(jìn)化。
視角很重要。在 SOA 運(yùn)動(dòng)中，有很多例子表明，沖突的意愿導(dǎo)致了它偏離正軌。技術(shù)管理人員搭建了集權(quán)式的帝國(guó)，而不是逐漸灌輸文化的變更。企業(yè)架構(gòu)師堅(jiān)持標(biāo)準(zhǔn)化，卻沒有清晰的目標(biāo)。代理商們修改 ESB 的定義來適應(yīng)他們的產(chǎn)品，而不是反過來。依然惋惜 SOA 初始定義被遺棄的架構(gòu)師，希望能再次重新定義產(chǎn)品的代理商，對(duì) SOA 中間件付出大量投入的企業(yè) IT 商店，這些手持斧頭反對(duì) SOA 運(yùn)動(dòng)的人，對(duì)微服務(wù)心懷警惕也是可以理解的。不過，不要因?yàn)榉磳?duì) SOA 的證據(jù)就給微服務(wù)定罪。思想開明，傾聽所有聲音，但是要確保檢查確認(rèn)來源。質(zhì)疑每個(gè)人的動(dòng)機(jī)，包括你自己的。
尋求和諧，而不是絕對(duì)。SOA 最初的目標(biāo)是平衡的，例如加快產(chǎn)品上市速度，同時(shí)降低集成成本?；诩兄频母?，SOA 運(yùn)動(dòng)在實(shí)踐中摒棄了這兩個(gè)目標(biāo)，轉(zhuǎn)而追求應(yīng)用集成的控制和標(biāo)準(zhǔn)化。這是個(gè)極端而又失衡的定位。微服務(wù)運(yùn)動(dòng)的核心就是隨著規(guī)模擴(kuò)大，改進(jìn)軟件交付速度，提高系統(tǒng)安全性。這些是和諧的目標(biāo)。然而，考慮到微服務(wù)及其敏捷根源的分散式遺產(chǎn)，也存在實(shí)施者偏離正軌，帶來過多團(tuán)隊(duì)自治，因而犧牲安全性的風(fēng)險(xiǎn)。這在行業(yè)內(nèi)已有前車之鑒。重要的是確保存在制衡力量來支撐目標(biāo)，并堅(jiān)持核心原則。
模型和原則能夠持續(xù)，技術(shù)卻不會(huì)。在微服務(wù)與 SOA 的爭(zhēng)辯中，有一點(diǎn)是達(dá)成共識(shí)的：微服務(wù)架構(gòu)符合最初 SOA 對(duì)軟件系統(tǒng)分解為分散耦合服務(wù)的愿景。那就是一個(gè)模型。而且，最初的 SOA 原則諸如業(yè)務(wù)排列、依賴最小化和服務(wù)契約等，都與微服務(wù)的原則一致。二者之間最大的不同在于技術(shù)。這具有兩面性。技術(shù)進(jìn)化速度非?？?。在很大程度上，技術(shù)運(yùn)動(dòng)都可以歸結(jié)到新技術(shù)帶來的原則。對(duì)于微服務(wù)運(yùn)動(dòng)來說，這意味著今天風(fēng)頭正勁的技術(shù)明天可能就會(huì)過時(shí)。各種 Docker 都有得意的日子，但是微服務(wù)使用者應(yīng)該擁抱模型和原則，并且做好技術(shù)被淘汰的準(zhǔn)備。
微服務(wù)運(yùn)動(dòng)令人激動(dòng)。在合成已被證明的原則和新技術(shù)、文化實(shí)踐方面，它的確還很新。它是否是 SOA 的成功版本、進(jìn)化版本或者反面版本都無關(guān)緊要。微服務(wù)會(huì)出現(xiàn)，留下印記，然后被下一個(gè)運(yùn)動(dòng)替代，接著是下下一個(gè)，永不停歇。目前，微服務(wù)運(yùn)動(dòng)的成員決定了它將會(huì)留下怎樣的印記。希望它能從 SOA 運(yùn)動(dòng)吸取經(jīng)驗(yàn)教訓(xùn)，保持和諧狀態(tài)，從而幫助企業(yè)實(shí)現(xiàn)大規(guī)模的速度與安全的優(yōu)化。
本文系 OneAPM 工程師編譯整理。OneAPM 能為您提供端到端的 Java 應(yīng)用性能解決方案，我們支持所有常見的 Java 框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級(jí)部署，即刻體驗(yàn)，Java 監(jiān)控從來沒有如此簡(jiǎn)單。想閱讀更多技術(shù)文章，請(qǐng)?jiān)L問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客
