行動應用程式微服務架構設計與實踐

– 21 分鐘閱讀

隨著行動應用程式日益普及，後端架構設計的重要性也隨之提升。微服務架構提供更高的可擴充套件性、可維護性和效能，成為行動應用程式後端架構的熱門選擇。本文將探討如何設計和實踐一個根據微服務的行動應用程式後端架構，並深入探討儲存機制、微服務拆分策略以及監控和管理等關鍵導向。同時，文章也將分享一些實用的技巧和工具，例如日誌記錄、錯誤處理、自動健康檢查和可觀察性，以確保微服務在生產環境中的可靠性和可維護性。此外，文章還會探討如何使用 Kubernetes 佈署和管理微服務，以及如何使用日誌分析工具來診斷和解決問題。

行動應用程式的微服務架構

隨著行動應用程式的普及，後端架構的設計變得越來越重要。一個良好的架構可以提高應用程式的可擴充套件性、可維護性和效能。以下是行動應用程式的一個微服務架構設計。

儲存機制

行動應用程式需要儲存各種資料，例如使用者資料、影片資料等。為了提高儲存效率和可擴充套件性，採用多種儲存機制是必要的。例如，Amazon Web Services (AWS) 的儲存服務可以用於儲存影片資料，而其他資料可以儲存在關係型資料函式庫中。

儲存抽象層

為了抽象儲存機制，引入了一個微服務，負責管理儲存機制。這個微服務提供了一個統一的介面，讓其他微服務可以存取和管理資料，而不需要關心底層的儲存機制。

影片儲存

影片儲存是行動應用程式中的一個重要部分。為了提高影片儲存的效率和可擴充套件性，採用了一個專門的微服務，負責管理影片儲存。

個人化推薦

個人化推薦是提高使用者經驗的一個重要功能。為了實作個人化推薦，引入了一個新的微服務，負責管理使用者的收藏和觀看歷史，並根據這些資料提供個人化的推薦。

使用者管理

使用者管理是行動應用程式中的一個重要部分。為了提高使用者管理的效率和可擴充套件性，採用了一個新的微服務，負責管理使用者和他們的帳戶。

廣告管理

廣告管理是行動應用程式中的一個重要部分。為了提高廣告管理的效率和可擴充套件性，採用了一個新的微服務，負責管理廣告。

內容解密：

上述微服務架構設計可以提高行動應用程式的可擴充套件性、可維護性和效能。每個微服務都有其特定的功能，讓開發人員可以專注於特定的功能，提高開發效率和品質。

  graph LR
    A[行動應用程式] --> B[儲存抽象層]
    B --> C[影片儲存]
    B --> D[個人化推薦]
    B --> E[使用者管理]
    B --> F[廣告管理]

圖表翻譯：

上述 Mermaid 圖表展示了行動應用程式的微服務架構設計。圖表中，每個矩形代表一個微服務，箭頭代表了微服務之間的關係。儲存抽象層是核心微服務，負責管理儲存機制，而其他微服務則負責特定的功能，如影片儲存、個人化推薦、使用者管理和廣告管理。這個設計可以提高行動應用程式的可擴充套件性、可維護性和效能。

微服務開發的未來之路

在微服務開發的旅程中，我們經常會遇到各種挑戰和問題。但是，透過不斷的學習和實踐，我們可以逐步克服這些困難，成為更加熟練的微服務開發者。

微服務開發的關鍵

微服務開發的關鍵在於如何設計和實作一個穩定、可擴充套件和易於維護的系統。這需要我們對微服務的原理和最佳實踐有深入的理解。

外部資料函式庫和伺服器

在微服務架構中，外部資料函式庫和伺服器扮演著重要的角色。它們可以幫助我們實作資料的持久化和分享，同時也可以提高系統的可擴充套件性和可靠性。

狀態無關的叢集

狀態無關的叢集是一種可以幫助我們實作微服務之間無狀態通訊的技術。這種技術可以提高系統的可擴充套件性和可靠性，同時也可以簡化微服務之間的通訊。

UI 開發和微服務

UI 開發和微服務之間有著密切的關係。透過使用合適的 UI 框架和工具，我們可以建立出更加使用者友好的介面，同時也可以提高系統的可擴充套件性和可靠性。

React 和 Angular

