# 微服務 (Microservices)
現今軟體的複雜度越來越高，越大型的軟體維護的成本是呈指數型上升的，因此若是能拆成多個獨立的小服務，那維護的成本就只會是線性的。

微服務架構是一種開發應用程式的方法，將單一應用程式(單體系統 Monolitch)劃分成多個小型服務，每個服務獨立執行單一功能，並利用 API 將彼此串聯起來。

<!-- more -->


各服務功能都是以企業業務邏輯為基礎發展、開發，必須具備自動化、獨立部署的特性。

因此微服務具有獨立部署、開發彈性大、可以混用多種開發工具、資料隔離、錯誤隔離等等的優點。

然而分散式系統會造成複雜度提升，也導致了以下幾個問題 :
1. 遠端呼叫慢而且存在失敗的風險
2. 系統更新有許多來源，必須謹慎處理系統一致性的問題
3. 若沒有導入 CI、CD 的自動化建置和部署以及系統監控，則會很難去管理和維護這麼多的微服務

## 導入方式
新系統可以直接導入不受限於舊有程式的影響，但是舊系統建議以現有系統上疊加微服務，適應一段時間後再將核心任務改用微服務提供，一次到位很容易造成失敗。

若要導入則需具備以下條件 :
* 高度自動化
應用程式必須具備快速建置及快速部署的能力
* 監控機制
微服務是靠著許多鬆散耦合的服務組成，系統運作時必會故障且不容易發現問題，基本必須監控系統出錯的次數及服務可用性

## API v.s 套件
以 API 的形式取代套件可以免去版號升級不相容的問題，而 API 的版本只在於顯示的 Json 格式不同，內部運算邏輯仍相同。

然而每次呼叫 API 需要撰寫較多程式，所以可以利用套件將呼叫 API 的部分包起來，而套件的更新版本就是在 API 有新增版本的時候才更新，也就是套件更新只是支援 API 的其他版本

## 參考
[1][導入微服務前一定要知道的事](https://www.ithome.com.tw/news/116053)
[2][微服務架構樣式](https://docs.microsoft.com/zh-tw/azure/architecture/guide/architecture-styles/microservices)

###### tags: `WebAPI` `微服務`