分散式架構下為什麼要分層[ 技術與架構 ]
前言
分散式架構下如果你的服務沒有分層，那麼不應該叫分散式架構。有了分層更好的解決服務依賴問題。提高管理效率，開發效率，運維效率
不分層
當只有兩個服務的時候，好好看的清楚，當有四個服務相互依賴的時候，已經暈了
當你有更多服務的時候.....你會？想死，
生產者與消費者分層
分生產者與消費者之後，依賴關係更加明確了，管理起來更加簡單了。看下圖依賴關係是不是很明確了，模組直接基本做了依賴解耦了，也方便業務解耦
- 生產者與消費者，不是絕對的一一對應的。
這裡請問下大家圖中的消費者的模組為什麼分為使用者模組與登入日誌模組 - 生產者不能呼叫生產者，消費者也不能呼叫消費者。意思就是同層之間不允許相互呼叫，一旦相互呼叫，等於沒有分層了。
- 生產者消費者可以有不同人開發
- 分層有利於業務演進，分離，解耦,
當系統體量大了怎麼辦？
曾經經歷過一個大型電商專案，業務及其複雜，對高效能，高併發要求極高。實在無法進行拆分了。於是在消費者之上加一層業務層，解決了上述問題。
這個方式是不是有點像中臺的模組架構。哈哈。
部署目錄規範
- 不部署在/home下的使用者目錄，這樣不利於擴充套件維護等
- 在/（根） 目錄下建立屬於自己的目錄。分別建立消費者，生產者，業務方三個目錄
- 在對應目錄下為服務建立各自的服務名
- 在服務目錄建立log目錄用於存放日誌，config存放配置檔案
. ├── business │ └── user │ ├── config │ └── log ├── consume │ └── user │ ├── config │ └── log └── producer └── user ├── config └── log
微服務架構專案結構
模組依賴圖
- entity
entiry子模組裡面存放資料庫實體類，TDO。（個人不喜歡什麼VO，TDO，DDO，專案就那麼大，搞那麼複雜幹什麼細節請看這種 部落格管理與技術之方法（介面）行參與返回請用實體類）
- common
工具模組，只要有兩個功能。1. entiry裡面實體類，TDO之間的轉換。2. 寫一些不通用或者工具庫裡面沒有工具方法。當有時間了會把common裡面的工具方法，加入到工具庫裡面。保證common的單一性
- service Interface
provider子模組提供的服務介面，由consumers 或者task 呼叫
- provider
服務提供者，只有被consumere或者task呼叫之外任何服務都不能呼叫。
- consumers
服務消費者，可以被business呼叫或者直接被外部app呼叫
- service-consumers
consumers子模組提供的服務介面，business 呼叫
- business
業務層
- task
定時任務子模組，不應該和provider與consumers 耦合。provider與consumers通常會部署多個，而task絕大部分情況只部署一個。如果與provider何consumers 耦合。你可能需要修改每個的配置，如果忘記修改造成啟動多個task或者沒有啟動task裡面的任務，會造成致命的問題。
專案結構
包路徑應該定義為:
- com.dome.user.entity
- com.dome.user.common
- com.dome.user.service
- com.dome.user.provider
- com.dome.user.consumers
- com.dome.user.service-consumers
- com.dome.user.business
- com.deme.user.task
業務架構與基礎組建的關係
業務模組應該按需載入基礎組建，不寫到業務模組裡面，也不應該全部依賴。按需載入依賴就