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

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

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

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

系統功能與實現程序

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

Microservices Use Case Model

Microservices System Sequence Diagram

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

系統部署

利用 UML 系統部署 (Deployment) 圖表達了「Web Portal」、「API Gateway」、「Product & 購物車 Microservices」之間的系統連結。

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

  • 系統之間的連結是透過 REST API,這是比較通用,但不是絕對只能採用該通訊協定。
  • 「API Gateway」擔任類似 Router 的轉址,係屬於底層系統伺服器 (server)層級,一般並非是由 Application Developer 開發,而是可以採用商用/開源的產品。

微服務內部的分層結構

利用 UML 套件 (package) 圖規劃了每一個微服務內部的分層結構。網路上文章大都採以垂直 Layer 的方式來表達分層,個人仍是偏好採用老派 (old-school) 的水平 Tier 分層方式,來表達出「展示 (Presentation)層」、「應用邏輯 (Application Logic)層」、「資料存取 (Data Access) 層」與「資料來源 (Data Source)層」。

Microservices Use Case Model

  • Web API 係屬於展示層 (一般是透過 Controller 的實作),負責接收 REST Client 的 Request,傳進的參數爲 JSON 資料結構。
  • 微服務內部各層物件之間的連結,可以直接傳遞 JSON 當爲參數與回傳值,或者也可以在展示層就轉換 (transform)爲 資料傳遞物件 (DTO, Data Transfer Object),兩者格式的互轉是很容易的,一般都有現成的工具物件可以直接使用。
  • 資料存取層的存取物件在微服務的術語稱爲「Repository (儲庫)」,從名字就可以得知它是多個 Service 物件功用存取的。一般在大型 (Monolithic)系統的 DAO (Data Access Object) 物件最好不要設計爲共用,會非常的龐大擁腫;但由於微服務係由 Bounded Context 或功能模組界定了領域邊界 (domain boundary),範圍已侷限,所以「Repository」的設計考量是可以共用的。

文章導覽

   

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。