分佈式架構下爲何要分層[ 技術與架構 ]

前言

分佈式架構下若是你的服務沒有分層，那麼不該該叫分佈式架構。有了分層更好的解決服務依賴問題。提升管理效率，開發效率，運維效率

不分層

當只有兩個服務的時候，好好看的清楚，當有四個服務相互依賴的時候，已經暈了

當你有更多服務的時候.....你會？想死，

生產者與消費者分層

分生產者與消費者以後，依賴關係更加明確了，管理起來更加簡單了。看下圖依賴關係是否是很明確了，模塊直接基本作了依賴解耦了，也方便業務解耦

1. 生產者與消費者，不是絕對的一一對應的。

   這裏請問下你們圖中的消費者的模塊爲何分爲用戶模塊與登陸日誌模塊

2. 生產者不能調用生產者，消費者也不能調用消費者。意思就是同層之間不容許相互調用，一旦相互調用，等於沒有分層了。
3. 生產者消費者能夠有不一樣人開發
4. 分層有利於業務演進，分離，解耦,

當系統體量大了怎麼辦？

曾經經歷過一個大型電商項目，業務及其複雜，對高性能，高併發要求極高。實在沒法進行拆分了。因而在消費者之上加一層業務層，解決了上述問題。

這個方式是否是有點像中臺的模塊架構。哈哈。

部署目錄規範

1. 不部署在/home下的用戶目錄，這樣不利於擴展維護等
2. 在/（根） 目錄下建立屬於本身的目錄。分別建立消費者，生產者，業務方三個目錄
3. 在對應目錄下爲服務建立各自的服務名
4. 在服務目錄建立log目錄用於存放日誌，config存放配置文件

.
├── business
│   └── user
│       ├── config
│       └── log
├── consume
│   └── user
│       ├── config
│       └── log
└── producer
    └── user
        ├── config
        └── log

微服務架構項目結構

模塊依賴圖

1. entity

   entiry子模塊裏面存放數據庫實體類，TDO。（我的不喜歡什麼VO，TDO，DDO，項目就那麼大，搞那麼複雜幹什麼細節請看這種 博客管理與技術之方法（接口）行參與返回請用實體類）

2. common

   工具模塊，只要有兩個功能。1. entiry裏面實體類，TDO之間的轉換。2. 寫一些不通用或者工具庫裏面沒有工具方法。當有時間了會把common裏面的工具方法，加入到工具庫裏面。保證common的單一性

3. service Interface

   provider子模塊提供的服務接口，由consumers 或者task 調用

4. provider

   服務提供者，只有被consumere或者task調用以外任何服務都不能調用。

5. consumers

   服務消費者，能夠被business調用或者直接被外部app調用

6. service-consumers

   consumers子模塊提供的服務接口，business 調用

7. business

   業務層

8. task

   定時任務子模塊，不該該和provider與consumers 耦合。provider與consumers一般會部署多個，而task絕大部分狀況只部署一個。若是與provider何consumers 耦合。你可能須要修改每一個的配置，若是忘記修改形成啓動多個task或者沒有啓動task裏面的任務，會形成致命的問題。

項目結構

包路徑應該定義爲:

1. com.dome.user.entity
2. com.dome.user.common
3. com.dome.user.service
4. com.dome.user.provider
5. com.dome.user.consumers
6. com.dome.user.service-consumers
7. com.dome.user.business
8. com.deme.user.task

業務架構與基礎組建的關係

業務模塊應該按需加載基礎組建，不寫到業務模塊裏面，也不該該所有依賴。按需加載依賴就好了。