微服務是一種架構。
架構的重要性在於影響了非功能性需求，例如：容錯性、擴展性、可用性…等
而非功能性需求決定了軟體的品質。
微服務架構根據作者(Chris Richardson)的定義：
把應用程序的功能性分解為一組服務的架構風格，且每一個服務都是由一組專注、內聚的功能職責組成。
個人理解：由多個專注各自職責功能(Domain) 的微小服務組合成一個應用程式的整體功能。
何謂一組服務
作者(Chris Richardson)給出了擴展服務的三個維度：
Ｘ：在多個實例之間實現請求的負載平衡
這組服務是由負載平衡器 + 多個相同實例組成
Ｙ：根據功能將應用程式拆分
這組服務是透過功能分解組成
Ｚ：根據請求的屬性路由
這組服務是由路由器 + 多個相同應用實例組成
結合
也可以由多個維度複合組成，如下：
可看出是先利用 Y 軸擴展方式依據功能切分出多個小服務，將一個應用程式分解成一組服務，再視需要借助 X 軸或 Z 軸方式進行擴展。
特性：
在微服務架構中，服務間是鬆耦合特性等於是封裝了服務內的實現細節並透過 API 進行溝通，且每個服務具有自己的資料庫，在開發時，可以專注當前服務的開發，不必與其他服務協調，運行時，彼此相互獨立，不會因為其他服務的例外情況造成 Blocking、Exception…之類的影響。
優勢
使大型複雜的應用程式可以 CI/CD
產品規模越大代表團隊越大，可能導致溝通成本過高使效率降低，但使用微服務架構時，代表著也可以將大團隊分解成小團隊，每個團隊有著明確的職責，並可以獨立完成開發、測試、部屬流水線，不需要頻繁的與其他團隊溝通協調，效率相對高於單一的大團隊，且能夠快速響應產品的需求。
每個服務相對較小，容易維護
服務小而負責的功能單一意味著能讓 RD 更容易理解程式碼的作用，且規模小啟動快速也有助於提高效率(測試、部屬…)，相比單體架構，跑完全部的測試和 StartUp 可能就需要耗費一些時間。
服務可以獨立擴展或部屬
微服務架構可以視每個服務需求實現相應的擴展，例如：某個服務負載比較吃重，就可以使用 X 軸擴展(Load Balance)，或是視需求部屬於不同的硬體環境，彈性更高於單體架構。
更容易採納新的技術
因為鬆耦合的特性，只要接口規格訂好，不必在乎內部細節如何實現，也就代表可以選擇更適合這個服務的語言與開發框架，彈性更高於單體架構。
更好的容錯性
可以實現更好的故障隔離，假設有沒設想到的例外情境導致服務當掉或其他意外時，相比單體架構，也不至於對整體應用程式造成影響。
但…軟體工程並沒有銀彈，微服務架構也有它的劣勢：
劣勢
- 微服務架構的拆分定義
沒有任何一個工具或算法能有助於進行拆分，所以如何拆分與定義對設計架構的人來說非常重要，不良的拆分可能造成的問題，像是變成分散式單體架構，也就是功能職責沒有切割好導致某個服務可能需要負責多個功能如同小型的單體架構，又或是沒設計好而造成大量服務間的耦合關係。
例如：必須先開好Ａ系統才能開Ｂ系統，造成維運人員需要寫一份冗長的 SOP，而這樣的
人工行為還會有不小心失誤開錯的風險要承受。
- 分散式系統帶來的複雜性
分散式系統帶來的門檻相較單體架構可能高個好幾個層次，像是使用快取就要注意
快取同步的問題，或是未知原因造成分散式 NoSQL資料庫延遲嚴重，但仍舊是可用的，可能就需要設計熔斷機制，把向快取抓資料的這個行為 skip 掉…等等，但正式的大型產品肯定不會那麼單純。
- 部屬多個服務時需要更謹慎的協調各個團隊
很少有架構能夠被
徹底的遵循實現，還是要依據現實情境考量，可能免不了會有耦合的情況，這時候必須協調各個開發團隊，制定一個部屬計畫，讓服務能夠按照著依賴關係進行排序。
參考
《微服務架構設計模式》- Chris Richardson