React 和 Angular 是兩種流行的 UI 框架，它們可以幫助我們建立出更加使用者友好的介面。透過使用這些框架，我們可以簡化 UI 開發的過程，同時也可以提高系統的可擴充套件性和可靠性。

微服務開發的最佳實踐

微服務開發的最佳實踐包括了許多方面，例如設計原理、實作細節、測試和佈署等。透過遵循這些最佳實踐，我們可以建立出更加穩定、可擴充套件和易於維護的微服務系統。

測試和佈署

測試和佈署是微服務開發中非常重要的兩個環節。透過使用合適的測試框架和工具，我們可以簡化測試的過程，同時也可以提高系統的可靠性。同時，透過使用合適的佈署策略，我們可以簡化佈署的過程，同時也可以提高系統的可擴充套件性。

圖表翻譯：

上述圖表展示了微服務開發的整體流程。從左到右，圖表分別展示了微服務開發、設計原理、實作細節、測試和佈署等環節。同時，圖表也展示了狀態無關的叢集、外部資料函式庫和伺服器、測試框架和工具、佈署策略等相關概念。透過這個圖表，我們可以更好地理解微服務開發的整體流程和相關概念。

健康微服務的維護

隨著應用程式的複雜度增加，我們需要技巧來對抗問題並保持微服務的健康。業界已經開發了許多最佳實踐和模式來處理問題。在本章中，我們將涵蓋一些最有用的技巧。遵循這些指導將使您的應用程式執行更加順暢，更加可靠，從而減少壓力，並在問題發生時更容易從中還原。

11.1 保持微服務的健康

一個健康的微服務應用程式由健康的微服務組成。一個健康的微服務是指不會出現當機、錯誤、CPU過載或記憶體耗盡等問題的微服務。要了解應用程式的健康狀態，我們需要：

  • 觀察微服務的行為以瞭解其過去和當前的狀態。
  • 當問題發生時採取行動以保護客戶。
  • 分類別問題，以便首先解決最嚴重的問題。
  • Debug 問題並根據需要應用修復。

使用 FlixTube 的元資料微服務作為示例，圖 11.1 顯示了生產環境中健康微服務的基礎設施。請注意，有多個微服務的複製品，且使用負載平衡器將請求均勻分配到微服務的例項中。如果任何單個微服務失效，則可以有一個複製品在失效例項重新啟動時替代它。

這種冗餘確保了微服務和應用程式的持續可靠性。在本章中，您將學習如何在 Kubernetes 上複製微服務以及其他促進容錯和從錯誤中還原的技術。

11.2 監控和管理微服務

將應用程式佈署到生產環境只是第一步。之後，我們需要不斷地知道應用程式是否正常執行，特別是在推出新的程式碼更新時。

表 11.1 列出了本章中您將學習的主要技術，以便了解微服務的行為。

技術描述
日誌記錄輸出關於微服務行為的訊息，以顯示當前發生的事情
錯誤處理有策略地管理和從錯誤中還原
自動健康檢查組態 Kubernetes 自動檢測微服務中的問題
可觀察性輸出和記錄可用於瞭解微服務之間互動作用的遙測資料

當發生問題時，我們需要調查和 Debug 以找到問題的原因並進行修復。在本章中，您將學習找到問題原因的策略，以便您可以進行修復。

微服務監控與分析

在微服務架構中，監控和分析每個服務的行為對於確保整體系統的效能和可靠性至關重要。為了實作這一點，我們需要使用適合的軟體工具來監控、視覺化和理解應用程式的行為。

監控和視覺化工具

有多種軟體工具可用於監控和視覺化微服務的行為，例如：

  • 日誌記錄：收集和儲存每個服務的日誌記錄，以便於除錯和故障排除。
  • 事件跟蹤：跟蹤每個服務的事件，以便於瞭解系統的行為。
  • 追蹤：跟蹤每個服務的請求，以便於瞭解系統的效能。
  • 指標：收集和儲存每個服務的指標，以便於瞭解系統的效能。

使用元資料微服務作為示例

以元資料微服務為例，我們可以看到如何使用日誌記錄、事件跟蹤、追蹤和指標來監控和分析其行為。

  • 日誌記錄：元資料微服務的日誌記錄被儲存到一個資料函式庫中，以便於除錯和故障排除。
  • 事件跟蹤：元資料微服務的事件被跟蹤，以便於瞭解系統的行為。
  • 追蹤：元資料微服務的請求被跟蹤，以便於瞭解系統的效能。
  • 指標：元資料微服務的指標被收集和儲存，以便於瞭解系統的效能。

