前言

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

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

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

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

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

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

當某個原本采用一體性應用程序架構的系統被分解為多個小型服務時，在原本的一體性架構中集中保存在某處的數據，在新的微服務應用中經常會改為保存在多個地方，這種改變可能會帶來維護數據一致性的挑戰。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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