Development

SOA架構 與 Microservice

之前遇到問題查詢的資料，做個整理。

Service Oriented Architecture(SOA) 服務導向架構

特性:

  • 針對某特定要求的輸出，該服務就是運作一項商業邏輯
  • 具有完備的特性（self-contained）
  • 消費者並不需要瞭解此服務的運作過程
  • 可能由底層其他服務組成

原則:

  • 可重複使用、粒度、模組性、可組合型、物件化原件、構件化以及具互動操作性
  • 符合開放標準（通用的或行業的）
  • 服務的識別和分類，提供和發布，監控和跟蹤。

SOA 所解決的核心問題

  • 系統整合(技術層面)
  • 系統的服務化(技術層面)
  • 業務的服務化(是以業務驅動把一個 業務單元封裝成一項服務）

SOA

Microservices 微服務

  • 通過服務實現元件化
  • 按業務能力來劃分服務和開發團隊
  • 去中心化
  • 基礎設施自動化（devops、自動化部署）
    與服務導向架構（Service-Oriented Architecture）不同，後者是整合各種業務的應用程式，但微服務只屬於一個應用程式。(強調單一業務組件化)

Microservices 特性

  • 每個服務都容易被取代。
  • 服務是以能力來組織的，例如使用者介面、前端、推薦系統、帳單或是物流等。
  • 由於功能被拆成多個服務，因此可以由不同的程式語言、資料庫實作。
  • 架構是對稱而非分層（即生產者與消費者的關係）

Microservices

Microservices 資料庫三種設計模式

  1. 每個服務都各有一個數據庫，同屬性的服務可共享同個資料庫。
  2. 所有服務都共享同個資料庫，但是不同表格，並且不會跨域存取。
  3. 每個服務都有自己的資料庫，就算是同屬性的也是，資料庫並不會共

資料庫的可棄性:
實踐微服務架構中有許多的做法。但是其中一種的做法是將資料庫視作短期的儲存空間而不是長期的資料。因為他們可以在上線時從事件中心回覆，因此可以快速的從記憶體中快速存取（例：Redis）作為資料庫伺服器。這種做法需要將每個請求當作事件來進行廣播，這樣就可以從事件儲存中心重播所有的事件。

在微服務中，則通過 API 調用來完成。這些模塊或者服務間調用，大部分時候是為了共享數據。
共享數據最賤的方式當然就是採用一種共享資料庫的模式，也就是單體應用常用的方式。應用可以有多個系統模塊，但一般都是只有一個資料庫。

一庫一服 vs 一庫多服

一庫多服，這種架構模式通常會被認為是 微服務架構下的反範式，它的問題在於:

  • 單點故障：一個資料庫倒下，整批服務全部停止。何來的服務獨立性？
  • 數據在同一個地方，會給貪圖方便的開發或者 DBA 工程師編寫很多數據間高度依賴的程序或者工具。
  • 無法針對某一個服務進行精準優化或擴展。
    所以一般推薦的做法，是為每一個微服務準備一個單獨的資料庫，也即一庫一服(Database per Service)模式。這種模式更加適合微服務架構，它滿足每一個服務是獨立開發、獨立部署、獨立擴展的特性。需要對一個服務進行升級或者數據架構改動的時候，不會影響到其他的服務。需要對某個服務進行擴展的時候，也可以手術式的對某一個服務進行局部擴容。

微服務的切割

  1. domain-driven design (DDD) 領域驅動設計
  • Infrastructure（基礎實施層）
  • Domain（領域層）
  • Application（應用層）
  • Interfaces（表示層，也叫用戶界面層或是接口層）

domain-driven design(DDD)

  1. 資料結構

微服務的利和弊

Microservices 利與弊

  • 利: 單一服務組件化、可獨立部署、技術多樣性
  • 弊: 分佈式的系統複雜性(各別服務的溝通複雜化)、最終一致性、運維複雜性

微服務(設計模式)

鏈式設計模式

聚合器設計模式

代理設計模式

分支設計模式

資料庫共享模式

異部消息設計模式

Service Oriented Architecture 與 Microservice 差別