前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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