微服務與容器化技術：現代軟體開發的根本

– 8 分鐘閱讀

微服務架構的核心價值在於將應用程式拆分成小型、獨立的服務，每個服務專注於特定的業務功能，並透過輕量級的通訊協定互動，例如 HTTP/REST 或訊息佇列。這種模組化設計提升了開發團隊的靈活性，允許使用不同的技術堆疊和程式語言，並促進快速佈署與迭代。然而，微服務也帶來了系統複雜性增加、分散式系統問題和安全性挑戰。實務上，從單體應用轉向微服務需要考量團隊的學習曲線、組織變革和成本效益。此外，服務間的通訊方式也至關重要，同步通訊適用於即時回應，而非同步通訊則適合降低耦合度。在建構微服務時，API 設計、錯誤處理和安全性是不可或缺的環節。而容器化技術，特別是 Docker，則簡化了微服務的佈署和管理。文章進一步探討了離線容器化技術，這對於無法連線網際網路的環境至關重要。透過 Dockerfile 定義應用程式環境，並將其封裝成映像檔，即可在目標環境中離線載入和執行。文章也提供 Python 和 Node.js 的離線佈署、更新和維護例項，涵蓋專案封裝、依賴函式倉管理和容器操作等關鍵步驟，展現了容器化技術在離線環境下的實用性。

微服務與容器化技術

微服務架構（Microservices Architecture）和容器化技術（Containerization）是現代軟體開發中的兩大重要趨勢。這些技術不僅改變了軟體的開發方式，還重新定義了應用程式的佈署和執行。以下將探討微服務與容器化技術的基本概念、優勢與挑戰，並結合實務案例進行分析。

微服務的基本概念

微服務架構是一種軟體設計風格，將應用程式拆分成一系列獨立的小型服務，每個服務專注於特定的業務功能。這些服務之間透過輕量級的通訊協定進行互動，通常使用HTTP/REST或訊息佇列。

模組化架構

模組化架構是微服務的核心理念。透過將應用程式拆分成多個小型、獨立的模組，開發團隊可以更靈活地進行開發和維護。每個模組可以使用不同的技術堆疊和程式語言，這使得技術選型更加靈活。

其他的優勢

除了模組化架構之外，微服務還具有以下優勢：

  1. 快速佈署與迭代：由於每個服務都是獨立的，開發團隊可以快速佈署和迭代某個特定功能，而不需要重新佈署整個應用程式。
  2. 技術多樣性：不同的服務可以使用不同的技術堆疊和程式語言，這使得技術選型更加靈活。
  3. 自動化與持續整合：微服務架構天然支援自動化測試和持續整合，這提高了開發效率和產品品質。

潛在挑戰

然而，微服務架構也帶來了一些挑戰：

  1. 複雜性增加：隨著服務數量的增加，系統的複雜性也隨之增加，這需要更強大的管理工具和策略。
  2. 分散式系統問題：如網路延遲、資料一致性等問題需要特別注意。
  3. 安全性問題：每個服務都需要單獨進行安全性保護，這增加了安全管理的難度。

切換到微服務架構

從傳統單體應用（Monolithic Application）轉向微服務架構是一個複雜的過程。以下是一些需要考慮的因素：

慣性與屬性

轉向微服務架構需要克服許多慣性。例如，團隊成員可能需要學習新技術和工具，而現有系統可能需要重構以適應新的架構。

組織學習曲線

組織在轉向微服務架構時會面臨一個學習曲線。團隊成員需要了解如何設計、開發和維護微服務。此外，還需要建立新的流程來支援自動化測試和持續整合。

商業案例

轉向微服務架構通常需要強有力的商業理由。例如，企業可能希望透過提高開發效率來降低成本或加快產品上市時間。

成本考量

轉向微服務架構會帶來一些初期成本，如培訓、工具購買和基礎設施升級等。然而，長期來看，這些投資可能會帶來更高的回報。

微服務之間的通訊

在微服務架構中，各個服務之間需要透過某種方式進行互動。這裡介紹幾種常見的通訊方式：

通訊型別

  1. 同步通訊：如HTTP/REST或gRPC，適用於需要即時回應的場景。
  2. 非同步通訊：如訊息佇列（Message Queue），適用於不需要即時回應或需要減少耦合度的場景。

準備撰寫網路服務

在撰寫網路服務時，需考慮以下幾點：

  1. API設計：設計清晰、簡潔且易於使用的API。
  2. 錯誤處理：設計良好的錯誤處理機制。
  3. 安全性：確保資料傳輸過程中的安全性。

微服務維護

