在過去一年左右的時間裡，我們看到有關微服務的文章與演講不斷湧現，其主題包括微服務的反模式、各種原則以及它與SOA 之間的關聯。最近，來自C2B2 的顧問主管 Matt Braiser 也加入了微服務與 SOA 的關聯這一話題的讨論之中。

最近，人們對于微服務的概念進行了大量的讨論，其中有許多讨論是關于微服務與 SOA 之間的關聯。微服務究竟是壓垮 SOA 的最後一根稻草，還是能夠拯救整個軟件工程行業的萬能藥？人們對此衆說紛纭。

Matt 在文中對于微服務概念産生背後的原因以及 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 所說，真正的區别在于數據的管理與所有權？這一争論是否完全沒有存在的必要？或者是否正如喬治. 桑塔亞那所說的，那些不能銘記過去的人注定要重蹈覆轍呢？

公衆：Springboot實戰案例錦集

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部