微服務與容器技術實踐：現代應用開發

– 11 分鐘閱讀

隨著軟體定義網路、SaaS 和物聯網等技術的發展，企業需要更靈活的應用開發和佈署流程。微服務和容器技術因其提升效率和降低團隊負擔的特性，成為現代應用開發的熱門技術。本文旨在提供微服務和容器技術的全面，從基本概念到實際應用，並提供豐富的案例分析，適合技術人員和商業管理階層。本文首先比較了微服務架構和傳統單體架構的優缺點，突顯微服務在可擴充套件性、靈活性、降低風險和技術多樣性方面的優勢。同時也點明微服務架構的挑戰，例如系統複雜度、資料一致性和網路延遲等問題。接著，本文以一個計算器應用程式為例，說明如何將單體架構轉換為微服務架構，並解釋如何透過 HTTP 或其他協定進行微服務間的溝通。此外，本文也探討瞭如何在微服務架構中新增功能，以及如何設計層次結構來支援不同功能。最後，本文以一個電商系統為例，說明單體架構在擴充套件性和維護性方面遇到的挑戰，並點出容器化和雲端原生技術如何有效支援微服務架構，並以資料驅動決策的案例說明未來趨勢。

微服務與容器的實踐

轉型與創新：現代應用開發的新挑戰

在當今快速變遷的科技領域，物聯網、軟體定義網路及軟體即服務（SaaS）等新興技術正深刻影響著應用開發與佈署流程。隨著這些創新技術的興起，企業對於能夠簡化應用更新流程的平台和架構需求與日俱增。這些平台和架構不僅能讓最新版本更頻繁地上市，同時也能降低開發和佈署團隊的負擔。

然而，這場轉型依然處於初期階段，許多技術和框架已經湮沒在歷史長河中。但其中仍有一些技術脫穎而出，持續改進全球軟體開發的效率。這些技術允許開發者以更大的靈活性來建立和更新應用程式。其中，微服務和容器技術便是其中的佼佼者。

相較於傳統的單體式架構，微服務將應用程式分解為多個獨立執行且互相協作的小型服務。這種方式特別適合於大型專案，需要多個團隊協作，且程式碼量龐大的情況。即使是小小的程式碼變動，也可能導致嚴重延遲。微服務則透過引入靈活性和可擴充套件性，使得應用程式開發和佈署過程更加高效。

微服務與容器：未來趨勢的必備技能

本文旨在為讀者提供一個全面的微服務與容器技術，無論你是剛接觸這些技術的初學者，還是已經有一定經驗的專家。本文涵蓋了從基本概念到實際應用的各個方面，並提供了豐富的案例分析和技術深度。

本文主要導向兩類別讀者：

  1. 技術從業者：包括學生、設計師及系統架構師，這些讀者可能已經熟悉微服務和容器技術，但希望深入瞭解這些技術在實際專案中的應用。本文將為你提供詳細的分析和決策指引，幫助你在適當時機採用這些技術。

  2. 商業管理階層：包括高層管理人員及專案經理，這些讀者希望從商業角度瞭解微服務和容器技術。本文透過簡單易懂的例子和最少化的專業術語，幫助你快速掌握這些新興技術。

為什麼要選擇本文？

  • 全面性：本文提供了微服務與容器技術的全面概覽，涵蓋從基本概念到實際應用。
  • 實踐導向：透過豐富的案例分析，幫助你理解如何在真實專案中應用這些技術。
  • 決策指引：提供詳細的分析和決策建議，幫助你在適當時機採用微服務和容器技術。

本文結構

本文分為三個部分：

  1. 基礎知識：介紹微服務和容器技術的基本概念及其優勢。
  2. 實踐應用：探討如何在實際專案中應用這些技術。
  3. 案例研究：透過一個完整的服務台應用案例，展示如何將傳統架構轉換為根據微服務和容器的架構。

開始你的學習之旅

無論你是希望提升組織效率、轉型到微服務與容器技術、還是學習最新趨勢以提升競爭力，本文都將是你理想的學習資源。立即開始你的學習之旅吧！