微服務維護包括日常執行監控、故障排除以及定期更新等。以下是一些關鍵點：

  1. 監控與記錄：建立完善的監控和記錄系統以便及時發現問題。
  2. 故障排除：準備相應的故障排除策略以便快速還原。
  3. 更新與迭代：定期進行更新和迭代以確保系統穩定性和安全性。

涵蓋內容解密：API Gateway

API Gateway 是一個管理 API 請求並將其路由到適當後端服務的一個介面。它起到反向代理、負載平衡、安全防護等作用。API Gateway 的實施涵蓋以下幾點：

  1. API Gateway 的作用：API Gateway 是一個中介層，負責接受客戶端請求並將其路由到相應後端微服務；同時提供諸如請求限速、認證/授權、日誌記錄等功能。

  2. 常見實作方案：常見的 API Gateway 有 Kong、NGINX 和 AWS API Gateway 等；各自有其特點和適用場景。例如 Kong 主要強調高擴充套件性和外掛系統；NGINX 主要強調高效能；AWS API Gateway 則強調雲原生支援。

# 假設我們使用 Flask 和 Flask-Restful 建立簡單 API Gateway
from flask import Flask, request, jsonify
from flask_restful import Api, Resource
import requests

app = Flask(__name__)
api = Api(app)

class ProxyResource(Resource):
    def get(self, service):
        # 取得目標後端服務地址
        target_url = f"http://{service}/api/v1/resource"
        # 轉發請求到目標後端
        response = requests.get(target_url)
        return jsonify(response.json())

api.add_resource(ProxyResource, '/<string:service>')

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

內容解密：

  • 這段程式碼建立了一個簡單的 API Gateway 使用 Flask 框架。
  • ProxyResource 類別處理 GET 請求並將請求轉發到相應後端 microservice。
  • target_url 變數指定目標後端 microservice 的地址並利用 Python 的 requests 模組進行 HTTP 請求轉發。
  • if __name__ == '__main__': 條件陳述式確保 Flask 應用只在直接執行時執行並啟動伺服器在指定埠上。

離線容器化技術簡介

離線容器化技術是指在無法連線網際網路上執行容器化應用程式的一種方法。這在某些情況下非常有用。例如：

  • 隔離網路環境：某些企業因為安全或合規原因無法連線公共網際網路。
  • 損毀環境：佈署位置無法連線公共網際網路（例如遠洋船隻或偏遠地區）。
  • 敏感資料處理：處理敏感資料時無法上傳到雲端環境中。

離線容器化技術可以讓開發者在本地環境中建立所有所需檔案及依賴關係，並將它們封裝成容器映像（container image）。然後在目標環境中載入該映像並執行容器化應用程式。

# 本地環境中建立 Dockerfile
# Dockerfile 的內容：
FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt requirements.txt
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "./app.py"]

# 建立 Dockerfile 之後執行以下命令來建立容器映像：
# docker build -t my-python-app .

內容解密：

  • Dockerfile 是 Docker 構建映像時所需檔案，其內容規範瞭如何從基礎映像建立新映像。
  • FROM python:3.9-slim-buster 指定基礎映像為 Python 的官方 Slim Buster 檔案；WORKDIR /app 則設定工作目錄為 /app。
  • COPY requirements.txt requirements.txt 和 RUN pip install -r requirements.txt 則負責複製本地環境中的 requirements.txt 檔案並安裝相關依賴函式庫。
  • CMD ["python", "./app.py"] 指定當容器啟動時要執行哪一個指令。
# 建立映像成功後，
# 在目標環境中載入該映像：
# docker load < my-python-app.tar
# 執行容器：
# docker run -d --name my-python-container my-python-app

內容解密：

  • docker load < my-python-app.tar 用於在目標環境載入本地建立好的 Docker 映像檔案。
  • docker run -d --name my-python-container my-python-app 則在目標環境中啟動該容器並設定名稱為 my-python-container。
  • --d 標誌表示後台執行該容器； --name my-python-container 則指定該容器名稱為 my-python-container。

離線搬移專案例項

這裡給出具體例項說明如何將開發專案從本地離線環境搬移至遠端無連線網際網路環境下執行。

首先在本地建立專案並安裝依賴函式庫:

mkdir offline-project
cd offline-project
echo "flask==2.0.1" > requirements.txt

製作 Dockerfile:

FROM python:3.8-slim-buster

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-index --find-links=/app/dependencies -r requirements.txt

COPY . .

CMD ["flask", "run", "--host=0.0.0.0"]

製作好 Dockerfile 後建立 Docker Image:

docker build -t my-offline-app .

將專案所有檔案封裝成 tar.gz 包:

tar -czvf project.tar.gz *

在離線環境下載取 project.tar.gz 包並解壓縮:

