前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在2014年，我們曾經(jīng)在一篇文章中報道過在來自Cap Gemini的Steve Jones與其他人之間進行的一次討論，其觀點是微服務(wù)并不是什么新鮮的東西。在當時，Steve是這么說的：

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

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

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

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

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

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

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

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

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

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

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

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