服務粒度——“三個火槍手”原則
三個火槍手原則就是一個微服務由三個人負責開發。一般來說，在進行微服務架構時，根據團隊規模來劃分微服務數量是合理的。
而為什么是3個人？？？？
- 從系統規模來講，3 個人負責開發一個系統，系統的復雜度剛好達到每個人都能全面理解整個系統，又能夠進行分工的粒度；如果2個人開發一個系統，系統復雜度不夠；如果4個人甚至更多人開發一個系統，系統復雜度又會無法讓開發人員對系統的細節都了解很深。
- 從團隊管理來說，3個人可以形成一個穩定的備份，即使1個人有事不在，2個人也可以支撐；如果2個人的話，少了一個人剩余的1個人壓力就很大；如果是1個人就更慘了
- 從技術角度，3個人的技術小組能夠形成有效的討論，能快速達成一致意見；如果是2個人，可能會有意見無法統一問題；如果4個人或更多，就會出現有的成員不認真討論，開會劃水。
拆分方法
- 基于業務邏輯拆分：最常見的拆分方式，將系統中的業務模塊按照職責范圍識別出，每個業務模塊拆分為一個獨立的服務。但是，每個人對職責范圍的理解不一樣，如：電商系統中，可以分為“商品”“交易”“用戶”3個服務，也可以分為“商品”，“訂單”，“支付”，“買家”，“賣家”，“發貨”6個服務
- 基于可拓展拆分：將系統中的業務模塊按照穩定性排序，將成熟的和改動不大的服務拆分為穩定服務，將經常變化和迭代的服務拆分為變動服務。穩定服務的顆粒度可以粗一些（及時是邏輯上沒有強關聯的服務，也可以放在同一個子系統中）；不穩定的服務可以劃分的細一些（控制數量，參考三個火槍手原則）。這樣拆分還有個好處是避免開發時不小心影響了成熟的功能。
- 基于可靠性拆分：將系統中的業務模塊按照優先級排序，將可靠性要求高的核心服務和可靠性要求低的非核心服務拆分開來，然后重點保證核心服務的高可用。好處：
- 避免非核心服務故障影響核心服務。日志功能屬于非核心服務，將其拆分出來，及時日志系統出問題，也不影響核心服務
- 核心服務高可用方案可以更簡單。核心服務的功能邏輯將變簡單，且存儲的數據可能更少，用到的組件也會更少明科技高可用方案要簡單。
- 降低高可用方案成本。如上一條所講，將核心服務拆分后，功能邏輯將變簡單、存儲的數據更少。。。帶來的核心服務占用的機器、帶寬等資源將減少。
4. 基于性能拆分：將性能要求高或性能壓力大的模塊拆分出來，避免改模塊的性能壓力問題而影響其他服務。常見的拆分方式和具體的性能瓶頸有關，可以拆分web服務、數據庫、緩存等。例如電商的搶購，性能壓力大的是入口排隊，可以將排隊功能獨立成一個服務
以上拆分方式可以根據實際情況自由組合，例如可以基于可靠性拆分出服務A，基于性能拆分出服務B，基于可擴展拆分出C/D/F服務等。
基礎設施
如圖，為微服務的基礎設施
微服務所帶來的快速開發，這是建立在有良好的基礎設施上，換句話說，沒有自動測試、自動化部署等等等等支持，當服務拆分的越來越多的時候，也就是所有開發同學、運維同學、測試同學崩潰的時候
通常情況下，一個公司或團隊要實施微服務，可以從如下優先級開始：
- 服務發現、服務路由、服務容錯：這些是最最基本的：）
- 接口框架、API網關：主要是為了提高開發效率，接口框架是提升內部服務的開發效率、API網關是為了提升與外部服務對接的效率
- 自動化部署、自動化測試、配置中心：主要是為了提升測試和運維效率
- 服務監控、服務跟蹤、服務安全：提升運維效率
原文鏈接：
https://blog.csdn.net/u010530712/article/details/84837251
