一位商人站在辦公室的桌前,一邊在筆記型電腦上打字,一邊觀看手上拿著的手機

微服務與微服務架構

微服務用來建構以分佈式部署的雲端型應用程式。和單體式架構相比,它的可擴充性高,所需的建構和維持的時間及精力較少。

微服務可在雲端中迅速部署

  • 微服務架構是快速部署及更新雲端型應用程式的設計方法。

  • 微服務一般為獨立運作,通常是在透過標準介面鬆散結合的容器中運作。

  • 微服務的優勢包括部署快速、易於升級,並支援增加的規模與複雜性。

author-image

作者

什麼是微服務?

微服務是輕巧、鬆散結合的模組,可作為複雜雲端型應用程式的架構模塊。雖然個別的微服務可以獨立運作,但它們都是在整合性介面下鬆散結合。

人們認為微服務架構現代化且具靈活性,可取代單體式架構較傳統的開發模型。

單體式架構中,通常為每個應用程式分配一個實體或虛擬的伺服器,而這些伺服器總是處於執行狀態。應用程式的擴展及可用性,完全取決於底層硬體,底層硬體為固定的實體。

反觀微服務可在單一伺服器或跨多個伺服器運作多個實例,因為資源可以動態擴充,支援工作負載的需求。個別的微服務一般皆為容器化,以提高可攜性及擴充能力。

微服務的不同特點

作為一個開發流程,微服務架構具有一些常見但並非普遍的特點。

這些特點包括:

  • 元件:微服務一般由可單獨替換和升級的軟體元件組成。這種架構對雲端管理技術具有影響,因為每個微服務都必須個別建置、監測及升級。
  • 服務:這些元件包括可依照需求進行通訊的服務,但可能不會在要求或呼叫之間持續作用。
  • 獨立部署:大多數的情況下,各個服務元件在微服務架構內獨立運作。特別是和較傳統的單體式架構相比,如果其中一個元件有所變更或更新,這對服務和元件的影響微乎其微。
  • 安全性:微服務之間的通訊一般以雙向傳輸層安全性(mTLS)加密,以保護資料在傳輸中免於受到惡意軟體和入侵式攻擊。
  • 容器化:微服務一般在容器中部署,以提高可攜性及擴充能力。

微服務架構可使應用程式更容易擴充和更快速部署,進而實現創新並加快新功能的上市時間。

—Amazon Web Services (AWS)

微服務和雲端應用程式的優勢

由於該架構在雲端中與生俱來的靈活性,因此微服務持續受到歡迎。事實上,Intel 最近進行的一項研究顯示,83% 的新雲端原生應用程式和 SaaS 解決方案都在使用微服務。1

微服務的最大優勢之一,是部署的速度和靈活性。隨著雲端應用程式和工作負載持續拓展規模與範圍,調整單體式架構以適應新的需求即變得日益困難且耗時,變得日益困難且耗時。微服務為分離式,因此可以在分散模式中管理其開發、部署和維護。

例如,可以指定各個獨立開發團隊負責其中一或多個微服務。責任分配有利於根據每個單位的業務能力重組 DevOps 功能。這麼做可以推動整個開發流程的現代化並消除孤島狀態。

微服務也構成一些部署上的挑戰。個別模組可能在不同系統上執行以滿足要求,這或許會導致不同模組之間效能不一致。

同樣地,需求激增時,延遲也可能成為某些微服務的問題。一般解決這些問題的方式是過度佈建資源,滿足激增的需求等級。

由於微服務是分離式的,因此影響某個模組的服務失敗,可能不會對其他模組造成太多或任何中斷。這是一項優勢,但服務失敗也會帶來挑戰。

例如,在停止執行服務後,可能難以為失敗的服務偵錯。其中一項解決方案是事先協調基礎結構並監測所有的流程和資料流程。這些監測通訊協定可利用支援硬體的遙測收集器和效能監測單位(PMU),其內建於Intel® 技術的雲端平台中。

微服務架構的運作方式

在微服務架構中,複雜的應用程式分解成多個可單獨開發和操作的獨立功能。個別的微服務經常透過 API 相互通訊,雖然彼此連接鬆散,但每個微服務都可以單獨開發、部署及更新。

微服務部署通常遵循以下三種模式之一:

  1. 雲端原生:有些已建立的高容量應用程式和服務起初是微服務,並保留在雲端。根據國際數據公司(IDC)的統計,約有56% 的微服務是雲端原生,其餘 44% 則源自舊式應用程式。2
  2. 重構與轉移:從內部或邊緣的資料中心開始部屬,並經過重構以適應雲端型的微服務架構。重構可能包括重新對應資料庫和其他與單體式架構有關的資源,使它們與相對應的微服務配對。
  3. 隨即轉移:有的組織沒有經過重構,而是在簡便的「隨即轉移」轉換中,將應用程式移轉至微服務架構。