註冊你手上的《Microservices and Containers》書籍以便於即時獲得更新或修正內容。請前往 InformIT 網站進行註冊並登入或建立一個帳戶。輸入產品 ISBN（9780134598383），然後點選提交。在已註冊產品標籤下檢視 Access Bonus Content 連結旁邊附近此產品，然後按該連結取得任何可用之額外材料。如果你希望收到獨家優惠資訊及更新訊息，請勾選收到我們電子郵件通知。

微服務簡介

技術的演進持續改變世界的運作方式，這些變化也對支援其運作的技術提出了新的挑戰。從 56k 速率的撥接式調變解調器到 100Gbps 的乙太網，僅用了不到兩個世代的時間。隨著速度的提升，企業對開發更快速的軟體需求也隨之增加，為此開發出了許多高階的軟體語言來滿足應用需求。在系統層面，我們從大型主機演進到高速伺服器，再到將伺服器標準化、虛擬化和雲端化。如今，「容器化」已成為一個動詞，因為容器被廣泛應用於更有效地利用資源。

在這段過程中，出現了許多新的架構正規化，如模型-檢視-控制器（MVC）、企業整合模式（EIPs）和服務導向架構（SOA）。現在，微服務架構成為技術界的熱門話題。讓我們來看看它為什麼如此受到關注。

什麼是微服務？

微服務是一種獨立、自包含的功能，設計成可執行或程式形式，並透過輕量級的互程式通訊（如超文字傳輸協定（HTTP）、根據表示狀態轉移（REST）架構的 RESTful 網頁服務、訊息佇列等）與其他微服務進行溝通。微服務之所以獨特，是因為每個微服務都可以獨立地開發、測試、佈署和按需擴充套件，不依賴其他微服務。

微服務與傳統架構比較

要理解微服務架構的價值，我們需要將其與傳統的單體架構進行比較。

單體架構

傳統的單體架構是一種將所有功能模組封裝成一個單一應用程式的設計方式。這種架構的優點是簡單易懂，開發和佈署過程也相對較為直觀。然而，隨著應用程式規模的擴大和功能需求的增加，單體架構會面臨以下問題：

  1. 擴充套件性不足：單體應用難以針對某些功能進行獨立擴充套件。
  2. 維護困難：由於所有功能模組緊密耦合，修改一個部分可能會影響到整個系統。
  3. 佈署風險：每次更新都需要佈署整個應用程式，風險較高。

微服務架構

與單體架構不同，微服務架構將應用程式拆分成多個獨立執行的小型服務。這些小型服務各自負責特定功能，並透過標準協定進行互動。微服務架構帶來以下優勢：

  1. 高可擴充套件性：每個微服務可以獨立地按需擴充套件。
  2. 靈活性強：不同團隊可以同時開發和佈署不同的微服務。
  3. 降低風險：每次更新只需佈署特定微服務，風險降低。
  4. 技術多樣性：不同微服務可以使用最適合其功能需求的技術堆疊。

內容解密：

每個微服務都可以獨立地按需擴充套件

這意味著當某個功能需要更多資源時，只需要針對該功能進行資源分配和擴充套件即可。例如，假設我們有一個電子商務平台，其中「訂單處理」和「庫存管理」是兩個獨立的微服務。當訂單量急劇增加時，「訂單處理」微服務可以獨立地擴充套件以應對更多請求。

不同團隊可以同時開發和佈署不同的微服務

這使得大型專案可以分散到多個團隊來進行開發和佈署。例如，「前端開發團隊」可以專注於「使用者介面」微服務，「後端開發團隊」則專注於「資料處理」微服務。

每次更新只需佈署特定微服務

這降低了更新過程中的風險。假設在「支付處理」微服務中發現了一個漏洞，「支付處理」團隊只需更新該微服務即可修復漏洞，而不會影響到整個系統。

不同微服務可以使用最適合其功能需求的技術堆疊

例如，「資料分析」微服務可能會使用 Python 和 Pandas 清理資料，「實時通知」則可能會使用 Node.js 和 WebSocket 技術進行即時通訊。

實施挑戰

