微服務淺談
==========================
###### tags: `MicroService`

"微"服務這幾年超級夯!!!
工作中有些筆記跟服務使用上的經驗做些分享. 也藉此複習.

# 微服務架構興起的原因
為了解決單體架構的一些不足.

單體架構(Monolithic)下，各業務系統之間是緊密耦合的，各個模組都是運行在同一個程序裡,
每次上版就要重啟整個程序.
也因此，在模組數量增長時，造成服務啟動變久，佈署時間拉長，更提升風險
所以很多公司選擇安排一段時間停止服務進行維護做上版佈署
又因為雞蛋放在同一個籃子裡，一個項目出錯，整個網站就面臨無法提供服務的狀態(就像下圖Something went wrong、Oops，500.)
雖然程序可以佈署多份，並透過反向代理(Reverse proxy)，或負載均衡做動態調整。但這種架構下，不同業務訪問同一份資料庫，有些資源可能佔用大量資料庫CPU time或記憶體，此時，進行模組擴充會有相當大的困難度

[Pattern: Monolithic Architecture](https://microservices.io/patterns/monolithic.html)

所以就慢慢的出現一些架構，SOA、RPC、分散式架構，直到這裡說的微服務架構.

# "微服務"架構
[Pattern: Microservice Architecture](https://microservices.io/patterns/microservices.html)

先講解什麼是微服務
## 微服務
微服務(Microserivce)，為什麼不叫Mini-service?
微服務宗旨就是一個"**K.I.S.S**"原則- Keep It Simple And Stupid; 白話來說就是一個程序只做一件事情.

以此衍生出幾個"微"服務的設計原則(Design Principle)
1. 高內聚， 低耦合
2. 高度自治
3. 圍繞在業務能力進行規劃
4. 彈性設計
5. 日誌與監控
6. 全面自動化

### 高內聚， 低耦合
每個服務針對一個單一職責([SRP](https://en.wikipedia.org/wiki/Single-responsibility_principle))的業務能力做封裝. (這太玄學)
這件事情的定義非常的模糊，因此更多時候，會需要Domain Expert(領域專家)，從業務上的角度做職責切分，或根據[Subdomain](https://ithelp.ithome.com.tw/articles/10216798)做劃分.
自然會達成高內聚(因為都在只面對同一類的業務)

低耦合，因為服務之間彼此不在同一個程序裡，僅透過一些通訊協定與接口做溝通，使得程序之間相對獨立，服務自然就處於低耦合的狀態了.
同時消除了隱式的數據依賴，僅存在服務之間彼此溝通傳遞資料.

### 高度自治
1. 服務能獨立佈署和擴展，每個服務都各自運行在獨立的程序內，這賦予了靈活的佈署方式，使得快速迭代交付有可能實現.
2. 獨立開發與各自系統演化，技術選型靈活化，不再受到技術債的迫害.
可依業務自己選擇適合的技術來開發，獨立演化. 服務之間僅透過網路協議與接口相互溝通.
3. 獨立的團隊與自治，團隊就能對服務的整個生命週期負責，僅需關心負責的[邊界上下文(Bounded Contexts)](https://ithelp.ithome.com.tw/articles/10218252)

### 圍繞在業務能力進行規劃
每個服務代表特定業務邏輯，而明顯定義的Bounded Contexts. 就能快速圍繞在業務進而組織團隊. 而明顯的Bounded Contexts可以隔離實做上的細節([ISP](https://medium.com/@f40507777/%E4%BB%8B%E9%9D%A2%E9%9A%94%E9%9B%A2%E5%8E%9F%E5%89%87-interface-segregation-principle-isp-6854c5b3b42c))，就能抽象出業務邏輯，建立業務模型，使模型能重複被使用.

### 彈性設計
容錯，服務降等，限流，[熔斷器](https://microservices.io/patterns/reliability/circuit-breaker.html)，服務限流，防止雪崩等等的機制.

目標是作到服務可以滿足以下特性:
Availability(可用性)，Reliability(可靠性)，Controllability(可控制性)，Observability(可觀察性).

### 日誌與監控
為了達成Observability(可觀察性)，方便對產線環境進行快速的問題定位，檢測出可能發生的異常或是故障.
監控包含可用狀態，請求流量，錯誤計數，鍊路調用追蹤等等的.
以結構化的日誌與界面做展示.

### 全面自動化
因為不再像傳統的單體架構就少量的程序需要佈署，要是依賴手動部署，很可能出錯且部署很慢.
所以會需要一些非手動的方式來提昇效率和降低成本.
利用自動化的運維服務來協助.

# 遺留的系統與服務怎辦? 能否慢慢轉成微服務?
## 扼制模式[Strangler application](https://microservices.io/patterns/refactoring/strangler-application.html)
重作???
賣鬧阿，風險太大，老闆也不想看到資源拿去重作，且前人的智慧，一時半刻間是無法領悟的.
應該像上圖，這樣逐步重構，時間久了，單體程序所涵蓋的功能與業務會越來越少.
很多人都想"一步到位"，但是在到位之前，是沒任何好處與價值的.
快速能交付，才是我們希望的.

因此有幾種策略:
1. 新的功能與業務，乾脆將之以服務的方式來開發(避免繼續疊床架屋)
2. 透過interface或抽象，隔離表達層與實做層
3. 把單體內的功能模組，提取到新的服務中，強行拆解單體.

## [Anti-corruption layer](https://microservices.io/patterns/refactoring/anti-corruption-layer.html)
Anti-corruption layer防腐層，又稱為膠水代碼(Glue Code).
用來保護全新定義出來的領域模型，不受到單體模型的污染; 替這兩個模型之間進行翻譯轉換.
使得新的服務，能夠透過Glue code去調用單體服務的所有資料與功能.
Glue code在設計模型內能透過[Adapter Pattern](https://en.wikipedia.org/wiki/Adapter_pattern)來實做.