微服務

不知自己不知道, 那你會以為你知道.

tags: `微服務` `container` `202204`

此篇前言

什麼是微服務?

能獨立自主運作、改寫、升級
擁有自己的狀態
微服務之間，必須透過定義好的 API 溝通
單一服務故障時，系統仍保持一致性、可用性

為何要採用微服務?

微服務小巧並且專注做好每一件事

確保系統架構的擴充性，不會造成未來營運上的瓶頸。
提升資源的可用性，降低營運成本。(比如虛擬器的資源可更加的利用，AWS上還有對 container 做單獨的服務，讓你省去管理虛擬機的成本)
故障隔離: 單一服務故障，可以獨立退版，且不是直讓系統掛掉。
各個服務，可由不同的小團隊去開發與維運。
各服務可用各自的技術與框架下去開發，不受限於技術或框架的限制。

如何將系統改用微服務的步驟?

NOTE:

首先要有個很大的單體程式，並檢查單體程式目前的程式碼模組化的程度。若程式寫得不好，建議不要直接改成微服務。
檢視現有的系統，定義服務的邊界，分割為數個獨立運作的服務。
- 電商網站通常有這些功能訂單功能、商品功能、庫存功能、客戶服務、商家服務、統計服務、物流服務
  - 簡單上可這樣劃分(不是絕對)
    - 商品-微服務
      - 購物車功能、商品功能、庫存功能
    - 客戶-微服務
      - 客戶服務(個人化設定 …)、商家服務(個人化設定 …)
    - 訂單-微服務
      - 訂單管理、購買、物流服務
    - 統計-微服務
      - 瀏覽商品紀錄、客戶來訪紀錄、購買總金額、售出總金額

切割: 找出系統的邊界，可以獨立切割成微服務的區塊。
介面: 定義 API, protocol
架構安全: 服務之間的安全機制，比如授權TOKEN、Json + 數位簽章(AES)
框架: 決定服務要採用的開發技術、框架、執行環境
重構: 用重構 +單元測試，逐步改善原本的系統架構、切出變成微服務。
測試: 部屬容易，可局部更新。所以更可以使用真實環境來測試，但退版機制得先訂出來。
追蹤: 規劃統一的 LOG 機制，解決跨服務的問題排除。
監控: 服務運作狀況，服務效能表現，服務失敗處理原則。
壓測: 了解單一服務效能瓶頸，與運作規模的上限。