在微服務的設計程序中，微服務設計有多大，微服務粒度的把控，一直是設計人員需要考慮和設計的難點，
因為服務粒度設計過大，不能得到微服務架構帶來的便利，例如：更加敏態的開發，更頻繁的版本發布，由于服務功能劃分的小，可以根據實際的業務場景，選擇更加合適的技術進行代碼重構等等，
但同時我們也要注意，不是服務越”微“越好，因為服務的過度拆分會使架構的設計復雜度大大提升，同時也會大大提升運維和測驗的復雜度等，
所以對服務拆分粒度的把控，對設計人員來講就至關重要了，甚至對專案的成敗有非常重要的影響，
這篇檔案提供了一些主要的微服務拆分原則，供您參考，來幫助您進行更加合理粒度的微服務設計，
微服務的拆分原則 - 通用
| 編號 | 原則 | 說明 |
| 原則1 | 基于業務分析拆分 | 基于TOGAF， ADA等 |
| 原則2 | 基于DDD領域驅動設計中的子域設計拆分 | 基于領域驅動設計 |
| 原則3 | 根據動作和用例拆分 | 比如支付 |
| 原則4 | 根據名詞或者資源拆 | 比如賬號 |
| 原則5 | 架構穩定 | 拆分的結構穩定, 不會經常修改 |
| 原則6 | 服務是可測驗的 | 集成測驗要可定義，測驗可回溯 |
| 原則7 | 單一原則 | 一個服務做一個業務， 自己治理自己的資料庫 |
| 原則8 | 開閉原則 | 面向物件理論， 對擴展開放， 對修改關閉 |
| 原則9 | 高內聚 | 強一致，強依賴關系的放在一起， 減少分布式事務 |
| 原則10 | 松耦合 | 服務間互相獨立 |
| 原則11 | 足夠小的團隊可維護，最大兩個pizza team | 6-10人一個pizza team |
| 原則12 | 團隊自治，自己的服務的開發和發布要跟別的團隊盡可能小的協調 |
微服務的拆分原則 - 技術側重點
| 編號 | 原則 | 說明 |
| 原則1 | 潛在風險 | 服務的風險性 |
| 原則2 | 資源性能
| 機器的性能決定了方案的部分選擇 |
| 原則3 | 安全 | 安全要求是否很高，安全的策略 |
| 原則4 | 高并發
| 并發的種類， 持續的時間 |
| 原則5 | 資料庫
| 資料的型別， 讀寫的多少，資料量 |
微服務的拆分原則 - 專案側重點
| 編號 | 原則 | 說明 |
| 原則1 | 價格 | 預算，人力成本 |
| 原則2 | 時間 | 專案的緊急程度， 時間的長短 |
| 原則3 | 人 | 人員結構， 成員素質， 技識訓累 |
----------------------------------
大家好，我是流水，一個資深的IT從業人員和架構師. 非常高興您能搜索到，并看到這篇文章，希望這篇文章的內容能給您帶來新的知識和幫助，
也歡迎掃描以下的二維碼或微信搜索 “superxtech”，關注我的微信公眾號 , 我會把更多更好的IT領域技術知識帶給您！
----------------------------------
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/265897.html
標籤：其他
下一篇：Docker進階篇