＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊

單體式的挫折，導致微服務的架構風格 – 將應用程序建構爲多個微服務

• 每一個微服務均視爲是一個小型的系統。
• 微服務各自擁有自己的私有倉儲 (資料庫)。
• 微服務之間的互動是透過 API 的介接。
• 每一個微服務是獨立的個體，所以可以爲各自的微服務採用不同的實作技術與系統的建置、部署及維護方式。

＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊

要談及微服務，就需要回頭檢視典型單體 (Monolithic) 式的系統建構與開發方式。下圖可能是一個醫療領域的單體式系統架構。

這個「Monolithic」可以翻譯爲「單體」或「整體」，也就是我們一般典型的大堆頭式的開發系統，它有以下特點：

• 應用程序被建構爲單個單元 (single unit)。
• 多個功能模組共用同一個資料庫。
• 使用同一種技術框架 (ex. .NET or Java/Spring Framework) 實作。
• 對系統的任何變更都涉及建構與部署伺服端應用程序的新版本。
• 伺服器系統的延展性主要採以運行多個複製實例 (clone instance) 以達成負載平衡的需求。

閱讀全文 »

＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊

所以，微服務的定義是什麼呢？(What is Microservices)

它其實是一種架構設計的風格 (architecture design style) ，並沒有一種很絕對嚴謹的定義，要說較通用的說明，可以參考如下：
「用以描述將系統依據業務能力 (business capability) 分解為多個可獨立 (independent) 被建構 (built)、部署 (deployed) 與延展 (scaled) 的服務 (services)。」

微服務的表現 (represent) 可以參考如圖所繪製的醫療業務領域 (health care business domain)，這是可以建構微服務系統的最佳應用。

• 將單個應用程序開發爲一組小服務。
• 每組小服務均有自己的進程 (Process)。
• 每組小服務各自建構、部署與維護。
• 每組小服務可透過輕量化的溝通機制，例如 HTTP based 的 API，與其它小服務互動。
• 這些小服務有最低限度的集中管理，它們可以使用不同的程序語言，並使用不同的資料儲存技術。