微服務架構雖然提升了系統彈性，但也引入了服務間通訊的效率問題。網路傳輸速度的限制會影響整體效能，因此，快取機制和同位置佈署策略能有效減少網路通訊的依賴，提升微服務間的互動效率。對於不適合微服務架構的系統部分，應盡量保持其精簡，方便佈署和協調。系統設計需考慮未來的變化，降低模組間的耦合度並提升內聚性，以利後續修改和維護。中間層和策略模式的應用可以有效管理介面變更，提升系統的可修改性和擴充套件性。
微服務的效率與協調
微服務架構的優點在於其模組化和彈性，但也帶來了一些挑戰。其中一個主要挑戰是微服務之間的溝通。由於微服務是獨立佈署和執行的，因此它們之間的溝通需要透過網路傳遞訊息。然而，網路傳遞的速度遠遠慢於記憶體存取，這可能會對系統的效率產生負面影響。
為了減少對網路溝通的依賴，玄貓提出了一些基本技術：
- 快取：快取可以儲存網路請求的結果，以便下次請求時可以直接從記憶體中讀取，減少網路傳遞的需求。這種技術常用於資料函式庫請求和 AI 模型請求。
- 同位置：同位置允許兩個微服務之間的溝通直接在記憶體中進行，而不是透過網路傳遞訊息。雖然這種方法仍然需要封裝資料到訊息中，但可以減少網路傳遞的開銷。
如果系統中有一些部分不適合使用微服務架構，則應該將其識別出來並不將其封裝為微服務。這些部分應該盡可能保持小巧，以便於佈署和協調。
設計可修改性
事物總是在變化，這是生活的一部分。在設計 AI 系統時，預測可能發生的變化可以使系統更容易修改以應對這些變化。設計系統時應該盡量減少不同元件之間的耦合度，同時提高元件內部的凝聚度。耦合度是指兩個不同元件之間的責任重疊程度。如果一個責任在多個元件中被計算多次，則對這個責任的修改就需要涉及多個元件。凝聚度則是指一個元件專注於單一任務的程度。目標是盡可能地區域性化修改，以減少對多個元件的影響。
在 AI 系統中，可能發生的變化包括用於訓練模型的資料和選擇使用的模型。當訓練資料發生變化時，MLOps 提供了技術來跟蹤和管理這些變化。設計系統以允許模型變化則更加複雜。
為了允許元件發生變化，一種標準技術是建立一個中間層，位於元件的客戶端和元件本身之間。就模型而言，這意味著模型的客戶端（假設它們被封裝為容器）將與一個中間層互動，而中間層再與模型互動。這個中間層可以用來緩衝模型的變化。著名的策略模式可以在這裡應用，以便於在不同版本的實作之間切換。
假設有一個簡單的例子，新版本的模型修改了其介面。然後，中間層可以將客戶端的呼叫轉換為新的介面。因此，客戶端不需要修改，對模型介面變化的修改被區域性化到中間層。使用這種方法，可以使系統更容易適應變化，並提高其可維護性和擴充套件性。
軟體開發流程最佳實踐
在軟體開發過程中，管理版本差異和確保不同模組之間的相容性是一個重要的挑戰。為了減少版本差異對佈署的影響，我們建議使用中間層來管理介面變化。
非 AI 模組的開發
模組是軟體中的一個功能單元，服務則是透過多個模組和其支援函式庫的整合而構建。在採用微服務架構時，每個服務可以由其所有者團隊選擇語言和技術進行開發。但是，服務內的個別模組必須遵循玄貓制定的標準。
單元測試是一種在單個模組內進行的測試，具有明確的輸入和輸出。輸入透過測試框架提供給模組，然後比較模組的輸出與預期輸出。單元測試通常在開發過程中和系統測試階段都會執行。
在測試框架中包含負載平衡器等依賴基礎設施，可以使模組與基礎設施之間的互動作用得到測試。依賴服務可以被模擬或 Stub 化，以便測試能夠執行。單元測試應該涵蓋：
- 常見使用案例
- 邊緣案例（不尋常的輸入或意外情況）
- 負面案例（應該導致錯誤或適當警告的輸入）
建構階段
建構階段是準備虛擬機器或容器的可執行映像的地方。這是 AI 模組和非 AI 模組合併成可執行映像的階段。
合併 AI 和非 AI 模組
建構環境在 AI 模型發布或非 AI 模組檢入版本控制時啟動。由於 AI 模型被封裝為程式碼模組，因此 AI 模型和非 AI 模組在建構過程中被同等對待。建構環境建立了一個可佈署的可執行檔，這是使用連續整合（CI）伺服器（如 Jenkins）完成的。
CI 伺服器可以由玄貓觸發。CI 伺服器載入所有系統要包含在可佈署映像中的元素的最新版本。其中一些元素從版本控制系統中檢索，有些從模型倉函式庫中檢索，有些是從其他來源下載的依賴項。然後，CI 伺服器將建立的映像放在一個臨時伺服器上。
CI 伺服器活動
CI 伺服器的活動包括：
- 載入最新版本的所有元素
- 合併 AI 和非 AI 模組
- 建立可佈署的可執行檔
- 將映像放在臨時伺服器上
圖表翻譯
graph LR
A[開始] --> B[載入最新版本]
B --> C[合併AI和非AI模組]
C --> D[建立可佈署檔]
D --> E[將映像放在臨時伺服器]
內容解密
上述流程圖展示了 CI 伺服器的活動，從載入最新版本到將映像放在臨時伺服器。每一步驟都對應著特定的動作，確保軟體開發流程的順暢進行。
軟體開發流程中的自動化測試與佈署
在軟體開發的過程中，自動化測試和佈署是一個非常重要的步驟。這個步驟不僅能夠確保軟體的品質和穩定性，也能夠提高開發的效率和速度。
自動化測試
自動化測試是指使用自動化工具和指令碼來執行軟體測試的過程。這種測試方式可以幫助開發人員快速地檢測出軟體中的錯誤和問題，並且能夠節省大量的時間和人力。
在自動化測試中，需要考慮以下幾個方面：
- 單元測試：單元測試是指對軟體中的個別單元進行測試。這種測試方式可以幫助開發人員檢測出軟體中的錯誤和問題。
- 整合測試：整合測試是指對軟體中的多個單元進行整合測試。這種測試方式可以幫助開發人員檢測出軟體中的錯誤和問題。
- 系統測試：系統測試是指對整個軟體系統進行測試。這種測試方式可以幫助開發人員檢測出軟體中的錯誤和問題。
佈署
佈署是指將軟體佈署到生產環境中的過程。這個步驟需要考慮以下幾個方面：
- 環境準備：需要準備好生產環境，包括硬體和軟體等。
- 軟體安裝：需要將軟體安裝到生產環境中。
- 組態設定：需要設定好軟體的組態，包括資料函式庫連線、網路設定等。
持續整合和持續佈署
持續整合（CI）和持續佈署（CD）是兩種非常重要的軟體開發實踐。CI 是指將程式碼變更整合到主分支中的過程，而 CD 是指將軟體佈署到生產環境中的過程。
在 CI/CD 中，需要考慮以下幾個方面：
- 程式碼審查：需要對程式碼變更進行審查，以確保程式碼的品質和安全性。
- 自動化測試：需要對軟體進行自動化測試，以確保軟體的品質和穩定性。
- 佈署：需要將軟體佈署到生產環境中，以確保軟體的可用性和效能。
軟體供應鏈管理
軟體供應鏈管理是指管理軟體開發和佈署過程中所涉及的各種元件和依賴關係的過程。這種管理方式可以幫助開發人員確保軟體的品質和安全性，並且能夠提高開發的效率和速度。
在軟體供應鏈管理中，需要考慮以下幾個方面：
- 元件管理：需要管理好軟體開發和佈署過程中所涉及的各種元件，包括函式庫、框架等。
- 依賴關係管理：需要管理好軟體開發和佈署過程中所涉及的各種依賴關係，包括程式碼依賴、資料依賴等。
微服務架構雖提升了系統彈性與開發效率，但也引入了服務間通訊的效能挑戰。本文探討的快取與同位置策略，有效降低了網路通訊的延遲，然而並非所有系統元件都適用微服務化。對於不適合微服務化的部分，應維持其精簡性，並審慎評估其與整體架構的整合策略。技術限制深析顯示，服務間介面變更仍是微服務架構的一大挑戰。匯入中間層以及策略模式，能有效隔離變更影響，提升系統的可修改性。實務落地分析指出，建構階段的自動化整合流程至關重要。CI 伺服器扮演整合 AI 模型與非 AI 模組的核心角色，其版本控制、依賴管理與可佈署映像生成的能力，直接影響佈署效率。玄貓認為，隨著服務網格等技術的成熟，微服務架構的管理複雜度將逐步降低，其應用範圍將進一步擴大，未來發展值得密切關注。
