微服務的內部分層結構- 洋蔥 (Onion) 架構

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

微服務的內部分層結構- 洋蔥 (Onion) 架構

  • 基於 DDD (Domain Driven Design) 設計思維的一種架構呈現。
  • 洋蔥的中心即爲系統最爲穩固的核心 (如圖爲 Domain Model)。
  • 本質仍為三層式 (3-tier) 分層,亦即展示、應用邏輯、資料存取的分層,但特別強調相依反轉 (IoC, Inverse of Control)。

Onion Architecture 分層 (Layer)

  • Domain Model (領域模型)
  • Domain Service (領域服務)
  • Application Service (應用服務)
  • Infrastructure (基礎建設)
閱讀全文 »

微服務總體系統部署架構

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

Client (用戶端)

  • 通常爲使用者界面 (User Interface),例如網頁 (Web Page) 。
  • 用戶端可以透過 API Gateway 取得系統提供的服務。
  • 除了使用者介面外,也可以是其它裝置,例如 Mobile App,以及來自外部系統的 Request。

Identity Provider (身份辨識提供者)

  • 將來自用戶端的請求 (request) 傳遞給身份提供者,身份提供者對客戶端的請求進行身份驗證並將請求傳達給 API Gateway。
  • 通過定義良好 (well defined) 的 API Gateway,將請求轉派 (delegate) 至系統內部的微服務。

API Gateway

  • 用戶端不直接調用 (invoke) 服務,而是透過 API Gateway (閘道) 擔任進入點 (entry point),將請求轉發至適當的微服務。
  • 收到用戶端的請求後,內部架構由微服務組成,微服務通過訊息的相互傳遞,以處理用戶端請求。

使用 API Gateway 的好處

  • 對所有的微服務形成良好的封裝 (encapsulation),內部微服務的變動不會影響到用戶端。
  • 可以將外部通用的協定 (protocol),轉換為 Intranet 內部所使用特定的通訊協定。
  • 可以提供系統橫切 (cross-cut) 的非功能性需求,例如安全性 (security)、負載平衡 (load balance) 等。

Static Content (靜態內容)

將微服務處理後的靜態內容,部署至雲端平台的存儲機制,該機制可以經由內容傳遞網絡 (CDN, Content Delivery Network) 傳回給用戶端,進而可以提供效能、可擴展與較低成本網路傳遞。

Service Discovery (服務檢索)

提供一種目錄服務 (directory service) 的方式,而可以透過多樣化的檢索方式來取得所對應的微服務。

System Management (系統管理)

負責系統節點 (node) 的負載平衡,以及檢測故障 (failures)。

微服務 (Microservices) vs 單體式 (Monolithic) 系統比較

MicroservicesMonolithic
部署 (Deployment)應用程式基於特定的業務能力界定多個微服務,每個微服務爲獨立可各別被部署應用程式只有一個單元的主體
耦合性 (Coupling)每個微服務已元件化,彼此間的溝通只透過 API 連結,因而形成良好的寬鬆耦合 (loose coupling)功能模組之間沒有良好的隔離而造成緊密耦合 (tight coupling)
延展性 (Scalability)可以視微服務的負載情形而各別擴展系統資源只能對系統整體採以複製 (clone) 的方式擴展
開發 (Development)可以依微服務的性質採不同的實現技術;每個微服務的實作團隊可以並行分工開發只能選擇一種特定的實作技術;團隊的分工大都採以模組的切割,或依據分層的技術,需要較高的專案管理 Effort
維護性 (Maintenance)每個微服務可以個別獨立建置、部署與維護由於只有單體式的系統,所以管理與維護會依系統規模度而有着等比複雜度的提昇
適用系統性質平台 (Platform)、產品 (Product)專案 (Project)
適合系統規模大型涵蓋多個業務範疇 (如 ERP) 的系統小型團隊建構規模較小的系統
適合雲端服務非常適合系統規模越大,就越難以部署至雲端平台上
系統開發難易度• 需有總體架構規劃,架構師 (Architect) 或架構團隊需有效界定微服務的邊界 (Bounded Context),以及制定微服務間的 API 協定
• 微服務平行分工的開發團隊需高度正向的密切溝通,持續整合不僅涵蓋技術,也包括人
因大都採以資料導向 (data oriented) 的開發模式,所以初期開發容易;但隨着系統規模度與變動性的議題,很容易導致複雜度的提昇,系統易淪於僵化而難以維護

微服務特點與主要特徵

微服務 (Microservices) 特點

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

主要特徵 (Characteristics)

  • 經由服務 (service) 的元件化 (componentization)。
  • 圍繞業務能力 (business capability) 的組織 (organized)。
  • 分權化的治理 (Decentralized Governance)。
  • 寬鬆耦合 (loose coupling) 的連結性 (connectivity)。
  • 基礎設施的自動化 (Infrastructure Automation)。

閱讀全文 »

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

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

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

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

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

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

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

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

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

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

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

閱讀全文 »

軟體思維顧問

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

Personal