前言

微服務(wù)究竟是壓垮SOA的最后一根稻草，還是能夠拯救整個(gè)軟件工程行業(yè)的萬能藥？人們對(duì)于微服務(wù)的概念進(jìn)行了大量的討論，其中有許多討論是關(guān)于微服務(wù)與SOA之間的關(guān)聯(lián)。詳細(xì)請(qǐng)看下文分析

來自C2B2的顧問主管Matt Braiser在文中對(duì)于微服務(wù)概念產(chǎn)生背后的原因以及SOA的原則進(jìn)行了一些基本的概括。這篇文章的基本思想是：這兩種架構(gòu)在原則上確實(shí)是相當(dāng)近似的，但面向SOA或微服務(wù)進(jìn)行架構(gòu)的產(chǎn)品確實(shí)存在著各種不同之處，使得他們各自適用于不同的用例。Matt在對(duì)微服務(wù)的總體介紹中是這樣說的：

經(jīng)過分離的組件可以各自擁有獨(dú)立的生命周期，并且按需進(jìn)行擴(kuò)展。不僅如此，這種方式也打破了組件之間的技術(shù)依賴，這就允許每個(gè)服務(wù)各自選擇最適合的技術(shù)進(jìn)行實(shí)現(xiàn)。通過將較大的問題分解為幾個(gè)較小的問題，讓每個(gè)問題更易于進(jìn)行分析，也更利于開發(fā)者選擇最適合的解決方案。

盡管有這些優(yōu)點(diǎn)，但微服務(wù)也存在著一些不足之處。雖然在這一領(lǐng)域中具有實(shí)際工作經(jīng)驗(yàn)的開發(fā)者基本上都已經(jīng)很好地理解了這些問題，但針對(duì)他們的報(bào)道與討論卻相對(duì)很少：

通過這種方式對(duì)大問題進(jìn)行分解也增加了整個(gè)解決方案的復(fù)雜度，尤其是在那些使用不同技術(shù)或方式創(chuàng)建各種服務(wù)的系統(tǒng)中體現(xiàn)得更為明顯。這種架構(gòu)將系統(tǒng)的整合點(diǎn)推移到了服務(wù)之間的接口，因此這些服務(wù)的接口需要進(jìn)行良好的定義，在系統(tǒng)中也要對(duì)服務(wù)級(jí)別達(dá)成一致，并且還需要定義其他的非功能性需求。

在目前來看，微服務(wù)還是一種相對(duì)較新的技術(shù)，架構(gòu)師與開發(fā)者們通常所使用的一些輔助性工具也還處于發(fā)展階段，以上所提及的這些問題可能遲早會(huì)得到解決。但在Matt看來，微服務(wù)的應(yīng)用還存在著一個(gè)關(guān)鍵問題，那就是數(shù)據(jù)的管理和所有權(quán)：

當(dāng)某個(gè)原本采用一體性應(yīng)用程序架構(gòu)的系統(tǒng)被分解為多個(gè)小型服務(wù)時(shí)，在原本的一體性架構(gòu)中集中保存在某處的數(shù)據(jù)，在新的微服務(wù)應(yīng)用中經(jīng)常會(huì)改為保存在多個(gè)地方，這種改變可能會(huì)帶來維護(hù)數(shù)據(jù)一致性的挑戰(zhàn)。

Matt指出，與微服務(wù)相關(guān)的產(chǎn)品通常會(huì)專注于服務(wù)組件的生命周期，鼓勵(lì)開發(fā)者在實(shí)現(xiàn)服務(wù)時(shí)選擇某些推薦的實(shí)現(xiàn)方式，例如Docker，并通過某些推薦的協(xié)議進(jìn)行服務(wù)之間的交互，通常來說RESTful風(fēng)格是一種自然的選擇。

