iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 28
0

這篇要來說,微服務,這名詞跟容器Container,很常會一起提到,是因為他們彼此是相互輔助的,由於容器化所以服務都顯得輕量,也由於微服務所以將應用都容器化,這樣的組合會是相較流暢的搭配,接著就來針對微服務Microservice來說明有些人認為,包含我,微服務只是顆粒更小的SOA,其實這點也沒有錯,在架構上沒什麼差異,核心概念還是建立模組化與可替用元件,只是有別於過去單體式架構,微服務架構更加倡導:

  • 以業務內容切割服務
  • 將每個服務模組化,每個模組內的功能少量化,將模組多量化
特色 優點 缺點
分散式系統結構,鬆散耦合 服務單一責任 複雜性較高
服務可獨立開發 服務單純單一化 跨團隊的溝通成本較高
服務須獨立且容易部署 不會因為升級或調整而影響其他
容器化 較為輕量且獨立,擴充方便 服務都很微小
服務之間以API方式溝通 內部實作邏輯有隱密性與獨立性 API溝通時可能會有網路壅塞或延遲
每個服務都能有自己的資料庫 獨立性較高 若有共同資料一致性的設計不容易

https://ithelp.ithome.com.tw/upload/images/20191014/20111916U816Exh8dd.png
圖片來源:走入軟體架構演進史 見證微服務發展今昔

而微服務概念的其中一位提出者,Martin Fowler,建議要導入微服務有三件事
1. 高度自動化,具備快速建置的能力
2. 應用程式監控機制,因分散鬆散的結構,不容易發現問題,必須有監控項目包含出錯次數與服務可用性
3. 快速部署,呼應第一點且無論測試、正式,都要能快速部署,未來設法全部自動化

在現在高度往雲服務、容器化、敏捷開發的導向下,我相信微服務也會有一塊市場發展,雖然其門檻與條件相較的高,但是對架構師而言很好很有趣的挑戰

參考資料、延伸閱讀:

下集預告:相關分享 - ELK Stack


上一篇
相關分享 - K8s
下一篇
相關分享 - ELK Stack
系列文
後端功城獅30天DevOps探討挑戰30

尚未有邦友留言

立即登入留言