微服務與 DevOps

微服務架構的分離式性質往往會導致 DevOps 團隊採用跨功能的方法,進行應用程式開發。

例如,不是在堆疊中開發軟體應用程式,而是指派一個團隊負責韌體,另一團隊負載中介軟體,第三個團隊負責使用者介面,微服務開發工作更傾向以業務能力為主進行組織。

在某種程度上,DevOps 團隊的開發流程與組織可以模仿微服務架構本身,其類似獨立、自封式的單元鬆散地互動,超越障礙和孤島。

所有的利害關係人都必須明白,將單體式應用程式現代化為微服務架構,是一段漫長艱辛的歷程,可能需要經過反覆改進。結構設計師和開發者必須仔細評估單體式應用程式的各個面向,並為每個面向提出一種移轉方式。

保護微服務

由於微服務一般設計成相互交流,因此在交流的每一端使用資料,或在兩個點之間傳輸時,保護資料是當務之急。

常見的解決方案是以雙向傳輸層安全性(mTLS)加密,有助於減少每個端點和傳輸過程中資料遭到入侵或惡意軟體攻擊的風險。mTLS 的目標是加密每個微服務提出的要求。這種整體的安全性方法構成了零信任環境的基礎,其中每個微服務、使用者與連線都必須經過獨立驗證及授權。

然而,不一定需要在每個個別的微服務中包含身分驗證和加密。為了避免冗餘,許多開發者選擇部屬服務網。網格作為微服務架構中的基礎結構層或 Proxy 執行個體,協助保護、控制及監測通訊。

安全性通訊協定可能需要大量的運算能力,這可能會佔用資源並降低微服務的傳遞速度。為了加速加密演算法及協助減少延遲,微服務開發者可部署 Intel® Data Protection Technology(Intel® DPT)。

Intel® DPT 包括 Intel® Advanced Encryption Standard – New Instructions(Intel® AES-NI)和 Intel® Secure Key Instructions 以及 Intel® Digital Random Number Generator(Intel® DRNG),以快速建立加密金鑰。

這些進階的演算法保護措施,針對 Intel® Xeon® 可擴充處理器的內建安全性功能進行最佳化。例如,Intel® Advanced Vector Extensions 512 (Intel® AVX-512) 和對稱加密、安全性雜湊和函數拼接等演算法創新,為加密提供顯著的效能改進。

這些和其他硬體支援的安全性功能可從主要的雲端服務供應商取得,實例則由 Intel® Xeon® 可擴充處理器提供支援。

微服務架構範例及其不斷演變的框架

隨著雲端應用程式持續拓展規模與範圍,開發者亦愈加仰賴微服務來建構複雜的多功能應用程式,並迅速擴展應用程式以適應瞬息萬變的使用模式。

對於每個微服務型的部署,一般都有多個鬆散連接的元件服務在單獨執行。這些模組化元件協同合作,建立一個整合式的使用者體驗或應用程式。

在某些微服務型的應用程式中,使用者體驗可能根據團體特性而有所區分,使用微服務的優勢是程式碼可以共享及重新使用。如此一來,便無須建構及維護同一服務的多個實例。如果其中一個不同的體驗需要量身打造,則可以加入其他的微服務。

比方說,熱門的共乘應用程式就是以微服務為基礎,但駕駛和乘客有著不同的使用者體驗。駕駛管理、位置追蹤、乘客個人檔案和付款處理屬於不同的微服務,但共同支援各自行動裝置上的使用者和駕駛介面。這些介面全都共用相同的品牌,只是每個群組的某些功能可能有所不同。

微架構也是電子商務商店的通用環境。產品建議與結帳流程可能是以個別的微服務開發及部署,但購物者會在線上商店的品牌環境和介面中體驗到兩個流程。

使用微服務的時機

微服務方法可將最複雜的解決方案分解成元件,協助移轉及擴充應用程式。每個微服務都是獨立開發與部署的,而各種微服務是以鬆散的整合式實體共同運作。

組織在開發新的雲端原生解決方案時,最有可能使用微服務。當現有的單體式架構變得過於笨拙,無法滿足不斷變化的需求時,組織也可能會部署微服務。

轉換至微服務架構的過程可能會導致組織及 DevOps 團隊本身的架構產生變化。隨著時間的推移,團隊可能會調整其新的、跨職能的業務能力重點,而不是模仿技術堆疊中功能層的孤島。

常見問題集 (FAQ)

常見問題集

微服務是輕巧的模組,可作為複雜雲端型應用程式的架構模塊。雖然個別的微服務可以獨立運作,但它們都是在整合性的介面下鬆散結合。

相對於單體式架構,微服務可以快速簡易地部署。微服務框架也很易於擴充,以適應日益複雜的工作負載和擴大的使用模式。