微服務

menu icon

微服務

微服務架構是一種方法,其中單一應用程式由許多鬆散連結且可獨立部署的小型服務所組成。

何謂微服務?

微服務(或微服務架構)是一種雲端原生架構方法,其中由許多鬆散連結且可獨立部署的小型元件或服務組成單一應用程式。 這些服務通常

  • 擁有自己的技術堆疊,其中包括資料庫和資料管理模型;
  • 透過 REST API、事件串流與訊息分配管理系統的組合彼此相互通訊;而且
  • 依商業功能組織起來,其中區隔服務的界線通常稱為有界限的環境定義。

雖然關於微服務的討論有許多都圍繞著架構定義和特性,但透過相當簡單的商業和組織優勢會更容易理解它們的價值:

  • 程式碼可以更輕鬆地更新 - 可以在無需碰觸整個應用程式的情況下新增特性或功能
  • 團隊可以針對不同的件使用不同的堆疊和不同的程式設計語言。
  • 元件可以個別獨立擴充,減少因為單一特性可能面臨過多負載而必須擴充整個應用程式所造成的浪費和成本。

微服務也可以透過它們的對比者 來理解。 最常被拿來與微服務架構做比較的兩個對象是單體式架構和服務導向架構 (SOA)

微服務與單體式架構之間的差異在於,微服務是由許多鬆散連結的小型服務組成單一應用程式,相形之下,單體式方法則會產生緊密連結的大型應用程式

如需進一步瞭解微服務與單體式架構之間的差異,請觀看以下影片 (6:37):

 

微服務與 SOA 之間的差異則可能比較不清晰。 雖然在微服務與 SOA 之間可以做技術對比,尤其是關於企業服務匯流排 (ESB) 的角色,但更容易看出差異的是其中一個範圍。 SOA 是在企業層面致力將組織 當中彼此通訊與互動的所有 Web 服務標準化,而微服務架構則專注在應用程式。

這篇文章「SOA 與微服務比較:有什麼不同?」以取得進一步的詳細資料。

微服務帶給組織的好處

在高階主管和專案主持人之間,微服務可能不像在開發人員之間那樣受歡迎。 這是微服務比較與眾不同的特徵之一,因為只有軟體開發團隊才會熱衷架構。 之所以如此,是因為微服務更能充分反映許多企業領導者想要架構與營運其團隊和開發流程的方式。

換個方式說,微服務是一種架構模型,它可以更充分地促進所需的維運模式。 在 IBM 最近對 1200 多位開發人員及 IT 主管所做的 IBM 意見調查中,87% 的微服務使用者同意,微服務的採用是值得付出花費和努力的。 您可以使用下面的互動式工具,進一步探索更多有關微服務優缺點的看法:

