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

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

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

醫療領域的微服務系統架構

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

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

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

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

醫療領域的單體式系統架構

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

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

閱讀全文 »

關於微服務 (Microservices) 的定義

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

醫療領域的微服務界定

所以,微服務的定義是什麼呢?(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社群-軟體設計鮮思維 **

Microservices Use Case Model

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

系統功能與實現程序

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

Microservices Use Case Model

Microservices System Sequence Diagram

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

閱讀全文 »

關於 DDD (Domain Driven Development) 微服務的結構設計議題

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

最近在線上輔導了一位 技術職PM 結構設計的實現 (Realization)議題,他傳給我 DDD 的架構圖,覺得在「Domain Service」與「Domain Model」的責任界定上,觀念不是很清楚。

嗯,其實這所謂的 DDD (Domain Driven Development) 架構圖根本就是典型 3-tier (Presentation-Application Logic-Data Source) 分層結構呈現爲圓形的剝洋蔥層次而已,越是內層 (Domain Model) 越代表爲系統的核心。
DDD Onion Architecture Diagram

工程師從這張圖往往會認爲「Domain Model」是最重要的核心觀念。是這樣沒錯,但對以「需求爲導向」的專案開發性質,它卻反而沒那麼重要!況且結構設計的基礎功夫要很紮實,封裝-介面-多型 諸多「虛」的設計觀念確實能充分了解並能整合活用,沒有花上 5-10 年以上功夫,是不容易應用在現實的系統開發上的。相對於此,「Domain Service」對現實的專案開發可是更切實際,且結構設計上的觀念也會比較容易入手。

閱讀全文 »

Java SOA 基本觀、架構與實做 <4>

設定 SCA 以及 SDO 的開發環境

安裝步驟 Overview

    o 安裝 STP/SCA Tools
    ※ Prerequisition – 請確定已安裝 Eclipse Modeling Tool。
    安裝步驟:

  1. 打開 Eclipse Software Update,並選擇「Available Software」。
  2. 選擇 Ganymede Update Site > SOA Development > SCA Composite Tools Feature 1.0.0
  3. 鍵入 Install 按鍵
  4. 安裝 SCA 執行環境(使用Apache Tuscany):請至 http://tuscany.apache.org/sca-java-releases.html 下載最新版本的 Tuscany 以及其Source。
  5. 將Apache Tuscany解壓縮至適當路徑。
    o 安裝 SDO Runtime 以及 Eclipse Link
    安裝步驟:

  1. 設定 JAVA_HOME 環境變數以及 PATH。
  2. 下載 EclipseLink,並解壓縮。
  3. 設定 ECLIPSELINK_HOME 環境變數:
    ECLIPSELINK_HOME = <INSTALL_DIR>/eclipselink。
  4. 下載 EclipseLink for OSGi,並解壓縮至 ECLIPSELINK_HOME 目錄下。

閱讀全文 »

軟體思維顧問

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

Personal