這篇要來說，微服務，這名詞跟容器Container，很常會一起提到，是因為他們彼此是相互輔助的，由於容器化所以服務都顯得輕量，也由於微服務所以將應用都容器化，這樣的組合會是相較流暢的搭配，接著就來針對微服務Microservice來說明有些人認為，包含我，微服務只是顆粒更小的SOA，其實這點也沒有錯，在架構上沒什麼差異，核心概念還是建立模組化與可替用元件，只是有別於過去單體式架構，微服務架構更加倡導：
| 特色 | 優點 | 缺點 |
|---|---|---|
| 分散式系統結構，鬆散耦合 | 服務單一責任 | 複雜性較高 |
| 服務可獨立開發 | 服務單純單一化 | 跨團隊的溝通成本較高 |
| 服務須獨立且容易部署 | 不會因為升級或調整而影響其他 | |
| 容器化 | 較為輕量且獨立，擴充方便 | 服務都很微小 |
| 服務之間以API方式溝通 | 內部實作邏輯有隱密性與獨立性 | API溝通時可能會有網路壅塞或延遲 |
| 每個服務都能有自己的資料庫 | 獨立性較高 | 若有共同資料一致性的設計不容易 |
圖片來源：走入軟體架構演進史 見證微服務發展今昔
而微服務概念的其中一位提出者，Martin Fowler，建議要導入微服務有三件事
1. 高度自動化，具備快速建置的能力
2. 應用程式監控機制，因分散鬆散的結構，不容易發現問題，必須有監控項目包含出錯次數與服務可用性
3. 快速部署，呼應第一點且無論測試、正式，都要能快速部署，未來設法全部自動化
在現在高度往雲服務、容器化、敏捷開發的導向下，我相信微服務也會有一塊市場發展，雖然其門檻與條件相較的高，但是對架構師而言很好很有趣的挑戰
參考資料、延伸閱讀：
下集預告：相關分享 - ELK Stack
iThome鐵人賽
看影片追技術