(資料來源: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'。)

以下只是一些微服務對於企業來說的優勢。

可獨立部署

微服務最重要的一個特徵可能是,其服務規模比較小而且可獨立部署,因此不再需要為了變更一行程式碼或在應用程式中新增功能而獲得批准。

微服務保證可幫組織化解為了做小小變更而耗費大量時間的內心挫折。 不需要是電腦科學博士,就能看出或瞭解能夠進一步促進速度和敏捷的方法有何價值。

但速度並不是這種服務設計方式的唯一價值。 有一種常見的新興組織模式,它將涉及商業問題、服務或產品的跨部門團隊集結起來。 微服務模型非常符合此趨勢,因為它可讓組織針對單一服務或服務組合建立小型的跨部門團隊,並讓他們以敏捷方式運作。

微服務的鬆散連結還可以建立一定程度的錯誤隔離,以及更好的應用程式復原力。 由於是小型服務,加上其清晰的界限和通訊模式,使得新的團隊成員更容易瞭解程式碼庫並迅速做出貢獻,就速度和員工士氣來說都有顯著好處。

適合工作的正確工具

在傳統的 n 層級架構模式中,應用程式通常共用一個堆疊,搭配支援整個應用程式的大型關聯式資料庫。 這個方法有幾個明顯的缺點,其中最重大的是,應用程式的每個元件必須共用一個堆疊、資料模型和資料庫,即使有明顯更好的工具適用於工作的某些元素。 這會形成不良架構,並且讓開發人員感到挫折,因為他們一直都知道有更好更有效率的元件建置方式可用。

相形之下,在微服務模式中,元件會獨立部署,並透過 REST、事件串流及訊息分配管理系統的組合進行通訊;因此,可以針對每一個個別服務將該服務的堆疊最佳化。 技術隨時都在變更,一個由眾多小型服務組成的應用程式,它可以在有更理想的技術可用時,更輕鬆且更省錢地進步發展。

精確擴充

有了微服務,個別服務不僅可以個別部署,還能夠個別擴充。 由此帶來的好處顯而易見: 只能正確執行,微服務的基礎架構需求低於單體式應用程式,因為它們能夠精確地只擴充有需要的元件,而不是像單體式應用程式需要擴充整個應用程式。

然而,其中也是有挑戰

微服務的重大好處伴隨著重大挑戰。 從單體式移到微服務意味著多很多的管理複雜性: 更多的團隊創造了更多的服務,然後部署在更多的地方。 某個服務發生問題可能導致其他服務發生問題,反之亦然。 記載資料(用於監視與解決問題)會變得更加浩瀚,而且可能在服務之間發生不一致。 新版本可能造成舊版相容性問題。 應用程式涉及更多的網路連線,這意味著發生延遲和連線問題的機會變更多。 DevOps 方法(如下所述)可以解決其中許多問題,但 DevOps 採用本身有自己的挑戰。

儘管如此,這些挑戰無法阻止非採用者採用微服務, 或阻止採用者深化其微服務承諾。新的 IBM 意見調查資料透露,56% 的非現行使用者可能在未來兩年內採用微服務,而 78% 的現行微服務使用者可能會增加他們投入在微服務的時間、金錢和精力(查看圖 1)。

顯示 56%、78% 和 59% 的三個圓餅圖

圖 1:微服務位在這裡。在未來兩年內,有 56% 的非使用者可能會採用微服務,78% 的使用者則會增加其微服務投資,而 59% 的應用程式將會使用微服務來建立。 (資料來源: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'。)

微服務可以啟用同時也需要 DevOps

微服務架構常被描述針對 DevOps 與持續整合/持續交付 (CI/CD) 進行最佳化,在可以頻繁部署小型服務的背景下,就很容易理解為何如此。

但看待微服務與 DevOps 之間關係的另一種方式是,微服務架構實際上需要 DevOps 才能獲得成功。 本文前面已討論過單體式應用程式的一些缺點,但它們的優點是,雖然擁有眾多的運轉部件和獨立技術堆疊,但並非複式分散式系統。 相形之下,假定伴隨微服務而來的複雜性、運轉部件和相依關係大幅增加,則在並未對部署、監視及生命週期自動化等方面進行重大投資的情況下,採用微服務將是不智的。

Andrea Crawford 透過以下影片深入分析 DevOps:

啟用關鍵技術和工具

雖然在微服務架構中可以使用任何現代的工具或語言,但仍有一些核心工具已成為微服務的必要和邊緣工具:

容器、Docker 及 Kubernetes

微服務的其中一個關鍵要素是,一般來說規模相當小。(沒有武斷的程式碼數量可用於決定某樣東西是否為微服務,但它的名稱中有「微」這個字。)

當現代容器時代在 2013 年迎來 Docker,它同時也導入了將變成與微服務緊密關聯的運算模式。 個別容器本身沒有作業系統負荷,因此它們比傳統的虛擬機器來得更小更輕,可以快速地啟動與停止運轉,這使得它們成為微服務架構內部小型輕量服務的完美搭配。

隨著服務和容器的擴大使用,編排與管理大型容器群組迅速成為重大挑戰之一。 Kubernetes 是一種開放原始碼容器編排平台,它因為可以傑出完成前述工作而成為最熱門的編排解決方案之一。

在 "Kubernetes Explained" 影片中,Sai Vennam 全面介紹了 Kubernetes:

 

API 閘道

微服務通常透過 API 進行通訊,特別是在狀態為首次建立時。 雖然用戶端和服務可以直接彼此通訊,但 API 閘道往往是有用的中介層,特別是在應用程式內部的服務數量隨著時間而增長時。 API 閘道擔任用戶端的反向 Proxy,方法是遞送要求、在多個服務之間扇出要求,以及提供更多的安全和鑑別。

有多種技術可用來實作 API 閘道,包括 API 管理平台,但如果使用容器和 Kubernetes 來實作微服務架構,則閘道通常會使用 Ingress 或 Istio 近期進行實作。

傳訊和事件串流

雖然最佳作法可能是設計無狀態服務,但狀態仍然會存在,服務必須注意它。 雖然 API 呼叫對於指定服務的初始建立狀態而言是有效的方式,但對於保持最新狀態來說不是特別有效的方式。 為了讓服務保持最新而不斷輪詢「我們到了嗎?」的方法根本不實際。

相反地,需要使用傳訊或事件串流來連結狀態建立 API 呼叫,以便服務能夠在播送狀態變更,而其他感興趣的當事人可以接聽這些變更並相應調整。 此工作可能最適合使用一般用途訊息分配管理系統,但在有些案例中事件串流平台,例如 Apache Kafka,可能才是好搭檔。 而微服務與事件驅動的架構開發人員的結合有利於建置分散式、可高度擴充、容錯且可延伸的系統,其中可即時使用與處理大量的事件或資訊。

無伺服器

無伺服器架構將一些核心雲端和微服務模式帶進其邏輯結論中。 在無伺服器的情況下,執行單位不只是一個小服務,而是一個功能,它通常只是幾行程式碼。 無伺服器功能與微服務之間的區隔是模糊的,但即使是比微服務還小的功能通常可以被理解。

無伺服器架構和功能即服務 (FaaS) 平台與微服務相近的地方是,它們雙方都有意建立比較小的部署單元,然後根據需求精準擴充。

微服務與雲端服務

微服務未必僅與雲端運算相關,但它們經常一起出現有幾個重要原因,這些原因超越微服務成為新應用程式的熱門架構樣式,以及雲端成為新應用程式的熱門代管目的地。

微服務架構的主要優點包括與個別部署及擴充元件相關聯的使用率和成本優勢。 雖然內部部署基礎架構在某種程度上也有這些優點,但小型可獨立擴充的元件搭配隨需應變隨收隨付的基礎架構,才能真正實現成本最佳化。

其次但或許更重要,微服務的另一個主要優點是,每個個別元件都可以使用最適合其特定工作的堆疊。 當您自行負責管理時,堆疊擴增可能會產生嚴重的複雜性與額外負擔,而使用支援堆疊即雲端服務可戲劇性地將管理挑戰減到最少。 換個方式說,您不可能發行自己的微服務基礎架構,因為不建議這麼做,尤其是在剛起步的時候。

共用模式

在微服務架構中,有許多共用與有用的設計、通訊及整合模式,它們可協助因應一些常見的挑戰和機會,包括:

  • 「前端的後端 (BFF) 模式:此模式會在使用者體驗和體驗所呼叫的資源之間插入一層。 例如,在桌面上使用的應用程式,其畫面大小、顯示畫面和效能限制將會與行動式裝置不同。 BFF 模式可讓開發人員在每個使用者介面使用適合該介面的最佳選項來建立與支援一個後端類型,而不是嘗試支援任何介面都可以使用但可能會對前端效能造成負面影響的通用後端。
  • 實體和彙總模式:實體是依其身分來區別的物件。 例如,在電子商務網站上,「產品」物件可能依產品名稱、類型及價格來區別。 彙總是應視為一個單元的相關實體集合。 因此,對於電子商務網站而言,訂單將是由買方所訂購產品(實體)的集合(彙總)。 這些模式用來以有意義的方式分類資料。
  • 服務探索模式:這些說明應用程式和服務會彼此相互尋找。 在微服務架構中,服務實例會因為擴充、升級、服務失敗,甚至服務終止而動態變更。 這些模式提供探索機制以應付這種無常。 負載平衡可以使用服務探索模式,方法是將性能檢查和服務失敗當作重新平衡資料流量的觸發因素。
  • 配接器微服務模式:將配接器模式想像成您到其他國家旅遊時所使用的插頭轉接器。 配接器模式的用途是協助轉換不相容類別或物件之間的關係。 依賴第三方 API 的應用程式可能需要使用配接器模式,以確保應用程式和 API 之間可以進行通訊。
  • 扼殺應用程式模式:這些模式可協助管理將單體式應用程式重構成微服務應用程式。 彩色名稱是指藤蔓(微服務)隨著時間過去緩慢地佔領與扼殺樹木(單體式應用程式)。

您可以透過「如何使用開發模式搭配微服務(第 4 部分)」進一步瞭解這些模式。 如果您想要進一步瞭解其他微服務程式碼模式,IBM Developer 還提供許多資訊。

反面模式

雖然可以將微服務做好的模式很多,但同樣也有為數不少的模式可能很快就讓開發團隊陷入困境。 其中一些重新表述為微服務 “don’ts”(不要),如下所示:

  • 微服務的第一個規則是不要建置微服務: 說得更準確一點,不要從微服務開始進行。 一旦應用程式變得又大又笨重且無法輕鬆更新與維護時,微服務是一種可以管理複雜性的方法。 只有當您感受單體式應用程式逐漸顯現的痛苦和複雜性時,才值得開始考慮如何將應用程式重構為小型服務。 在您感到痛苦之前,您都不算有一個需要重構的單體式應用程式。
  • 千萬不要在沒有 DevOps 或雲端服務的情況下建置微服務:建置微服務意味著建置分散式系統,而分散式系統很困難(如果您做出讓它變得更困難的選擇,它們就會格外困難)。 在沒有 a) 適當部署和監視自動化或 b) 受管理雲端服務的情況下,為了支援您眼前不斷蔓延的異質基礎架構而嘗試建置微服務,這會招致許多不必要的問題。 不要自己找麻煩,不如把時間花在擔心國家大事上。
  • 千萬不要將微服務做得太小而使得數目變太多: 如果您將微服務中的「微小」弄得太誇張,您很快就會發現自己所面臨的額外負擔和複雜性已遠超過微服務架構的整體增益。 最好是傾向大型服務,然後只有在它們開始出現微服務可以解決的特徵,即部署變更變得越來越困難和緩慢、共用資料模型變得過於複雜,或者服務的不同部分具有不同的負載/擴充需求時,才將它們進行拆解。
  • 千萬不要將微服務變成 SOA: 微服務與服務導向架構 (SOA) 經常彼此混淆,因為在最基本的層次上,兩者都有意建置可供其他應用程式使用的可重複使用個別元件。 微服務與 SOA 之間的差異在於,微服務專案通常涉及重構應用程式,因此它比較容易管理,而 SOA 則著重在企業層面改變 IT 服務的運作方式。 轉變成 SOA 專案的微服務專案很可能會把自己壓垮。
  • 千萬不要試著成為 Netflix:Netflix 是微服務架構的早期先驅之一,在建置與管理佔據所有網際網路流量三分之一的應用程式時,形成一種完美風暴,他們需建置大量的自訂程式碼與服務,而這些對於普通的應用程式來說是不必要的。 從自己可以處理的節奏開始進行,避免複雜性,並且儘可能使用現成工具,這樣會好得多。

指導教學: 建立微服務技能

如果您準備好進一步瞭解如何使用微服務,或者您需要建立微服務技能,請嘗試下列其中一個指導教學:

微服務與 IBM Cloud

微服務能以現代企業的速度促進創新開發。 瞭解如何藉由將獨立微服務部署至雲端環境中,以善用雲端的可擴充性和靈活彈性。 瞭解在 IBM 的協助下將您的應用程式現代化結果會如何。 

進行下一步:

立即開始使用 IBM Cloud 帳戶