現今軟體的複雜度越來越高，越大型的軟體維護的成本是呈指數型上升的，因此若是能拆成多個獨立的小服務，那維護的成本就只會是線性的。
微服務架構是一種開發應用程式的方法，將單一應用程式(單體系統 Monolitch)劃分成多個小型服務，每個服務獨立執行單一功能，並利用 API 將彼此串聯起來。
各服務功能都是以企業業務邏輯為基礎發展、開發，必須具備自動化、獨立部署的特性。
因此微服務具有獨立部署、開發彈性大、可以混用多種開發工具、資料隔離、錯誤隔離等等的優點。
然而分散式系統會造成複雜度提升，也導致了以下幾個問題 :
- 遠端呼叫慢而且存在失敗的風險
- 系統更新有許多來源，必須謹慎處理系統一致性的問題
- 若沒有導入 CI、CD 的自動化建置和部署以及系統監控，則會很難去管理和維護這麼多的微服務
導入方式
新系統可以直接導入不受限於舊有程式的影響，但是舊系統建議以現有系統上疊加微服務，適應一段時間後再將核心任務改用微服務提供，一次到位很容易造成失敗。
若要導入則需具備以下條件 :
- 高度自動化
應用程式必須具備快速建置及快速部署的能力 - 監控機制
微服務是靠著許多鬆散耦合的服務組成，系統運作時必會故障且不容易發現問題，基本必須監控系統出錯的次數及服務可用性
API v.s 套件
以 API 的形式取代套件可以免去版號升級不相容的問題，而 API 的版本只在於顯示的 Json 格式不同，內部運算邏輯仍相同。
然而每次呼叫 API 需要撰寫較多程式，所以可以利用套件將呼叫 API 的部分包起來，而套件的更新版本就是在 API 有新增版本的時候才更新，也就是套件更新只是支援 API 的其他版本
參考
[1]導入微服務前一定要知道的事
[2]微服務架構樣式