微服務架構 – 以醫療領域為例

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

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

微服務架構 – 以醫療領域為例

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

爲何會使用微服務架構?!

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

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

爲何會使用微服務架構?!

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

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

閱讀全文 »

關於微服務 (Microservices) 的定義

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

關於微服務 (Microservices) 的定義

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

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

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

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

使用 UML 圖表達微服務 (Microservices)的架構設計

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

使用 UML 圖表達微服務 (Microservices)的架構設計

這裏藉由一個「放入購物車」的極小型功能案例,並利用 UML 各面向的設計圖,來表達微服務 (Microservices) 的架構規劃與設計的呈現樣貌。下列是幾個主要設計面向的設計圖 (並非是全部) 可以參考。

系統功能與實現程序

利用 UML 使用案例模型 (use case model) 與系統循序 (sequence) 圖表達「放入購物車」的系統功能與主要實現程序。

Microservices Use Case Model

Microservices System Sequence Diagram

  • 從需求模型可以看出共有兩個微服務:「Product Microservice」與「購物車 Microservice」。
  • 每一個微服務均各有資料庫,圖中可看出共有兩個。資料庫是私有倉儲,不能跨微服務直接存取 (即使位於同一區域都不行),只能透過 API 呼叫。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal