數據庫分布式架構下為什么要分層

這篇文章主要介紹“數據庫分布式架構下為什么要分層”，在日常操作中，相信很多人在數據庫分布式架構下為什么要分層問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫分布式架構下為什么要分層”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

前言

分布式架構下如果你的服務沒有分層，那么不應該叫分布式架構。有了分層更好的解決服務依賴問題。提高管理效率，開發效率，運維效率

不分層

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

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

生產者與消費者分層

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

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

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

業務模塊應該按需加載基礎組建，不寫到業務模塊里面，也不應該全部依賴。按需加載依賴就行了。

到此，關于“數據庫分布式架構下為什么要分層”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！