Monolithic

進入微服務之前 先來看看甚麼是monolithic

"A software system is called "MONOLITHIC" if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components."
From https://en.wikipedia.org/wiki/Monolithic_system

有些人看像是Docker，有些人看像是microservice，但它真的只是貨櫃

https://www.coscale.com/blog/comparing-microservices-and-monolithic-applications-from-the-perspective-of-monitoring

這個圖很好的比喻出了monolithic跟microservice在現實世界的對照(同時也可以暗喻一個大container對多個小container)，把所有功能(DB, UI, BL….)裝在一個大貨櫃(系統)裡, 那就是monolithic, 而盡量將有相關的功能封裝在小貨櫃裡就近似微服務, 要甚麼東西在大貨櫃裡都找的到, 在大貨櫃裡面會做貨物分類分區(分層架構)，而部署就類似要把貨櫃裝上船, 大貨櫃不好搬運, 需要的船也要大, 必須等到所有貨物(功能)都裝載完才能運送
, 上下貨(功能變更)則需要把整個大貨櫃運到岸邊打開

當monolithic系統持續擴大到一個限度後, 會開始會發現
• 編譯/部署/啟動時間過長,
• 各種服務之間依賴關係的複雜度迅速上升,
• 強健度的問題(整個系統可能會因為單一模組的問題而崩潰)
• 系統尺寸太大, 新進開發人員難以了解(說不定連老鳥都…)
對開發人員以及營運人員都會是場惡夢, 這是為什麼越來越多大型系統開始走向微服務

相較於大型monolithic, 微服務的特點在於:
* 服務的顆粒度小(同一小貨櫃只裝有關聯的物品), 內聚性高,
* 啟動快速
* 部署容易(運一個小貨櫃的總是比一個大的容易)
* 易於擴充兼具擴充彈性(可以只擴充需要的服務, 相較於monolithic則全部的服務打包擴充)
* 獨立性(通常擁有自己的DB)
* 系統強健度(單一服務功能故障基本上不會影響其他服務)
* 技術異質性，由於服務之間的低耦合度(藉由restful API或是Message queue互相溝通)和獨立性, 可以針對服務特性採用不同的技術/框架
ps: 通常只看單一服務本身仍是小型的monolithic

微服務依舊不是銀彈:

如果人月神話裡面所說的, 軟體開發沒有銀彈, 總是有 trade-off, 無服務本質上是分布式系統, 實踐上會遇到的挑戰會有:
• 如何切分服務/業務
• 現存的資料庫如何劃分
• 跨服務交易的取消及roll back，如何處理相關服務間資料一致性
• 服務之間的通訊, 同時從多個服務取得資料等
• 如何管理多個服務
• 服務出問題時的容錯設計
• Etc..