資料聚合和轉發

資料聚合和轉發是微服務監控和分析中的重要步驟。透過聚合和轉發資料，我們可以更好地瞭解系統的行為，並對其進行最佳化。

  • 資料聚合：收集和聚合每個服務的資料，以便於瞭解系統的行為。
  • 資料轉發：轉發聚合的資料到其他系統或工具，以便於進行進一步的分析和視覺化。

開發人員和營運人員

開發人員和營運人員可以使用監控和分析工具來檢視應用程式的效能，並對其進行最佳化。

  • 效能檢視：檢視應用程式的效能，以便於瞭解其行為。
  • 最佳化：對應用程式進行最佳化，以便於提高其效能和可靠性。

內容解密：

以上內容介紹了微服務監控和分析的重要性，並展示瞭如何使用適合的軟體工具來監控、視覺化和理解應用程式的行為。透過使用日誌記錄、事件跟蹤、追蹤和指標，我們可以更好地瞭解系統的行為，並對其進行最佳化。同時，資料聚合和轉發也是重要步驟，可以幫助我們更好地瞭解系統的行為，並對其進行最佳化。最後，開發人員和營運人員可以使用監控和分析工具來檢視應用程式的效能，並對其進行最佳化。

  flowchart TD
    A[應用程式] --> B[監控工具]
    B --> C[日誌記錄]
    B --> D[事件跟蹤]
    B --> E[追蹤]
    B --> F[指標]
    C --> G[資料函式庫]
    D --> H[事件跟蹤系統]
    E --> I[追蹤系統]
    F --> J[指標系統]
    G --> K[資料聚合]
    H --> K
    I --> K
    J --> K
    K --> L[資料轉發]
    L --> M[其他系統或工具]

圖表翻譯：

以上圖表展示了微服務監控和分析的流程。應用程式被監控工具跟蹤，監控工具收集日誌記錄、事件跟蹤、追蹤和指標等資料。這些資料被儲存到資料函式庫、事件跟蹤系統、追蹤系統和指標系統中。然後，資料被聚合並轉發到其他系統或工具，以便於進行進一步的分析和視覺化。

微服務架構下的系統管理和故障排除

在微服務架構中，每個服務都是獨立的，並且可能使用不同的程式設計語言和資料函式庫。這種架構可以提高系統的可擴充套件性和容錯性，但也增加了系統管理和故障排除的複雜性。

微服務的元資料管理

每個微服務都有自己的元資料，包括組態檔案、日誌檔案和效能監控資料。為了方便管理和維護，通常會使用一個單獨的微服務來管理所有其他微服務的元資料。這個元資料微服務可以提供一個統一的介面來存取和管理所有微服務的元資料。

微服務的複製和負載平衡

為了確保系統的高用性和容錯性，通常會為每個微服務建立多個複製品。這些複製品可以分佈在不同的伺服器上，以便當一個伺服器失敗時，其他伺服器可以接管其工作負載。負載平衡器可以用來將incoming請求和訊息分配到多個微服務複製品中，從而提高系統的整體效能和可靠性。

負載平衡器的工作原理

負載平衡器可以根據不同的演算法將incoming請求和訊息分配到多個微服務複製品中。例如，可以根據每個複製品的當前工作負載、回應時間或其他效能指標來進行分配。這樣可以確保每個微服務複製品的工作負載是合理的，從而提高系統的整體效能和可靠性。

遙測資料的收集和分析

遙測資料是指系統執行時產生的各種資料，包括日誌檔案、效能監控資料和其他診斷訊息。收集和分析遙測資料可以幫助開發人員瞭解系統的執行情況，找出潛在的問題和瓶頸，並進行相應的最佳化和故障排除。

收集遙測資料的方法

有多種方法可以用來收集遙測資料，包括使用日誌收集工具、效能監控工具和其他診斷工具。例如，可以使用ELK Stack（Elasticsearch、Logstash、Kibana）來收集和分析日誌檔案，使用Prometheus和Grafana來收集和分析效能監控資料。

故障排除和問題解決

當系統出現故障或問題時，需要進行快速和有效的故障排除和問題解決。這可以透過分析遙測資料、檢查系統日誌和進行診斷測試來完成。同時，也需要有一套完整的故障排除流程和問題解決流程，以確保問題可以快速和有效地解決。