通常來說，RESTful服務(wù)最適合于為某個(gè)數(shù)據(jù)模型提供CRUD操作，而微服務(wù)架構(gòu)中的服務(wù)往往能夠被輕易地分解為這些CRUD類型的服務(wù)，因此它與RESTful就能夠很好地結(jié)合在一起。而對(duì)于其他類型的服務(wù)來說，類RESTful風(fēng)格的服務(wù)通常也是一種良好的選擇，這種類RESTful的風(fēng)格也會(huì)使用HTTP作為傳輸協(xié)議，但服務(wù)本身并不一定要100%地符合RESTful的原則。

在Matt在文中提到SOA之后，他很快深入地談?wù)摿?strong>SOA與微服務(wù)之間的關(guān)聯(lián)：

現(xiàn)如今，談?wù)揝OA的各種不足似乎已經(jīng)成為了一件很普遍的事。但如果你認(rèn)真地觀察，就會(huì)發(fā)現(xiàn)SOA的缺陷中的絕大部分與微服務(wù)是相同的，只是有關(guān)他們的案例更為具體一些。而兩者的優(yōu)勢(shì)其實(shí)也大體相同，因?yàn)閺谋举|(zhì)上看，這兩種技術(shù)所做的都是同一件事：將一個(gè)較大的問題分解為多個(gè)較小的問題。

隨后，Matt進(jìn)一步指出，那些通常被認(rèn)為在實(shí)施或推廣微服務(wù)方面具有領(lǐng)袖地位的公司，往往也樂于將他們的架構(gòu)描述為面向服務(wù)的架構(gòu)。不過，為了實(shí)現(xiàn)目標(biāo)，這些公司通常會(huì)傾向于避免使用傳統(tǒng)的SOA產(chǎn)品。按照Matt的觀點(diǎn)來看，這些產(chǎn)品就是指專注于基于企業(yè)服務(wù)總線（ESB）的方案。但在Matt看來，之所以這些SOA產(chǎn)品名聲不佳，是因?yàn)槭褂谜咴谀承╉?xiàng)目中將這些產(chǎn)品錯(cuò)誤地用于進(jìn)行應(yīng)用程序的設(shè)計(jì)，而不是用于企業(yè)級(jí)架構(gòu)的設(shè)計(jì)。這些產(chǎn)品本身在交付面向服務(wù)架構(gòu)的方案開發(fā)時(shí)并不存在問題。

就其本身而論，這些產(chǎn)品的特性主要專注于企業(yè)級(jí)的用例，并提供了多種方法用于追蹤業(yè)務(wù)單元級(jí)別的SLA。大多數(shù)SOA產(chǎn)品都要求在服務(wù)的通信中使用一種或是少量的協(xié)議及消息格式，例如HTTP、FTP、SOAP和JMS等等，并提供連接器的代碼庫(kù)以實(shí)現(xiàn)通信功能。

實(shí)際上，Kai W？hner相信ESB仍未消亡，它仍然能夠在微服務(wù)架構(gòu)中扮演重要的角色。

通過使用ESB，你能夠?qū)崿F(xiàn)這一產(chǎn)品原本的目標(biāo)，包括集成、編排、路由、（某些類型的）事件處理、相關(guān)性以及業(yè)務(wù)活動(dòng)的監(jiān)控。你也可以通過（微）服務(wù)構(gòu)建你的應(yīng)用，通過這些服務(wù)實(shí)現(xiàn)你的需求，解決你在業(yè)務(wù)上的問題。隨后，你將自動(dòng)地將這些服務(wù)獨(dú)立地部署到某個(gè)可伸縮的運(yùn)行時(shí)平臺(tái)上，為這些服務(wù)提供標(biāo)準(zhǔn)化的接口。這些服務(wù)是松耦合的，他們能夠通過大量一般水平的硬件實(shí)現(xiàn)線性的擴(kuò)展。

顯然，不僅僅是Matt，還有許多人也相信SOA與微服務(wù)應(yīng)用了相同的原則，只是在組織中的應(yīng)用層次不同。SOA專注于對(duì)“大型服務(wù)”進(jìn)行編排操作，但這些大型服務(wù)也可以通過對(duì)一系列微服務(wù)進(jìn)行組合而實(shí)現(xiàn)。當(dāng)然，正如我們?cè)谝黄^早的文章中所說，服務(wù)的大小并不是一種定義微服務(wù)的好方法：

