簡介：分布式系統架構的明顯特點，就是按照業務系統的功能，拆分成各種服務，每個服務下面都有自己獨立的數據庫，以此降低業務間的耦合度，隔離不同的數據庫保證系統最大的穩定性等。

一、服務間隔離

1、分布式結構

分布式系統架構的明顯特點，就是按照業務系統的功能，拆分成各種服務，每個服務下面都有自己獨立的數據庫，以此降低業務間的耦合度，隔離不同的數據庫保證系統最大的穩定性等。

例如上圖是電商系統中經典的業務場景，訂單-倉儲-物流的服務模式，不同服務提供不同的應用場景，服務間存在通信機制，以此實現服務的高可用。

2、隔離思想

分布式的架構體系中，涉及一個根本思想邏輯：隔離；

服務和數據庫根據業務拆分，進而隔離開來，整個架構中某個服務掛掉，不會影響其他的服務繼續執行。例如上述1中：如果物流服務掛掉，影響的是用戶無法實時追蹤物流狀態，但是不會影響訂單的持續產生。

隔離的策略也是各有不同，常見的電商系統是典型的按照業務特點進行拆分，這種就是不同的業務場景下，使用不同的服務和數據庫；還有一種業務場景，多租戶平臺，針對大客戶提供獨立的服務和數據庫，對小客戶提供公服務和數據庫，這種策略比較現實：大客戶帶來收益多，完全覆蓋服務和數據庫的成本，必須保證不能被一些非必要因素影響。

不管是基于什么策略拆分隔離，首先都必須面對數據庫設計的問題。

二、數據庫設計

1、拆分思想

數據庫在業務體系不大的情況，一般都是單庫出現，最多加一個備份庫以備不時之需，當業務體量不斷擴大，就會考慮拆分場景，例如常見的：水平拆分，垂直拆分策略。

水平拆分

首先把單表表分割N個結構相同的表，然后把數據按照策略分散到不同的表中，這是表層面；如果把表在分散在不同的數據庫中，這就是數據庫層面的水平拆分。

垂直拆分

把單表中數據按照不同特點，拆分成兩張不同的表，常見的策略是根據數據是修改多，還是讀取多，把修改頻繁的字段放一張表，讀取頻繁的放另一張表，這是表層面；如果根據業務特點，拆分不同庫，這就是數據庫層面。

2、拆分模式

讀寫分離

讀寫分離是數據庫拆分的最基本方式，實現起來難度也不大，只需要根據讀寫庫的配置，把業務中數據寫操作路由到寫庫，數據讀操作路由到讀庫即可。

這種方式實現的數據庫拆分雖然相對容易，如果出現主從復制掛掉的情況，就會導致數據讀不到，或者數據讀取延時，所以在強一致的要求的情況下，使用不多。

分庫分表

分庫分表主要用來解決單表數據量過大的問題，根據特定字段的路由規則，把數據分散到不同的庫，不同的表中。

通常是基于一些唯一值的哈希算法實現的分庫分表策略。也有一些成熟的中間件可以集成到項目直接使用，這種模式更多適用于單點數據的查詢的場景，可以基于路由快速定位數據所在的庫表。

業務分庫

基于業務特點拆分數據庫，是當前分布式架構下，或者微服務模式的基礎用法，不同業務場景下數據放在一個庫，因為數據關聯性很強，在使用的時候方便，同時與其他業務數據隔離開來，避免單點故障導致數據庫掛掉。

這種模式雖然看起來更合理，但是復雜度也是非常的陡，因為兩種業務場景下的數據不可能絕對沒有關聯，比如訂單庫一定依賴用戶庫的信息，這就需要訂單服務和用戶服務之間需要通信，引發的問題就會很多。

用戶分庫

在多租戶場景下，會根據客戶流水大小提供不相同的服務和數據庫，這是一個十分現實的策略，畢竟可能一個大客戶的月流水超過幾個小客戶的總和。

既然可以根據客戶情況分庫，也可以基于其他策略，比如地區，常見云服務的應用，選擇華南，華北，華東區之類的。

三、架構體系難點

這里所提到的涉及問題，是指基于業務分庫模式下的出現的問題。

1、服務依賴

在分布式架構體系下，不同服務都有各自的數據庫，但是數據之間一定是有關系的，服務A要用服務C的數據庫，就必須通過服務C提供的接口來獲取，這是基本機制，不然拆分服務和庫就沒意義了，這樣就會導致服務間產生依賴關系。

如上圖，如果訂單服務和論壇服務同時依賴用戶服務，那么就要考慮如果用戶服務掛掉，會影響多大的范圍，做好權衡，還有一個關鍵點，如果多個服務依賴一個服務，那么就要保證被依賴的服務有足夠的能力應對，例如這里，如果訂單服務有10W的流量，論壇服務有10W的流量，那么就要保證部署上用戶服務起碼要能承受20W的流量。

2、分布式事務

既然數據庫在不同的服務下面，服務之間又存在依賴關系，那么保證數據的事務一致性就是非常大的難題。

這里基于支付業務的轉賬場景做一個簡單的演示，從數據源1的賬戶表中，向數據源2的賬戶表中操作轉賬，盡管在代碼層面看添加了事務最高級別的控制，但是卻沒有起到控制作用，導致出賬成功，但是入賬失敗，這就是典型的分布式事務問題。

@Service public class AccountServiceImpl implements AccountService {@Resourceprivate JdbcTemplate jdbcTemplateOne ;@Resourceprivate JdbcTemplate jdbcTemplateTwo ;/*** @param fromUser 出賬 賬戶* @param toUser 入賬 賬戶* @param money 涉及 金額*/@Transactional(isolation= Isolation.SERIALIZABLE)@Overridepublic void transfer(String fromUser, String toUser, int money) {// fromUser 出賬jdbcTemplateOne.update("UPDATE user_account SET money = money-? WHERE username= ?",new Object[] {money, fromUser});int i = 1/0 ;// toUser 入賬jdbcTemplateTwo.update("UPDATE user_account SET money = money+? WHERE username= ?",new Object[] {money, toUser});} }

這里只是先演示分布式事務的問題，如何解決分布式事務問題，需要很多的篇幅描述，后面的連續幾篇文章再細說。

四、源代碼地址

GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent

原文鏈接：https://developer.aliyun.com/article/766380?

版權聲明：本文中所有內容均屬于阿里云開發者社區所有，任何媒體、網站或個人未經阿里云開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式復制發布/發表。申請授權請郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發者社區協議授權的媒體、網站，在轉載使用時必須注明"稿件來源：阿里云開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：developer2020@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的架构设计：分布式服务，库表拆分模式详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。