故障排除流程

故障排除流程通常包括以下步驟：

  1. 收集和分析遙測資料，以瞭解系統的執行情況和故障原因。
  2. 檢查系統日誌，以瞭解故障的具體情況和原因。
  3. 進行診斷測試，以確認故障的原因和範圍。
  4. 制定和實施故障排除計劃，以解決故障和還原系統正常執行。
  5. 跟蹤和驗證故障排除結果，以確保問題已經完全解決。

監控和管理微服務

在生產環境中，透明度對於應用程式的行為至關重要。否則，我們將無法瞭解應用程式內部發生的事情，也無法在不知道問題存在的情況下解決它們。在本文中，我們將探討一些監控微服務行為的技術：

  • 日誌記錄
  • 錯誤處理
  • 自動健康檢查
  • 可觀察性

11.2.1 開發中的日誌記錄

日誌記錄是理解微服務行為的最基本工具。透過日誌記錄，我們輸出一個文字流，顯示應用程式內部發生的重要事件、活動和操作。來自應用程式的日誌流可以被視為應用程式的歷史，顯示其生命週期中發生的每一件重要事情。我們可以在開發和生產環境中使用控制檯日誌記錄。圖 11.2 展示了它如何適用於開發中的「資訊」微服務。

每個微服務，如同每個行程一樣，都有兩個輸出流用於日誌記錄：

  1. 標準輸出
  2. 標準錯誤

在 JavaScript 中，我們將日誌記錄輸出到標準輸出通道，如下所示：

console.log("這裡輸出有用的資訊");

我們將錯誤輸出到標準錯誤通道，如下所示：

console.error("這裡輸出有用的錯誤資訊");

內容解密：

上述程式碼片段展示瞭如何在 JavaScript 中使用 console.log() 和 console.error() 輸出日誌記錄和錯誤訊息。這些方法分別將輸出寫入標準輸出和標準錯誤流中，允許開發人員在控制檯中檢視應用程式的行為和錯誤。

自動健康檢查

Kubernetes 可以對微服務進行自動健康檢查。這使得我們可以確保微服務正在執行並正常回應。圖 11.1 顯示了生產環境中健康微服務的基礎設施。

圖表翻譯：

  graph LR
    A[微服務] -->|健康檢查|> B[健康狀態]
    B -->|正常|> C[繼續執行]
    B -->|異常|> D[觸發警示]

上述 Mermaid 圖表描述了微服務的健康檢查過程。當微服務接受健康檢查時，它會傳回自己的健康狀態。如果狀態正常，則繼續執行；如果狀態異常，則觸發警示機制。

監控和管理技術

監控微服務的行為需要多種技術的結合，包括日誌記錄、錯誤處理、自動健康檢查和可觀察性。透過這些技術，我們可以確保微服務的可靠性、可擴充套件性和可維護性。

圖表翻譯：

  graph LR
    A[日誌記錄] -->|提供歷史記錄|> B[可觀察性]
    C[錯誤處理] -->|提供錯誤訊息|> B
    D[自動健康檢查] -->|提供健康狀態|> B

上述 Mermaid 圖表展示了不同監控技術之間的關係。日誌記錄、錯誤處理和自動健康檢查都為可觀察性提供了重要的資訊，從而使我們能夠全面地瞭解微服務的行為和狀態。

錯誤處理與日誌記錄

在微服務架構中，錯誤處理和日誌記錄是兩個非常重要的方面。錯誤處理可以幫助我們應對和還原錯誤，而日誌記錄可以提供有價值的資訊來幫助我們診斷和解決問題。

錯誤處理

錯誤處理是指當錯誤發生時，我們如何應對和還原的過程。以下是一些錯誤處理的例子：

  • 執行時錯誤（例如，異常被丟擲，導致微服務當機）
  • 壞資料被輸入（例如，來自故障感測器或人為錯誤的資料輸入）
  • 程式碼被用於意外的組合或方式
  • 第三方依賴失敗（例如，RabbitMQ）
  • 外部依賴失敗（例如，Azure Storage）

我們需要計劃如何處理和還原錯誤，以最小化對使用者和業務的傷害。當錯誤發生時，我們需要思考如何應對和還原。

日誌記錄

日誌記錄是指將有關應用程式的事件和細節記錄下來的過程。以下是一些需要記錄的例子：

  • 應用程式中的重要事件和細節
  • 重要操作的成功或失敗