tar -xzvf project.tar.gz

在此環境中建立一個空目錄 /app/dependencies:

mkdir -p /app/dependencies/

然後將安裝所需依賴函式庫檔案放置於 /app/dependencies/ 中:

cp *.whl /app/dependencies/

在此離線環境下載取該 Docker Image:

docker load < my-offline-app.tar.gz

最後執行該 Image:

docker run -d --name my-offline-app-container my-offline-app

此圖示展示離線搬移專案流程：

  graph TD;
    A[本地環境] -->|製作Dockerfile| B[Docker Image];
    B -->|封裝TAR| C[壓縮檔];
    C -->|傳送至離線環境| D[解壓縮檔];
    D -->|準備依賴函式庫| E[Docker Image];
    E --> F[執行專案];

此圖示展示離線搬移專案流程:

  • A: 本地準備好所有檔案及依賴函式庫檔案，
  • B: 製作 Docker Image；
  • C: 清單檔壓縮；
  • D: 在目標機器解壓縮；
  • E: 在目標機器準備好依賴函式庫檔案；
  • F: 下載取及執行專案。

離線更新應使用案例項

假設有一已佈署於離線環境中的 Django 應用程式，現在想要更新其中一些功能並重新佈署至原有機器上：

首先在本地更新專案內容: 修改 Django 應用原始碼並在本地測試無誤後製作 Dockerfile:

FROM python:3.8-slim-buster

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-index --find-links=/app/dependencies -r requirements.txt

COPY . .

CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

製作好 Dockerfile 後建立新版本 Docker Image:

docker build -t django-offline-update .

將專案所有檔案及 dependencies (如果有更新) 改變部分封裝成 tar.gz 包:

tar -czvf django-update.tar.gz *

傳送 django-update.tar.gz 包至遠端機器上的對應位置並在該機器解壓縮:

tar -xzvf django-update.tar.gz

下載取最新版本 Docker Image:

docker load < django-offline-update.tar.gz .

最後停止舊版應用並啟動最新版本:

docker stop old-django-app-container && docker rm old-django-app-container &&
docker run -d --name updated-django-app-container django-offline-update .

此圖示展示更新 Django 應用流程：

  graph TD;
    A[本地更新專案] --> |製作Dockerfile| B[Docker Image];
    B --> |封裝TAR| C[壓縮檔];
    C --> |傳送至離線環境| D[解壓縮檔];
    D --> |準備依賴函式庫| E[Docker Image];
    E --> F[執行專案];

此圖示展示更新 Django 應用流程:

  • A: 在本地完成對專案所需修改；
  • B: 製作新版本 Docker Image；
  • C: 清單檔壓縮；
  • D: 在目標機器解壓縮；
  • E: 在目標機器準備好依賴函式庫檔案；
  • F: 下載取及執行最新版本專案, 停止舊版本, 啟動最新版本.

離線維護升級例項

假設有一已佈署於離線環境中的 Node.js 應用程式,現在想要更新其中一些功能並重新佈署至原有機器上: 首先在本地更新 Node.js 應用原始碼並在本地測試無誤後製作 Dockerfile:

FROM node:14-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install --production --no-audit --offline && npm cache clean --force

COPY . .

EXPOSE 8080

CMD ["node", "server.js"]

製作好 Dockerfile 後建立新版本 Docker Image:

docker build -t nodejs-offline-update .

將專案所有檔案及 dependencies (如果有更新) 改變部分封裝成 tar.gz 包:

tar -czvf nodejs-update.tar.gz *

傳送 nodejs-update.tar.gz 包至遠端機器上的對應位置並在該機器解壓縮:

tar -xzvf nodejs-update.tar.gz .

下載取最新版本 Docker Image:

docker load < nodejs-offline-update.tar.gz .

最後停止舊版應用並啟動最新版本:

docker stop old-nodejs-app-container && docker rm old-nodejs-app-container &&
docker run -d --name updated-nodejs-app-container nodejs-offline-update .

此圖示展示更新 Node.js 應用流程：

  
graph TD;
    A[本地更新專案] --> |製作Dockerfile| B[Docker Image];
    B --> |封裝TAR| C[壓縮檔];
    C --> |傳送至離線環境| D[解壓縮檔];
    D --> |準備依賴函式庫| E[Docker Image];
    E --> F[執行專案];

此圖示展示更新 Node.js 應用流程: -A: 在本地完成對專案所需修改； -B: 製作新版本 Docker Image； -C: 清單檔壓縮； -D: 在目標機器解壓縮； -E: 在目標機器準備好依賴函式庫檔案； -F: 下載取及執行最新版本專案, 停止舊版本, 啟動最新版本.

玄貓

玄貓

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