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
http://microservices.io/patterns/microservices.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
通過業務能力分解
http://microservices.io/patterns/decomposition/decompose-by-business-capability.html
業務能力 子能力以及與服務的對應
但業務變遷
頻繁的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.支持服務間協作
為其他服務的實現提供一些幫助