儘管有上述優勢，但實施微服務架構也面臨一些挑戰：

  1. 複雜度增加：分散式系統更加複雜，需要更多的人力和資源來管理。
  2. 資料一致性：在分散式環境中保證資料的一致性是一個難題。
  3. 網路延遲：由於各個微服務分佈在不同節點上進行通訊時可能會引起延遲。

未來趨勢

隨著技術不斷進步和市場需求的變化，「容器化」和「雲端原生」技術正成為支援微服務架構運作的一大助力。例如 Kubernetes 和 Docker 已經成為業界標準工具之一，幫助企業更高效地管理和佈署容器化應用程式。

資料驅動決策

目前行業內也有很多公司開始採取資料驅動決策方式來推動商業模式創新。例如：

以下為典型案例：
  • 公司 A：此公司採取了大量資料驅動決策方式並建立了完善的決策支援系統（DSS）。他們透過分析消費者行為資料推動產品創新與設計改進。
  • 公司 B：此公司透過先進人工智慧技術將資料洞察轉化為行銷策略。

玄貓深信：隨著時間推移及科技進步技術日益成熟，“大資料”與“機器學習”將持續主導企業未來商業成功之關鍵因素。玄貓相信有必要藉助AI框架進行系統規劃及資料挖掘分析後再做出適當調整以達至最佳效果及營運績效。

次段落標題
  1. 案例分析
  2. 重點觀察及評估

微服務架構介紹

微服務架構繼承了軟體開發中的多項優良原則，包括鬆耦合、按需擴充套件及導向服務等。這些特性使得微服務在現代軟體開發中具有顯著的優勢。本章將探討微服務的基本概念、與傳統單體架構的差異，以及實際應用中的優勢。

何謂微服務

首先，讓我們來瞭解「獨立能力」這個概念。獨立能力意味著每個微服務只負責一個具體的功能，且這個功能對所有消費者來說都是一致的。舉例來說，一個訂單管理服務只負責處理訂單，並不會進行其他操作，如傳送通知。它可能會呼叫另一個負責傳送通知的微服務來完成這項任務。這種功能分離提供了極大的靈活性，因為每個微服務都可以獨立地進行管理、維護、擴充套件、重複使用和替換，而不會影響到其他微服務。

根據這個定義，根據微服務的應用程式是由多個獨立的微服務組成的集合，每個微服務提供特定且明確定義的功能，並透過明確的協定進行通訊，以實作整體應用程式的功能。可以將這種架構描述為根據微服務的架構，其中每個微服務都作為一個獨立的程式執行。

微服務與單體架構的差異

接下來，玄貓將探討微服務與傳統單體架構之間的差異。單體架構中，所有功能都被封裝到一個大型可執行檔或WAR檔案中，稱為單體實作。

讓我們以一個簡單的例子來說明：假設有一個網頁上的計算器應用程式。在單體應用程式中，所有計算器操作（如加法、減法等）可能會被寫成獨立的程式函式，而一個函式可以直接呼叫另一個函式來完成其操作。這裡只有一個程式在執行，通訊是透過標準程式函式呼叫來實作的。設計可能類別似於此圖示：

  graph TD;
    Client[Client]
    Output[Output]
    Client --> Calc;
    Calc --> Output;
    Calc[Calc(num1,num2,op)];
    Calc1[+];
    Calc2[-];
    Calc3[X];
    Calc4[%];

此圖示展示了單體架構下簡單計算器應用程式的設計。

微服務架構示例

相反地，如果開發者採用微服務正規化來構建計算器應用程式，則會將每個計算器操作構建為獨立的微服務，如此圖示所示：

  graph TD;
    Client[Client]
    Client --> Add;
    Client --> Subtract;
    Client --> Multiply;
    Client --> Divide;
    Add[op(num1,num2, "+")];
    Subtract[op(num1,num2, "-")];
    Multiply[op(num1,num2, "X")];
    Divide[op(num1,num2, "/")];

在此情況下，一個微服務可以透過HTTP或其他協定進行互程式呼叫來呼叫另一個微服務。如果其中某個函式遇到嚴重錯誤（例如超出範圍），可能會導致整個應用程式當機。然而在使用微服務時，只有受影響的服務會失效；其他服務仍可正常運作。

這樣簡單的例子旨在強調採用微服務正規化的最大優勢：它可以簡化複雜應用程式的實施，允許我們將應用程式分解為可管理的獨立元件。這種簡化可以帶來多方面的幫助，例如允許我們在不影響其他服務的情況下新增所需功能。此外，每個微服務都可以根據需求進行獨立更新或擴充套件。

內容解密：

  • 什麼是獨立能力？ 獨立能力意味著每個微服務只負責一個具體功能。
  • 為什麼要使用分離功能？ 因為它提供極大靈活性。
  • 什麼是根據微服務的應用？ 根據多個獨立、具備明確定義功能並透過協定通訊之間達成整合目標。
  • 單體架構如何運作？ 所有功能被封裝至一處。
  • 如何透過HTTP或其他協定互相呼叫？ 一個程式可以呼叫另一程式。
  • 哪些優點？ 分離有助簡化複雜性並增加靈活性與容錯性。

增加新操作

例如，假設我們需要建立一個新操作來使用現有可用功能：比如找到給定數字的平方值。此操作非常簡單且僅涉及少量或無需更改現有程式碼。我們建立了一新的一項微服務來呼叫「乘法」操作已經發布之API（如此圖示所示）：

  graph TD;
    Client[Client]
    Client --> Square;
    Square[op(int,int, "^2")];

結果我們只有一項新增之「乘方」進行編譯及佈署處理而非整體重新編譯及佈署。

內容解密：

  • 增加新操作有何優點？ 透過呼叫已存在API從而減少現有更改程式碼風險。
  • 如何運作？ 新增更少更改程式碼便達到目的。

互動型層次結構

還有一些可僅供其他微服助提供支援之使用之案例（如此圖示所示）：

  graph TD;
    Client[Client]
    Client --> L1_1;
    Client --> L1_2;
    Client --> L1_3;

    L1_1 --> L2_1;
    L1_2 --> L3_1;

    subgraph Layer 1
        L1_1[μS]
        L1_2[μS]
        L1_3[μS]
    end

    subgraph Layer 2
        L2_1[μS]
        L3_1[μS]
    end

舉例說明：在上述圖示中客戶端僅可呼叫三項位於第一層之「子範域」而其其中某子範域又可依序呼叫其他第二層次。

內容解密：

  • 層次結構代表什麼意義？ 層次結構代表對不同功能有不同層次支援能力。

單體架構面臨挑戰

關於實際挑戰部分：再來看另一例子：假設有電商系統及其涉及高階元件（如此圖示所示）：

  graph TD;
    AppInstance1[AppInstance1]
    AppInstance2[AppInstance2]
    LoadBalancer[LoadBalancer]
    LoadBalancer --> AppInstance1;
    LoadBalancer --> AppInstance2;

    subgraph AppInstance
        ProductCatalog[Product Catalog];
        ShoppingCart[Shopping Cart];
        OrderMgmt[Order Mgmt];
        UserMgmt[User Mgmt];
        PaymentSearch[Payment Search];
        subgraph ExtAppInstance
            ProductCatalogE[Product Catalog];
            ShoppingCartE[Shopping Cart];
            OrderMgmtE[Order Mgmt];
            UserMgmtE[User Mgmt];
            PaymentSearchE[Payment Search];

        end
    end

對小至中規模企業而言：系統初始時可能會正常運作。然而隨著業務需求擴大也同時增加其團隊規模以及後續佈署及維護難度也逐漸提高。

內容解密：

  • 電商系統面臨問題？ 隨著團隊規模擴大維護及佈署也逐漸提高難度。
  • 如何適應業務需求擴大？ 需要針對需求變更以便適應潛在變動情境以縮減後續維護成本。

錯誤排除與降低風險

透過採取「錯誤排除」設計概念以便降低風險與提升維護效率。

內容解密：

  • 錯誤排除如何降低風險？ 提升可控性亦降低後續維護成本。
  • 如何實作與實施？ 需要針對不同業務場景設計不同處理策略。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。