分而治之應該把握哪些原則呢

咱們都知道，分而治之是一種處理複雜問題的通用方法，在系統架構中也是一種很重要的手段，架構的核心思想即是分而治之，那麼，咱們在使用分而治之這個核心思想的時候，應該把握哪些原則呢？

業務原則

1. 單一責任原則：對於一個微服務而言，具備有限的業務範圍，能夠幫助咱們知足服務開發和交付的敏捷性；
2. 適當的邊界：關注微服務的功能範圍，一個服務的大小應該等於知足某個特定業務能力所須要的大小；
3. 業務分層： 從總體規劃上把業務分層，造成單向依賴，避免微服務之間的網狀依賴關係；
4. 顆粒度遞增：設計初期先把業務劃分到儘量細，而後依據其它原則合併到適當顆粒度；
5. 非惟一依賴：至少被2個以上其它微服務依賴的功能模塊，纔有必要獨立成一個微服務。

技術原則

1. 部署獨立性：能獨立於其它微服務部署，一個微服務故障不影響其它微服務；
2. 動態擴展：每一個微服務均可以動態的進行x軸和z軸的擴展，並適應雲環境下的自動化部署；（ 參考這裏 ）
3. 領域和應用解耦：提供數據操做能力的領域服務和執行業務邏輯的應用服務解耦；
4. 避免產生頻繁的跨庫查詢；
5. 避免產生頻繁的分佈式事務。

治理原則

1. 在業務分層的基礎上，根據業務細分規則，對微服務分組；
2. 各個分組之間經過API網關集成；
3. 經過API網關實現級輕量級消息路由，鑑權；
4. 運行時管理，如服務降級，限流，監控等可在API網關實現，讓微服務功能純粹；
5. 避免經過數據庫集成；
6. 避免部署多個版原本兼容。

分解的過程：面對一個系統，特別是前人沒有作過的新系統，一般難以一會兒設計出合適的架構。在架構設計的初期，一般都要經歷一個不斷探索的階段。在架構設計過程當中，架構分解是必不可少的的關鍵步驟。如何進行架構分解？從哪裏入手開始進行分解？咱們須要有一個架構分解的過程模型來指導分解過程，啓發和探索架構分解的維度和線索，提升架構分解的效率。