# 微服務了沒 - 陳鋒逸 (陳小風)

{%hackmd j86FNbMoRoeN4Xn0pg5ofw %}

> 請從這裡開始

## 網站架構演進

### 三層式架構
* 分工明確
* 抽象化

Presentatio/Business/Data Access Layer

### SOA (software oriented architecture)

* 物理隔離
* 介面溝通

某些服務較多人使用，ex: 查詢系統
成為共同元件

以 domain 為主的網站為基礎

### 微服務

* 顆粒更細
* 靈活度佳

有自動延展、HA、高流量的需求

將整個網站 break down 成不同的 microservice

組裝服務及 reverse proxy 組合元件

快速排列做和成新的頁面

可以從現有的網站挑出某些模組，組裝成新的服務提供給使用者

本質是類似的

### Monolithic

* 單一應用程式
* 功能集中


可想像成巨大金字塔
* All in one
* 容易理解
* 集點集中
* 了解整體

問題：
* 耦合性高
* 重構困難
* 邏輯複雜
* 不易延展
* 資源利用率低
* 只能對整個網站做延展

惡夢性的問題
* 網站套件過時、還有安全性問題 -> 做 package update -> 出現很多 error, 導致網站 build 不起來 -> 因為套件被核心程式碼用到，所以要將整個網站測過一輪 (不可能)
* 小小的異動就會影響整個網站

### Micro services

#### 優點

* 許多應用程式 (小型網站)
* 可以重複運用元件，提供更多功能

* 資源運用
* 輕鬆的針對 bottleneck scale up
* 對整體沒有影響的 service 更新或測試
* 耦合性低
* 容易重構
* 功能比整個網站小、容易更改
* 甚至可以將整個服務重寫，migrate 到新的程式碼
* 彈性組合
* 透過現有服務排列組合
* 邏輯單純
* 一個服務 focus 在一個 domain 或一個流程，比較容易上手、修改服務
* 容易延展
* 較有彈性
* 用 docker base ，容易做 scaling

#### 缺點

* 不易開發
* 如果沒有用容器化/自動化技術，要開始開發、找 bug，需要花很多時間將服務 setup
* 缺乏單元測試的情境下，會不容易找出錯誤點
* 花費時間
* 架構複雜
* 功能分得越細，相對架構複雜
* 開發團隊要 sync 才能知道整個網站怎麼溝通，可能導致多個團隊開發多個類似的重複功能
* 邏輯重複
* 解決方式：package、團隊溝通
* IO 變高
* 如果要串很多服務（又用 https 連結服務）才能完成一個 http request，可能會導致 latency 變高
* 解決方式：分散流量、平行處理
* 安全性
* 如果服務的網段可以被外部存取，可能會造成外部直接呼叫微服務導致資料洩漏
* 解決方式：授權機制(token,apigateway...)

#### 改善方法

* 不易開發
* docker
* K8s
* 花費時間
* 自動化
* 持續改善
* 架構複雜
* 關注點分離
* 定義邊界
* 邏輯重複
* Package
* 團隊溝通
* 基礎建設
* IO 變高
* 優化瓶頸
* 分散流量
* 平行處理
* 安全性
* 授權機制
* api gateway

> 最終目的：**提供客戶穩定的服務**

# Monolithic 架構
* 只需要針對一整個網站做整體整合測試，就可以確保服務正確性

# 微服務架構
一開始導入微服務會發生的事：
* 將每個模組拆開成一個服務，但是部署、測試、監控都是手動做
* 可能要花 N 倍時間
* 碎片化
* context switch
* 遺漏事項

> 需要先導入基礎建設，像是自動化的部署、測試、監控
可以考慮用工具
* kubernetes
* jenkins
* prometheus

# 可能影響到選擇monolithtic or microservice的原因
* 團隊大小
* 產品性質(是否POC)
* 分散風險
* 資源運用
* 架構需求

# 走向微服務
* Code Level
* function call -> V1 calss
* function call -> factory -> V1 class
* 加入整合測試確保功能正常
* function call -> factory -> V2 class
* request -> load balancer/reverse proxy -> 產品

可以將一些需要 scale up 或是要分散風險的服務，先切成微服務

重點：
* 完整測試
* 解除依賴 (可以透過 load balaner/reverse proxy)
* 抽象化 (抽換元件)

# 微服務與團隊

* 從程式碼到架構
* 最早的微服務 - Linux
* `ls | head -3 | tail -1`
* 當 output 是 string, input 也是 string 就可以透過 pipe 去排列組合出不同的功能
* 共通觀念的延伸
* 找出想要導入微服務去解決問題的問題點
* 持續改善

* 演進式的改善方式
* 發現問題
* 解決計畫
* 改善產品
* 監控學習

# 總結
* 天下大勢，分久必合，合久必分
* 找出適合自己的架構
* 適應變化的能力
* 基礎建設最重要
* 自動化、單元測試、整合測試

###### tags: `MW18`