以下是一些不需要記錄的例子：

  • 從其他來源可以輕易確定的東西
  • 機密或敏感的資訊
  • 使用者的個人細節

如果你發現自己被太多細節淹沒，可以刪除不必要的日誌記錄。對於每個控制檯日誌，你只需要問自己一個問題：我能夠沒有這個細節嗎？如果你不需要它，可以刪除它。

一般來說，更多的日誌記錄比少的要好。當你在生產環境中除錯時，你需要所有可能的幫助來瞭解問題發生的原因。追蹤日誌記錄是瞭解導致問題的事件序列的一個重要步驟。

你不能在問題發生後增加更多的日誌記錄！好吧，你可以，如果你隔離和重現了問題，但這本身就可能很困難。更多的日誌記錄更好，因為當你遇到問題時，你希望有盡可能多的資訊來幫助你解決它。

監控和管理微服務

在我們的JavaScript程式碼中，我們通常會預期錯誤並使用異常、回呼或承諾來處理它們。在這些情況下，我們通常知道該怎麼做。我們可以重試失敗的操作，或者，如果可能，我們可能會糾正問題並重新啟動操作，如果沒有明顯的自動糾正動作。或者，我們可能需要將錯誤報告給使用者或通知我們的營運人員。

有時候，我們可以預期錯誤，但有時候不能。我們可能會錯過某些型別的錯誤，因為我們不知道它們可能發生，或者因為某些型別的錯誤（例如，硬碟故障）發生得如此之少，以至於不值得專門處理它們。但是，為了安全起見，我們必須考慮到那些我們甚至無法想象的錯誤！

我們需要一個通用的策略來處理意外的錯誤。對於任何過程，包括個別微服務，這基本上可以歸結為兩個主要選擇：中止和重新啟動或繼續操作。你可以在圖11.3中看到這些錯誤處理策略。

中止和重新啟動

中止和重新啟動策略攔截意外的錯誤並以簡單的方式回應：忽略我們不關心的任何錯誤。任何我們沒有明確使用try/catch陳述式處理的異常都會導致過程中止。

這是最簡單的錯誤處理策略，因為它基本上意味著什麼都不做。只要允許意外的錯誤發生，並讓Node.js在回應中終止我們的程式即可。

繼續操作

繼續操作策略攔截意外的錯誤並以更複雜的方式回應：繼續執行程式並忽略錯誤。這種策略需要更多的程式碼和邏輯來實作，因為我們需要決定何時繼續執行程式以及何時終止它。

無論哪種策略，我們都需要考慮到錯誤處理和日誌記錄，以確保我們可以診斷和解決問題，並盡量減少對使用者和業務的傷害。

  flowchart TD
    A[開始] --> B[預期錯誤]
    B --> C[處理預期錯誤]
    C --> D[繼續執行]
    A --> E[意外錯誤]
    E --> F[中止和重新啟動]
    E --> G[繼續操作]
    F --> H[重新啟動程式]
    G --> I[繼續執行程式]

圖表翻譯：

上述流程圖描述了微服務中的錯誤處理流程。首先，我們需要預期可能發生的錯誤，並使用try/catch陳述式或其他機制來處理它們。如果發生預期錯誤，我們可以使用相應的程式碼來處理它。如果發生意外錯誤，我們可以選擇中止和重新啟動或繼續操作。中止和重新啟動策略會終止程式並重新啟動它，而繼續操作策略會忽略錯誤並繼續執行程式。無論哪種策略，我們都需要考慮到日誌記錄，以確保我們可以診斷和解決問題，並盡量減少對使用者和業務的傷害。

處理微服務異常錯誤的策略

在微服務架構中，錯誤和異常是不可避免的。因此，設計一個合理的錯誤處理機制是非常重要的。這裡，我們將探討兩種常見的錯誤處理策略：中止和重啟（Abort and Restart）以及繼續操作（Resume Operation）。

中止和重啟

當微服務出現異常錯誤時，中止和重啟是一種簡單直接的處理方式。這種策略依賴於 Kubernetes 的自動重啟機制，當容器例項失敗時，Kubernetes 會自動啟動一個新的例項。這種方法的優點是簡單易行，但也可能導致服務短暫中斷。

繼續操作

繼續操作策略則嘗試攔截異常錯誤，並在不中止微服務的情況下進行錯誤處理。這可以透過 Node.js 的 process.on("uncaughtException",...) 事件來實作。當捕捉到未捕捉的異常時，程式不會終止，而是繼續執行，並將錯誤記錄下來。

process.on("uncaughtException", err => {
  console.error("Uncaught exception:");
  console.error(err && err.stack || err);
});

這種方法允許微服務在出現錯誤後繼續執行，但也需要謹慎處理，以避免錯誤導致服務進入不穩定的狀態。

改進的中止和重啟策略

結合了繼續操作策略的優點，我們可以實作一個改進的中止和重啟策略。當出現未捕捉的異常時，程式不僅記錄錯誤，還會主動終止並離開，從而觸發 Kubernetes 的自動重啟機制。

process.on("uncaughtException", err => {
  console.error("Uncaught exception:");
  console.error(err && err.stack || err);
  process.exit(1);
});

這種方法既保證了服務的可靠性，也確保了錯誤能夠被正確地記錄和報告。

錯誤處理策略選擇

在設計微服務架構時，錯誤處理是一個至關重要的方面。當發生意外錯誤時，我們需要決定是否應該重啟微服務或讓它繼續執行。這個決策取決於微服務的特點和業務需求。

重啟策略

重啟策略是指當微服務發生錯誤時，直接終止它並重新啟動。這種策略在大多數情況下是可行的，因為它可以確保微服務不會在錯誤狀態下繼續執行，從而導致更嚴重的問題。透過重啟微服務，我們可以監控錯誤並及時發現問題，以便進行修復。

繼續執行策略

然而，在某些情況下，繼續執行策略可能更合適。例如，處理使用者資料的微服務可能需要在錯誤發生後繼續執行，以避免資料丟失或損壞。在這種情況下，繼續執行策略可以確保微服務不會因為錯誤而停止，從而影響使用者經驗。

logging 與 Docker Compose

在開發過程中，logging 是一個重要的工具，可以幫助我們瞭解微服務的執行狀態。Docker Compose 提供了一個方便的方式來檢視所有微服務的 logging 資訊。透過 Docker Compose，我們可以在一個單一的流中檢視所有微服務的 logging 資訊，這對於開發和除錯非常有用。

Mermaid 圖表
  flowchart TD
    A[錯誤發生] --> B[重啟策略]
    A --> C[繼續執行策略]
    B --> D[監控錯誤]
    C --> E[繼續執行]
    D --> F[修復錯誤]
    E --> G[避免資料丟失]

圖表翻譯

此圖表展示了錯誤處理策略的流程。當錯誤發生時，我們可以選擇重啟策略或繼續執行策略。重啟策略可以監控錯誤並及時發現問題，以便進行修復。繼續執行策略可以避免資料丟失或損壞，但需要小心評估其風險。

11.2.4 基本日誌記錄與Kubernetes

當我們在開發環境下使用Docker Compose執行微服務時，我們可以輕易地看到應用程式的日誌記錄並瞭解程式碼中發生了什麼。但是，當我們將微服務佈署到生產環境的Kubernetes叢集時，檢視日誌記錄就變得稍微複雜了一些。

日誌記錄重定向到檔案

有一個很有用的技巧是當我們執行Docker Compose時，可以將輸出重定向到一個檔案中。這樣，我們既可以在終端機中看到輸出，也可以儲存到一個檔案中以便於後續分析。

docker-compose up --build 2>&1 | tee debug.log

這個命令使用tee來同時顯示輸出在終端機中並儲存到debug.log檔案中。

使用Kubernetes的kubectl取得日誌

要從Kubernetes叢集中檢視特定微服務的日誌，我們需要使用kubectl命令。假設我們正在執行FlixTube應用程式，並且想要檢視metadata微服務的日誌。

首先，我們需要找到Kubernetes為該微服務例項分配的唯一名稱，即Pod的名稱。然後，我們可以使用kubectl get pods命令來檢視叢集中所有Pod的列表。

kubectl get pods

載入日誌檔案到Visual Studio Code

一旦我們獲得了日誌檔案，我們就可以使用Visual Studio Code（VS Code）來載入和瀏覽它。VS Code允許我們搜尋特定的文字串，例如，如果我們正在嘗試找出與資料函式庫相關的問題，我們可能會搜尋包含“database”字串的日誌記錄。

