{%hackmd DfWYF9cYREebVNN1eEOz-w %} 微服務 ====== > ***不知自己不知道, 那你會以為你知道.*** ###### tags: `微服務` `container` `202204` 此篇前言 ------ ### 什麼是微服務? - 能獨立自主 運作、改寫、升級 - 擁有自己的狀態 - 微服務之間，必須透過定義好的 API 溝通 - 單一服務故障時，系統仍保持一致性、可用性 ### 為何要採用微服務? **微服務小巧並且專注做好每一件事** - 確保系統架構的擴充性，不會造成未來營運上的瓶頸。 - 提升資源的可用性，降低營運成本。(比如虛擬器的資源可更加的利用，AWS上還有對 container 做單獨的服務，讓你省去管理虛擬機的成本) - 故障隔離: 單一服務故障，可以獨立退版，且不是直讓系統掛掉。 - 各個服務，可由不同的小團隊去開發與維運。 - 各服務可用各自的技術與框架下去開發，不受限於技術或框架的限制。 ### 如何將系統改用微服務的步驟? :::info NOTE: - 首先要有個很大的單體程式，並檢查單體程式目前的程式碼模組化的程度。若程式寫得不好，建議不要直接改成微服務。 - 檢視現有的系統，定義**服務的邊界**，分割為數個獨立運作的服務。 - 電商網站通常有這些功能 訂單功能、商品功能、庫存功能、客戶服務、商家服務、統計服務、物流服務 - **簡單上可這樣劃分(不是絕對)** - **商品-微服務** - 購物車功能、商品功能、庫存功能 - **客戶-微服務** - 客戶服務(個人化設定 ...)、商家服務(個人化設定 ...) - **訂單-微服務** - 訂單管理、購買、物流服務 - **統計-微服務** - 瀏覽商品紀錄、客戶來訪紀錄、購買總金額、售出總金額 ::: - 切割: 找出系統的邊界，可以獨立切割成微服務的區塊。 - 介面: 定義 API, protocol - 架構安全: 服務之間的安全機制，比如 授權TOKEN、Json + 數位簽章(AES) - 框架: 決定服務要採用的開發技術、框架、執行環境 - 重構: 用重構 +單元測試，逐步改善原本的系統架構、切出變成微服務。 - 測試: 部屬容易，可局部更新。所以更可以使用真實環境來測試，但退版機制得先訂出來。 - 追蹤: 規劃統一的 LOG 機制，解決跨服務的問題排除。 - 監控: 服務運作狀況，服務效能表現，服務失敗處理原則。 - 壓測: 了解單一服務效能瓶頸，與運作規模的上限。