Jeppe Cramon在一系列博客文章中表達(dá)了他對(duì)于微服務(wù)的觀點(diǎn)，以及他在同步的雙向通信方案所看到的耦合問題。在他看來，僅僅使用服務(wù)的大小定義微服務(wù)并不是一種良好的衡量方法，并且也無助于判斷某個(gè)服務(wù)是否具有正確的職責(zé)。

實(shí)際上，Matt相信，微服務(wù)的出現(xiàn)應(yīng)當(dāng)歸功于SOA原則的成功（另一部分人則發(fā)現(xiàn)通過實(shí)施微服務(wù)，將更易于理解面向服務(wù)的思想），他的總結(jié)如下：

作為一名開發(fā)者，如果你正在開發(fā)一個(gè)應(yīng)用程序，那么微服務(wù)框架將能夠帶來更大的敏捷性，并為你提供更好的控制能力。而如果你的任務(wù)是在整個(gè)企業(yè)中對(duì)于大量的業(yè)務(wù)過程進(jìn)行編排，那么SOA產(chǎn)品或許能夠?yàn)槟闾峁└m合的工具。

在2014年，我們?cè)?jīng)在一篇文章中報(bào)道過在來自Cap Gemini的Steve Jones與其他人之間進(jìn)行的一次討論，其觀點(diǎn)是微服務(wù)并不是什么新鮮的東西。在當(dāng)時(shí)，Steve是這么說的：

在我看來，微服務(wù)只是一種為經(jīng)過良好架構(gòu)設(shè)計(jì)的SOA解決方案實(shí)現(xiàn)的面向服務(wù)的交付方案。SOA提供了上下文的框架，同時(shí)也提供了微服務(wù)所堅(jiān)持的大部分規(guī)則。不僅如此，SOA還提供了一種更寬泛的上下文，使微服務(wù)能夠在復(fù)雜的企業(yè)中符合這些上下文。許多人在不斷地抱怨SOA中的各種WS-*協(xié)議、ESB的龐大以及各種極端復(fù)雜的項(xiàng)目，其實(shí)這只是面臨的挑戰(zhàn)不同而已。

這樣看來，Matt并不是唯一一個(gè)認(rèn)為SOA與微服務(wù)之間存在著密切聯(lián)系的人，只是這些討論往往是由具有深厚SOA背景的人所發(fā)起的。或許是因?yàn)槟切┪⒎?wù)的提倡者在過去幾年中沒有深入地鉆研過SOA，也可能是他們發(fā)現(xiàn)SOA或是那些旨在幫助用戶通過SOA方法進(jìn)行開發(fā)的工具中缺少了某些方面的內(nèi)容？舉例來說，在今年早些時(shí)候，Bob Rhubart曾引用了Eberhard Wolff的文章，后者是adesso AG的技術(shù)咨詢公告板的主管，同時(shí)也是一位自由職業(yè)的顧問以及培訓(xùn)師，他是這樣談?wù)揝OA與微服務(wù)的：

SOA是一種能夠改變整個(gè)企業(yè)的IT結(jié)構(gòu)的戰(zhàn)略創(chuàng)新，它將企業(yè)系統(tǒng)劃分為不同的服務(wù)，為企業(yè)賦予了更大的靈活性……微服務(wù)必須能夠獨(dú)立地進(jìn)行部署，而SOA服務(wù)往往是按照一體性的部署方式實(shí)現(xiàn)的。因此，雖然SOA與微服務(wù)技術(shù)有一定程度的相似性，但他們的本質(zhì)是完全不同的。

