從單體架構升級到微服務,在代碼層面應注意的一些問題
作者:jajian
http://cnblogs.com/jajian/p/11101196.html
推薦閱讀(點擊即可跳轉閱讀)
1. SpringBoot內容聚合
2. 面試題內容聚合
3. 設計模式內容聚合
4. 排序演算法內容聚合
5. 多線程內容聚合
由於近年來的移動端的發展和 2C模式 的紅利,一些在風口的企業的業務得到爆髮式增長。從架構層面來說,業務驅動技術的變革,所以微服務架構的概念得到很多企業的青睞,因為可以解決服務的大流量和高並發以及穩定性的要求。
但是任何架構設計不是一蹴而就的,不能從起步就開始使用微服務,一般都是先通過單體架構來快速實現需求和搶佔市場,然後再迭代式擴展。不能一口氣吃個胖子。
這幾年自己有經歷從單體到微服務的架構演變,也有直接參与到已經落地的微服務架構的項目中。見過好的架構設計,也見過一些孬的設計。好的架構設計,代碼結構優雅,分層清晰,業務邊界劃分明朗,業務開發人員職責清晰。不好的設計就會導致代碼混亂難以維護,對新需求無法快速應變,開發人員容易在補丁上打補丁,最後造成積重難返不得不重構。
架構師需要從業務層面和未來業務發展有個全面的規劃,讓架構高可用,易擴展,靈活易使用,隱藏其複雜性。好的架構會讓下面的業務開發人員按照既定的模式「傻瓜式」編程。
既然第一步是單體架構,那麼好的單體架構設計,為我們後期的微服務拆分會有事半功倍的效果。避免重複勞動和過多的重寫。我們可以從這些方面進行一些有效的設計。
1、劃清業務邊界
如果對未來的架構有微服務的考慮,那麼在單體架構的時候就需要理清業務邊界的問題,常見的簡單劃分就是以業務區分,例如:用戶,商品,訂單,支付,許可權等等,具體的拆分程度可根據自身業務量和需要做劃分。
當前流行的 DDD(領域驅動設計)可以作為一個指導原則,但是 DDD 比較偏向於理論,需要執行人員有良好的專業能力才能實施的比較好。
2、代碼層次結構
業務區分好之後,就是項目代碼模塊的設計。在代碼層我們需要根據MVC的模式,建議的代碼設計層次如下:
├─demo-common
│ │ demo-common.iml
│ │ pom.xml
│ │
│ └─src
│ ├─main
│ │ ├─java
│ │ └─resources
│ └─test
│ └─java
├─demo-dao
│ │ demo-dao.iml
│ │ pom.xml
│ │
│ └─src
│ ├─main
│ │ ├─java
│ │ └─resources
│ └─test
│ └─java
├─demo-service
│ │ demo-service.iml
│ │ pom.xml
│ │
│ └─src
│ ├─main
│ │ ├─java
│ │ └─resources
│ └─test
│ └─java
└─demo-web
│ demo-web.iml
│ pom.xml
│
└─src
├─main
│ ├─java
│ └─resources
└─test
└─java
主要包含4個 module 模塊
- demo-common:基礎模塊,枚舉,常亮類,工具類,配置類。
- demo-dao:Dao層,mapper介面,mapper.xml。
- demo-service:服務介面提供層,業務service介面。
- demo-web:web層,Controller類,服務介面,與外部進行交互。
各模塊之間的依賴關係為: