微服務架構實施挑戰與反思

– 9 分鐘閱讀

微服務架構的匯入常根據改善單體架構的開發與維護效率，然而實務上卻經常演變成過於細碎的奈米服務，反而提高了系統複雜度。這源於對微服務的誤解和過度應用，尤其在小型產品或團隊中，將已具備微服務特性的應用再次拆分，反而降低了效率。本文探討微服務架構的優劣與常見的誤用情況，並以餐廳經營的比喻，闡述如何正確地將微服務應用於實際開發場景中，同時也說明瞭服務間通訊、錯誤處理、服務發現等關鍵技術的實踐方式，以確保微服務架構的有效性。

為什麼微服務很少成功？

微服務架構（Microservices Architecture, MSA）是一種軟體開發技術，它將大型應用程式分解為多個小型、獨立的服務，每個服務負責特定的業務功能。然而，許多企業在實施微服務時遇到了困難，導致微服務架構未能達到預期的效果。

微服務與奈米服務的區別

許多所謂的「微服務」其實是「奈米服務」（Nano-services）。這些服務過於細小，功能單一，彼此之間的依賴關係複雜，導致系統難以維護和管理。真正的微服務應該具備獨立性、可擴充套件性和明確的業務邊界。

微服務的歷史需求

要了解微服務的由來，需要回顧軟體架構的演變過程。早期的軟體系統大多採用單體架構（Monolithic Architecture），隨著業務需求的增長，單體架構逐漸暴露出其侷限性。

單體架構的問題

單體架構下，所有功能模組都集中在一個應用程式中，隨著系統複雜度的增加，開發、測試和佈署的難度也隨之增加。當團隊規模擴大到一定程度時，協調開發、測試和佈署的工作變得非常困難。

服務導向架構（SOA）的出現

為瞭解決單體架構的問題，服務導向架構（Service-Oriented Architecture, SOA）應運而生。SOA 將系統分解為多個獨立的服務，每個服務負責特定的業務功能。然而，在實踐中，SOA 往往變得過於複雜，服務之間的依賴關係混亂，部分業務邏輯被分散到企業服務匯流排（Enterprise Service Bus, ESB）中。

// 一個簡單的 SOA 架構示例
public class OrderService {
    public void processOrder(Order order) {
        // 呼叫其他服務處理訂單
        paymentService.processPayment(order);
        inventoryService.updateInventory(order);
    }
}

內容解密：

在這個例子中，OrderService 負責處理訂單，它呼叫了 paymentService 和 inventoryService 兩個其他服務。這種設計使得服務之間的依賴關係變得複雜，難以維護。

微服務架構的優勢

微服務架構旨在解決 SOA 的問題，它強調每個服務應該是獨立開發、佈署和擴充套件的，並且具有明確的業務邊界。微服務之間透過標準化的 API 進行通訊。

# 一個簡單的微服務架構示例
from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/orders', methods=['POST'])
def create_order():
    # 處理訂單建立邏輯
    order_id = order_service.create_order(request.json)
    return jsonify({'order_id': order_id}), 201

if __name__ == '__main__':
    app.run()

內容解密：

在這個例子中，我們使用 Flask 框架建立了一個簡單的微服務，它負責處理訂單建立的請求。這個微服務可以獨立於其他服務進行開發、佈署和擴充套件。

微服務架構的挑戰

儘管微服務架構具有許多優勢，但在實踐中仍然面臨著許多挑戰，例如：

  • 服務之間的通訊複雜度增加
  • 分散式事務的管理變得更加困難
  • 系統整體的可觀測性和監控變得更加複雜
  graph LR
    A[訂單服務] -->|呼叫| B[支付服務]
    A -->|呼叫| C[庫存服務]
    B -->|回傳| A
    C -->|回傳| A

圖表翻譯： 這個圖表展示了微服務架構中訂單服務、支付服務和庫存服務之間的通訊流程。訂單服務呼叫支付服務和庫存服務來完成訂單處理，並接收它們的回傳結果。

圖表翻譯詳細解析：

  1. 節點表示：圖表中的每個節點代表一個微服務，例如「訂單服務」、「支付服務」和「庫存服務」。
  2. 箭頭表示：箭頭表示微服務之間的呼叫關係，例如「訂單服務」呼叫「支付服務」和「庫存服務」。
  3. 流程說明：當「訂單服務」接收到訂單請求時，它會呼叫「支付服務」來處理支付，並呼叫「庫存服務」來更新庫存。處理完成後，「支付服務」和「庫存服務」會將結果回傳給「訂單服務」。

隨著技術的不斷進步，微服務架構將繼續演變。未來的微服務架構可能會更加註重自動化、智慧化和安全性。例如，透過引入人工智慧和機器學習技術，可以實作更智慧的服務治理和故障檢測。同時，透過採用更先進的安全技術，可以提高微服務架構的安全性。

總之，微服務架構是一種充滿挑戰和機遇的技術領域。透過不斷學習和創新，我們可以克服挑戰，充分發揮微服務架構的優勢，為業務成功奠定堅實的基礎。

為什麼微服務實施鮮少成功？

微服務被比喻為一道道獨立的菜餚，每道菜都有其特定的上下文和功能。理想的微服務應該具備以下特點：

  1. 獨立性：每個微服務如同單獨的一道菜，不與其他菜餚混合。
  2. 有限上下文：每道菜都有明確的定義，例如「抓飯」就是抓飯，不會與水果混合。
  3. 鬆散耦合：一道菜之後可以選擇另一道菜，例如在湯之後可以選擇任何配菜。
  4. 可擴充套件性：如果一份主菜不夠，可以再取一份。
  5. 易於測試：每道菜都可以單獨品嚐和測試。
  6. 可組態性：可以根據需求選擇是否新增特定配料。

然而，現實中微服務的實施往往未能達到預期效果。問題的核心在於錯誤地應用了微服務架構。

微服務被誤用

微服務最初是為了取代由數十名開發者共同維護的龐大單體架構而設計的。然而，現在的開發團隊通常規模較小，按照敏捷開發方法工作，負責開發小型產品或大型產品的一部分。

這些小型產品或產品的一部分已經具備了微服務的特徵：

  • 獨立上下文：每個產品或部分都有其獨立的功能和定義。
  • 鬆散耦合：不同產品或部分之間透過API進行通訊。
  • 獨立技術堆疊：每個產品或部分可以使用不同的技術堆疊。
  • 獨立資料儲存：每個產品或部分擁有自己的資料函式庫。
  • 獨立佈署：每個產品或部分可以獨立佈署。

事實上，這些小型產品或產品的一部分已經是微服務了。然而，開發團隊卻常常誤將它們視為單體架構，並試圖將其進一步拆分成更小的微服務，結果卻變成了「奈米服務」。

從單體到奈米服務：一個錯誤的例子

任務描述

實作為客戶列印電子收據的功能。收據資料儲存在後台辦公系統，而列印功能則透過外部營運商來實作。

初始架構

最初設計採用典型的六邊形架構：

  • 介面卡從後台辦公系統讀取收據資料並更新狀態。
  • 介面卡透過HTTP協定與外部營運商通訊，將收據傳送至列印並接收結果。
  • 業務邏輯控制資料傳送的流程和速度。

演算法步驟

  1. 服務透過介面卡從後台辦公系統取得收據資料，並在同一事務中記錄營運商分配和冪等鍵資訊。
  2. 服務轉換資料，並在記憶體中為每個營運商形成佇列。
  3. 服務透過介面卡將收據傳送至營運商進行列印。
  4. 服務接收營運商的回撥，並將已列印的收據資料寫回後台辦公系統。

這是一個典型的微服務架構，能夠確保資料一致性和可靠性。

變更架構：走向奈米服務

由於管理階層的強烈建議，架構被修改為「微服務」架構，但實際上變成了「奈米服務」架構。

變更後的架構將原有的微服務拆分為多個更小的服務，每個服務只負責非常狹隘的任務。這些「奈米服務」只有共同協作才能完成業務任務。

使用GRPC的原因

由於公司尚未引入Kafka，而舊的訊息匯流排即將被廢棄，因此選擇了GRPC作為服務間通訊的方式。

變更後的弊端

這種過度拆分的架構帶來了許多問題，包括但不限於：

  • 複雜度增加：更多的服務意味著更複雜的系統管理和除錯。
  • 效能問題：服務間通訊的開銷增加，可能會影響整體效能。
  • 一致性挑戰：多個小服務之間的資料一致性更難保證。

微服務架構的反思：以餐廳經營為喻

在現代軟體開發中，微服務架構已成為一種流行的設計模式。然而，過度細分微服務可能會導致一系列問題。本文將探討微服務架構的優缺點，並以餐廳經營為比喻，闡述如何正確實施微服務。