此外，我們還可以在日誌記錄中增加特殊的程式碼（字元序列）來區分不同的子系統或微服務的日誌記錄，這使得搜尋或過濾我們感興趣的日誌記錄變得更容易。

圖表翻譯：

  graph LR
    A[應用程式] -->|輸出|> B[終端機]
    B -->|重定向|> C[檔案]
    C -->|載入|> D[VS Code]
    D -->|搜尋|> E[日誌記錄]

這個圖表展示瞭如何從應用程式輸出重定向到檔案中，然後載入到VS Code中進行搜尋和分析。

監控和管理微服務

在 Kubernetes 中，監控和管理微服務是一個非常重要的任務。其中，檢視微服務的日誌是一個關鍵步驟。為了完成這個任務，我們可以使用 kubectl logs 命令來檢視指定微服務的日誌。

首先，我們需要找到微服務的 Pod 名稱。可以使用 kubectl get pods 命令來列出所有正在執行的 Pod。然後，根據輸出的列表，找到我們要檢視的微服務的 Pod 名稱。例如，如果我們要檢視 metadata 微服務的日誌，首先需要找到 metadata 微服務的 Pod 名稱。

kubectl get pods

輸出結果如下：

NAME READY STATUS RESTARTS AGE
azure-storage-57bd889b85-sf985 1/1 Running 0 33m
database-7d565d7488-2v7ks 1/1 Running 0 33m
gateway-585cc67b67-9cxvh 1/1 Running 0 33m
history-dbf77b7d5-qw529 1/1 Running 0 33m
metadata-55bb6bdf58-7pjn2 1/1 Running 0 33m
rabbit-f4854787f-nt2ht 1/1 Running 0 33m
video-streaming-68bfcd94bc-wvp2v 1/1 Running 0 33m
video-upload-86957d9c47-vs9lz 1/1 Running 0 33m

找到 metadata 微服務的 Pod 名稱後，可以使用 kubectl logs 命令來檢視其日誌。

kubectl logs metadata-55bb6bdf58-7pjn2

然而，每次都需要輸入完整的 Pod 名稱可能會很麻煩。為了簡化這個過程，可以使用 Stern 工具。Stern 允許你使用部分名稱來查詢和檢視日誌。

stern metadata

這樣，Stern 就會匹配所有以 “metadata” 開頭的 Pod，並顯示其日誌。

內容解密：

在上面的例子中，我們使用 kubectl logs 命令來檢視指定微服務的日誌。然後，我們介紹瞭如何使用 Stern 工具來簡化這個過程。Stern 的優點在於它允許你使用部分名稱來查詢和檢視日誌，這使得監控和管理微服務變得更加方便。

圖表翻譯：

  graph LR
    A[使用 kubectl logs] --> B[指定 Pod 名稱]
    B --> C[檢視日誌]
    A --> D[使用 Stern]
    D --> E[指定部分名稱]
    E --> F[檢視日誌]

這個圖表顯示了使用 kubectl logs 和 Stern 的兩種不同的方法來檢視微服務的日誌。第一種方法需要指定完整的 Pod 名稱，而第二種方法可以使用部分名稱來查詢和檢視日誌。

監控和管理微服務

在微服務架構中，監控和管理是非常重要的。這是因為微服務之間的互動和依賴關係使得系統的複雜性增加，從而使得問題的診斷和解決更加困難。

從系統架構的整體性來看，微服務架構雖然提升了行動應用程式的可擴充套件性、可維護性和效能，但也帶來了監控和管理的複雜性。本文深入探討了微服務架構的設計、日誌記錄、錯誤處理、健康檢查以及遙測資料收集等關鍵導向，並以FlixTube的metadata微服務為例，闡述如何在Kubernetes環境中實踐這些技術。分析顯示，有效地結合日誌記錄、錯誤處理策略以及工具如Stern和kubectl，才能在複雜的微服務環境中快速定位並解決問題。然而，微服務的粒度越細，監控和管理的挑戰就越大，需要更全面的自動化監控和警示系統。玄貓認為，未來發展趨勢將更注重AIOps的應用，透過人工智慧和機器學習技術，自動化分析海量遙測資料，預測潛在問題並主動修復，從而簡化微服務的管理和維護，提升系統的穩定性和可靠性。對於追求高效能和高可靠性的行動應用程式而言，及早規劃和實施全面的微服務監控策略至關重要。

玄貓

玄貓

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