From Monolith to Microservices
Monolith:
- 在微服務(Microservices)之前的架構標準是單體式(Monolith)
- 所有的元件都集中在單一個單元上
- 舉例有個線上購物系統,裡面有以下的程式服務
- 1.使用者驗證
- 2.購物車
- 3.正式的相關LOG
- 4.購物明細
- 5.通知
- 以上這些全部都收歸集中在單一個單元裡
- 並且使用相同語言開發
- 所有一切的開發,佈署與擴展都是以這一個單位進行
- 也就是裡面強制限定只能單一個技術棧
- 然後每個團隊在裡面負責不同服務(驗證,通知...如上)都必須小心不會影響到其他團隊的Code
- 即便只是一個團隊修改了其中一個服務程式(假設只是改個通知)
- 但是整個單元全部都要重新佈署才能生效
Monolith導致的問題:
- 應用程式大太且太過複雜
- 服務元件間互相糾結
- 無法針對特定服務(ex:使用者驗證)做單一擴展,而必須只能整個單元進行擴展
- i.e.擴展會造成額外不必要的基礎設施花費!
- 各元件依賴的library可能會有版本互斥的問題,但是無解!只能取其一
- Release時間拉長,因為改個小地方,其他全部可能都要重測
- 任何module的bug都可能導致整體應用掛掉
以上問題都能透過改成微服務(Microservices)架構來解決
微服務(Microservices):
- 也就是把應用程式拆解為比較小且獨立的應用程式
- 但是延伸許多問題:
- 1如何拆解原本的應用程式為微服務應用程式?
- 2.程式碼都該放哪去?
- 3.多少服務該建立?
- 4.這些微服務該多大或是多小?
- 5.甚至這些拆解後的微服務如何互相溝通?
微服務(Microservices)好處:
- BP上來說依據業務邏輯來做拆分
- 例如購物系統可能拆解為(User帳號系統,產品系統,購物車系統,明細系統...etc)
- 盡量讓一個服務只為特定一件工作
- 並且服務都各自管控,佈署,擴展
- i.e.完全的低耦合(loosely coupled)
- 例如只是重新佈署payment服務,就只要佈署好它就好,不用管其他服務
- 每個服務就能有各自的版本編號,而不用遷就其他服務
微服務(Microservices)間的溝通:
- 大部分仰賴API的呼叫方式(如payment呼叫user服務等等)
- 並且各個服務就能有各自的技術棧(服務系統有的可以是Java,有的是GO,有的是py等等)也不會影響其他團隊或其他微服務系統運作
微服務(Microservices)造成的問題:
- 拆解為微服務系統即變成複雜的分散式系統
- 要設置服務間的溝通,尤其A服務呼叫B服務,但是B掛掉的時候如何處理
- 微服務橫跨許多Server的佈署,一大堆instance,難以監控!
但是現在也越來越多工具在解決上述相關的微服務延伸問題!
