微服務模式筆記:服務分解策略
Microservice Patterns第二章的讀書筆記
原章節連結: https://learning.oreilly.com/library/view/microservices-patterns/9781617294549/kindle_split_010.html
Decomposition strategies
微服務最關鍵的挑戰 也就是微服務的本質是如何將應用的功能分解到服務中去
服務是業務相關而不是技術相關
2.1. What is the microservice architecture exactly?
2.1.1. What is software architecture and why does it matter?
應用架構是將應用分解成各個部分(元素)和這些部分間的關係
軟體架構的4+1 view model
簡單理解就是從幾個角度來描述架構
www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
- Logical view : 開發者建立的軟體元素。就像類和包 類之間的繼承 關聯和依賴
- Implementataion view: 構建系統的產出。比如java是jar或者war
- Process view:執行時元件.每個元素都是一個程序，和各個程序間的程序間通訊。
- Deployment：程序是如何對映到機器的。
架構對於功能需求基本沒有什麼幫助
但架構又是重要的 因為他讓應用滿足第二種需求: 服務質量(quality of service,QoS)需求
2.1.2. Overview of architectural styles
一種特定的架構提供有限的元素(元件)調色盤和關係(connectors)
你從中定義出應用架構的檢視
分層架構
定義了三層:
- Presentation layer: 包含實現了使用者介面和額外的API的程式碼
- Business logic layer： 包含業務邏輯
- Persistence layer：包含和資料庫互動的邏輯
但是也有明顯的缺點：
- 單一的展示層
- 單一的持久層
- 定義的業務邏輯依賴於持久層 離開資料庫無法測試
會存在依賴倒置，業務層定義的資料訪問介面最後需要持久層定義DAO類去實現(低層依賴高層所提供的介面)
六邊形架構
將業務放在了最中心
inbound adapter
outbound adapter
業務邏輯不依賴於adapter 相反是adapter依賴於業務邏輯
一個業務邏輯有一個或多個 ports
一個 port 定義了一系列業務邏輯和外部互動的操作
六邊形架構最大的好處是將展示層和資料訪問邏輯從業務邏輯中解耦
2.1.3. The microservice architecture is an architectural style
單體架構在implement view就是一個單獨可執行的jar或war
http://microservices.io/patterns/monolithic.html
什麼是服務
服務是獨立的 無依賴的可部署軟體元件 實現了一些有用的功能
不同服務間只能通過API呼叫 不像單體還可以通過程式碼
鬆耦合
https://en.wikipedia.org/wiki/Loose_coupling
服務間的互動只通過API 封裝細節
共享庫
只在不太可能會發生變化的地方使用共享庫
和具體業務無關 通用的功能上
服務的大小不重要
和組織結構相關
2.2. Defining an application’s microservice architecture
3步定義應用的微服務架構
這裡只是展示一個例子 現實中會有更多的問題
需要迭代等
system operation
其實也就是找到各個請求和迴應(或者找到各個事件)
服務拆分的一些阻礙:
- 網路延遲
- 服務間的同步呼叫降低了可用性
- 在不同服務間維持資料一致性
2.2.1. Identifying the system operations
從應用的需求出發 包括user story和對應的使用者場景
system operation
commands:建立 更新和刪除資料
queries: 查詢資料
分析user stories和場景中的動詞
一個例子:
2.2.2. Defining services by applying the Decompose by business capability pattern
業務能力 子能力以及與服務的對應
但業務變遷
頻繁的RPC帶來的效能損耗
會帶來一定的阻礙
2.2.3. Defining services by applying the Decompose by sub-domain pattern
DDD
subdmain
bounded context
http://microservices.io/patterns/decomposition/decompose-by-subdomain.html 
2.2.4. Decomposition guidelines
一些分解的原則
可以沿用一些OO裡的原則
單一職責原則
共同封閉原則(Common Closure Principle)
因為一個相同的原因導致兩個類需要修改 這兩個類應該在一個包下
對應於微服務 把要因為同一個原因修改的元件放到同一個服務裡去
通過業務能力和子域 結合SRP和CCP是一個很好的分解一個應用到服務的技術
為了應用他們成功地開發微服務架構 你必須解決一些事務管理和跨程序通訊問題
2.2.5. Obstacles to decomposing an application into services
一些阻礙:
- 網路延遲
- 同步通訊導致的可用性降低
- 跨服務的資料一致性維護
- 獲取資料的一致性檢視
- 上帝類阻止分解
網路延遲
網路延遲是分散式系統長期困擾的問題.
服務拆解之後可能會發現有大量的服務間的往返通訊
可以提供批處理API在一次往返中
但一些其他場景 可能就需要整合服務了
同步通訊導致的可用性降低
改進方法是非同步訊息傳輸
跨服務的資料一致性維護
涉及到分散式事務 saga 最終一致性
獲取資料的一致性檢視
實踐中一般不會是太大的問題
上帝類阻止分解
上帝類(god classes)是一個龐大的類 在整個專案中被貫穿使用
一般都是為了實現了一個應用不同方面的業務邏輯 有大量的field
方案1:
提供一個庫 並建立一箇中央的order資料庫
問題是緊耦合…所有的服務都要連到這個庫
方案2:
封裝order資料庫到order服務
這樣就把他變為了類似資料庫API的服務 只是為了提供order資料庫的訪問而存在
方案3:
使用DDD 將order的概念分解 各個子域有自己的order
但這樣會影響使用者體驗 在使用者體驗和多個實際模型間要有一種翻譯
2.2.6. Defining service APIs
定義服務API
他的操作和事件
基於兩點:
1. System operation 需要
這個API可能是被客戶端直接呼叫 也可能是服務端直接呼叫 用來完成這個服務裡的某個具體操作
2.支援服務間協作
為其他服務的實現提供一些幫助