.NET + Windows Container, 微服務架構設計
主講：吳剛志
微服務架構
- 能獨立自主運作（獨立部署，升級，維護，改寫）
- 包含程式（code）的執行，與狀態（state）
- 為服務之間，必須透過定義好的介面溝通（API）
- 單一服務發生故障，系統仍能保持一致性與可用性（故障隔離）
為什麼要採用微服務
- 確保系統架構的擴充性，不會成會將來營運的瓶頸
- 提升資源的使用率，降低營運成本
- 故障隔離，單一服務失敗，不會讓整個系統掛掉
- 讓數個小團隊，個別負責服務的開發與維運
- 持續創新，每個服務可以允許使用不同的開發技術與框架
stackoverflow 也是採用微服務
如何將系統改為微服務架構的步驟?
檢視現有系統，定義服務的邊界，分割成數個獨立的服務
系統擴充的三個面相（依需求切割服務）
- 複製同樣的服務
- 垂直分割：功能導向，將不同功能進行切割
- 水平分割：將使用者導向不同的分流，例如不同區域，切不同的partition
透過基礎服務自動化工具，來管理及部署服務：Container
- Infrastructure as code：開發團隊越來越掌握主權
- 採用不可變的 server（immutable server 拋棄式 ）來部署服務：base image 鏡像
- 採用 container 來管理服務
使用容器技術（Container）
- Dock is a shipping container system for code
- 用統一規格封裝為服務，統一部署與管理（Infrastructure as code）
- Container image 被產生，統一放到儲存褲
- 部屬時可以直接使用
- 將 app 封裝成 Container image
- Container 被產生之後就不允許再修改，以部屬的服務若要異動，唯一的方式是重新 BUILD / SHIP / RUN
實際案例分享：如何『微服務化』人才發展管理系統?
先找出適合抽出來做微服務的部分
實作上的困難
- 維護困難：大型單體式 (Monolithic Apps) 開發、維護、更新、測試都很困難。
- 擴充困難：由於服務無法分割，只能整體進行擴充，複雜度高。
- 雲端化困難：難以朝向雲端化發展 (我們想將部分服務切割出來，改由原廠直接從雲端提供服務)。
- 佈署困難：Container 技術能解決佈署問題，但是 Docker 必須架構在 Linux 上，.NET Developer 難以直接使用。
改版開發步驟
- 切割：找出系統的邊界，挑出適合切割出獨立的微服務區塊
- 介面：定義 API , PROTOCOL, 對應的 SDK, 版本相容性與安全性原則
- 架構安全：服務之間的安全機制，採用授權 TOKEN, JSON + 數位簽章(AES)•
- 框架：決定服務要採用的開發技術、框架、執行環境
- 重構：用重構 + 單元測試，逐步改善原本的系統架構，切割出獨立服務
- 測試：佈署容易，可局部更新，可隨時使用真實的環境測試
- 追蹤：規劃統一的 LOG 機制，按操作序號追蹤，解決跨服務問題排除
- 監控：服務運作狀況，服務效能表現，服務失敗後的處理原則
- 壓測：了解單一服務效能瓶頸，與運作規模的上限
Windows Container
- 支援所有 Windows Application
- 安全相容 Docker API 的 Windows 版本 Container Engine
- 支援進階的 Hyper-V Container，可以做出更高階的隔離等級
參考資料
Session 錄影：Channel 9