然而，就在同一篇文章中，Oracle ACE部門的總監(jiān)Torsten Winterberg說到：在他看來，“微服務(wù)正是我們?cè)谶^去十年間一直在談?wù)摰哪欠NSOA”。這種SOA與微服務(wù)之間的關(guān)聯(lián)的爭(zhēng)論很可能還會(huì)持續(xù)很長(zhǎng)一段時(shí)間，或許就像REST與SOA的爭(zhēng)論一樣。實(shí)際上，TIBCO亞洲區(qū)的CTO Kevin Pool就將此稱為一種良性的爭(zhēng)論。

那么微服務(wù)的不同之處體現(xiàn)在哪里呢？在微服務(wù)架構(gòu)中，每個(gè)操作（或方法）都是獨(dú)立開發(fā)的。（在他的文章前半部分）我們所描述的那個(gè)單用戶的SOA服務(wù)將分別實(shí)現(xiàn)為多個(gè)獨(dú)立的微服務(wù)。這些服務(wù)之間一般不會(huì)定義正式的接口，或者僅僅是定義一種非常簡(jiǎn)單直接的接口。也無需定義具有復(fù)雜的架構(gòu)層次和結(jié)構(gòu)的中央式數(shù)據(jù)模型。好吧，或許我們需要定義某種通用的數(shù)據(jù)字典，但這一點(diǎn)在每個(gè)微服務(wù)中并非是強(qiáng)制性的，因?yàn)槊總€(gè)微服務(wù)都可以按照自身的需要，獨(dú)立地整合相應(yīng)的變更。每個(gè)微服務(wù)都實(shí)現(xiàn)了獨(dú)立部署、停用或是重啟等操作。在大多數(shù)場(chǎng)景中，各個(gè)獨(dú)立的微服務(wù)將在一個(gè)統(tǒng)一的平臺(tái)中執(zhí)行。

Kevin在比較和對(duì)比SOA與微服務(wù)的不同之處時(shí)選擇了一種非常特定于實(shí)現(xiàn)的視角，SOA的實(shí)現(xiàn)專注于ESB、SOAP和WSDL。不過，在今年早些時(shí)候，Coert van den Thillart在他的文章中對(duì)此給出了或許是最好的一次總結(jié)：

微服務(wù)架構(gòu)風(fēng)格與SOA究竟有多大區(qū)別，回答完全取決于個(gè)人觀點(diǎn)。在圍繞著服務(wù)的概念創(chuàng)建架構(gòu)這一方面，微服務(wù)提供了一種更清晰、定義更良好的方式。兩者之間最關(guān)鍵的區(qū)別在于，微服務(wù)專注于以自治的方式產(chǎn)生價(jià)值。

在對(duì)SOA和微服務(wù)的各方面特性與實(shí)現(xiàn)途徑進(jìn)行比較與對(duì)比后，George Lawton相信微服務(wù)為SOA技術(shù)引入了敏捷性，并且“修正了SOA中的一些遺留問題”：

微服務(wù)的原則與敏捷軟件開發(fā)思想是高度一致的，而它與SOA原則的演化的目標(biāo)也是相同的，則減少傳統(tǒng)的企業(yè)服務(wù)總線開發(fā)的高復(fù)雜性。

對(duì)于他的這篇文章，目前看來至少有一位留言者表示了贊同意見：

我同意（包括其他留言）微服務(wù)并不是一種新思想的方法。在我看來，它更像是一種思想的精煉，并且更好地利用了先進(jìn)的技術(shù)以解決問題，例如容器與自動(dòng)化。

那么，你對(duì)此問題的觀點(diǎn)是怎樣的呢？微服務(wù)與SOA之間是否存在關(guān)聯(lián)？我們所討論的方向是否應(yīng)偏重于如何通過技術(shù)（實(shí)現(xiàn)）手段以支持這兩種架構(gòu)，而不是專注于他們?cè)诩軜?gòu)上的區(qū)別？還是如同Matt所說，真正的區(qū)別在于數(shù)據(jù)的管理與所有權(quán)？這一爭(zhēng)論是否完全沒有存在的必要？或者是否正如喬治。桑塔亞那所說的，那些不能銘記過去的人注定要重蹈覆轍呢？