---
# System prepended metadata

title: 微服務
tags: [container, 微服務, '202204']

---

{%hackmd DfWYF9cYREebVNN1eEOz-w %}

微服務
======  

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

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

此篇前言  
------

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

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

### 如何將系統改用微服務的步驟?
:::info
NOTE:
- 首先要有個很大的單體程式，並檢查單體程式目前的程式碼模組化的程度。若程式寫得不好，建議不要直接改成微服務。
- 檢視現有的系統，定義**服務的邊界**，分割為數個獨立運作的服務。
    - 電商網站通常有這些功能 訂單功能、商品功能、庫存功能、客戶服務、商家服務、統計服務、物流服務
        - **簡單上可這樣劃分(不是絕對)**
            - **商品-微服務**
                - 購物車功能、商品功能、庫存功能
            - **客戶-微服務**
                - 客戶服務(個人化設定 ...)、商家服務(個人化設定 ...)
            - **訂單-微服務**
                - 訂單管理、購買、物流服務
            - **統計-微服務**
                - 瀏覽商品紀錄、客戶來訪紀錄、購買總金額、售出總金額
:::
- 切割: 找出系統的邊界，可以獨立切割成微服務的區塊。
- 介面: 定義 API, protocol
- 架構安全: 服務之間的安全機制，比如 授權TOKEN、Json + 數位簽章(AES)
- 框架: 決定服務要採用的開發技術、框架、執行環境
- 重構: 用重構 +單元測試，逐步改善原本的系統架構、切出變成微服務。
- 測試: 部屬容易，可局部更新。所以更可以使用真實環境來測試，但退版機制得先訂出來。
- 追蹤: 規劃統一的 LOG 機制，解決跨服務的問題排除。
- 監控: 服務運作狀況，服務效能表現，服務失敗處理原則。
- 壓測: 了解單一服務效能瓶頸，與運作規模的上限。