微服務架構的挑戰

在某些情況下，開發團隊可能會將微服務架構推向極端，將原本單一的服務拆分成多個極小的「奈米服務」（nano-services）。這種做法可能會導致以下問題：

  1. 實作難度增加：由於服務之間的互動變得更加複雜，需要編寫更多的額外程式碼來處理資料流、錯誤處理等問題。這增加了開發的複雜度和工作量。

    # 示例：處理服務間的錯誤處理
try:
    response = service_a.call()
    service_b.process(response)
except ServiceAError as e:
    logger.error(f"Service A error: {e}")
    # 處理錯誤的邏輯

    內容解密：

    • 這段程式碼展示瞭如何在呼叫服務A失敗時進行錯誤處理。
    • 使用try-except區塊捕捉特定的錯誤型別ServiceAError。
    • 記錄錯誤日誌並執行相應的錯誤處理邏輯。

  2. 維護成本增加：當系統被拆分成眾多奈米服務時，維護工作變得更加困難。需要對每個服務進行監控、報警、日誌記錄和除錯，這不僅增加了維運的負擔，也提高了整體的維護成本。

    # 示例：Docker Compose 組態檔案
version: '3'
services:
  service_a:
    image: service_a_image
    ports:
      - "8080:8080"
    depends_on:
      - service_b
  service_b:
    image: service_b_image
    ports:
      - "8081:8081"

    內容解密：

    • 這段組態定義了兩個服務：service_a和service_b。
    • service_a依賴於service_b，因此service_b必須先啟動。
    • 使用Docker Compose可以簡化多服務的佈署和管理。

  3. 過度設計：有時，系統的實際需求並不需要如此高的靈活性和可擴充套件性。過度設計可能會導致資源的浪費。

以餐廳經營為喻

為了更好地理解微服務架構，我們可以將其與餐廳經營相比較：

  • 一道菜代表一個微服務：每個菜餚應該是一個完整的實體，而不是一堆積散亂的食材。這意味著每個微服務應該是一個功能完整的單元，而不是被過度細分為奈米服務。

      graph LR;
    A[客戶] --> B[訂單服務];
    B --> C[廚房服務];
    C --> D[出餐];

    圖表翻譯：

    • 此圖示展示了客戶訂單流程：客戶下單後，訂單服務處理訂單並通知廚房服務進行製作，最終出餐給客戶。
    • 每個節點代表一個獨立的服務，彼此協同工作以完成整個流程。

  • 基礎設施如同調味料：鹽罐、胡椒瓶和紙巾是共用的基礎設施，而不是每個餐桌都備有這些物品。同樣，基礎設施服務應該是分享的，而不是被重複實作。

  • 餐桌和裝置如同硬體和軟體：每個客人有自己的座位和餐具，這些共同構成了資訊系統（IS）。

  • 多個餐桌形成一個域：多個餐桌聚集在一起，形成一個完整的用餐區域，這對應於IT架構中的域。

  • 整個餐廳如同企業IT景觀：所有這些域共同構成了企業的IT環境。

正確實施微服務

許多公司深受過度分解的困擾，他們驕傲地宣稱擁有數百甚至上千個微服務，卻忽略了背後的基礎設施成本和維護難度。新的開發人員可能需要數月時間才能完全理解這些服務，而定位一個簡單的錯誤可能需要一週時間。

根據上述經驗教訓，我們提出以下建議：

不要將小型產品過度細分為奈米服務，這將扼殺其發展潛力。給予產品成長的機會，讓它在適當的時候自然演化成更適合的架構。

隨著技術的不斷進步，微服務架構也在不斷演化。未來，我們可以期待更多的新技術和新方法來簡化微服務的管理和維護。例如，Serverless架構、Service Mesh等技術，都為微服務架構帶來了新的可能性。

# 示例：使用 Service Mesh 進行服務發現
import grpc

# 建立 gRPC 通道
channel = grpc.insecure_channel('service_a:50051')
stub = service_a_pb2_grpc.ServiceAStub(channel)

# 呼叫服務
response = stub.Call(request)

內容解密：

  • 這段程式碼展示瞭如何使用gRPC進行服務間的呼叫。
  • 透過Service Mesh技術，可以簡化服務發現和負載平衡的實作。
  • 使用gRPC可以提高服務間通訊的效率和可靠性。

透過不斷探索和實踐，我們可以更好地利用微服務架構來推動業務創新和發展。

玄貓

玄貓

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