本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、服務間隔離 ## 1、分散式結構 分散式系統架構的明顯特點，就是按照業務系統的功能，拆分成各種服務，每個服務下面都有自己獨立的資料庫，以此降低業務間的耦合度，隔離不同的資料庫保證系統最大的穩定性等。  例如上圖是電商系統中經典的業務場景，訂單-倉儲-物流的服務模式，不同服務提供不同的應用場景，服務間存在通訊機制，以此實現服務的高可用。 ## 2、隔離思想 分散式的架構體系中，涉及一個根本思想邏輯：隔離； 服務和資料庫根據業務拆分，進而隔離開來，整個架構中某個服務掛掉，不會影響其他的服務繼續執行。例如上述1中：如果物流服務掛掉，影響的是使用者無法實時追蹤物流狀態，但是不會影響訂單的持續產生。 隔離的策略也是各有不同，常見的電商系統是典型的按照業務特點進行拆分，這種就是不同的業務場景下，使用不同的服務和資料庫；還有一種業務場景，多租戶平臺，針對大客戶提供獨立的服務和資料庫，對小客戶提供公服務和資料庫，這種策略比較現實：大客戶帶來收益多，完全覆蓋服務和資料庫的成本，必須保證不能被一些非必要因素影響。 不管是基於什麼策略拆分隔離，首先都必須面對資料庫設計的問題。 # 二、資料庫設計 ## 1、拆分思想 資料庫在業務體系不大的情況，一般都是單庫出現，最多加一個備份庫以備不時之需，當業務體量不斷擴大，就會考慮拆分場景，例如常見的：水平拆分，垂直拆分策略。 **水平拆分** 首先把單表表分割N個結構相同的表，然後把資料按照策略分散到不同的表中，這是表層面；如果把表在分散在不同的資料庫中，這就是資料庫層面的水平拆分。 **垂直拆分** 把單表中資料按照不同特點，拆分成兩張不同的表，常見的策略是根據資料是修改多，還是讀取多，把修改頻繁的欄位放一張表，讀取頻繁的放另一張表，這是表層面；如果根據業務特點，拆分不同庫，這就是資料庫層面。 ## 2、拆分模式 **讀寫分離** 讀寫分離是資料庫拆分的最基本方式，實現起來難度也不大，只需要根據讀寫庫的配置，把業務中資料寫操作路由到寫庫，資料讀操作路由到讀庫即可。  這種方式實現的資料庫拆分雖然相對容易，如果出現主從複製掛掉的情況，就會導致資料讀不到，或者資料讀取延時，所以在強一致的要求的情況下，使用不多。 **分庫分表** 分庫分表主要用來解決單表資料量過大的問題，根據特定欄位的路由規則，把資料分散到不同的庫，不同的表中。  通常是基於一些唯一值的雜湊演算法實現的分庫分表策略。也有一些成熟的中介軟體可以整合到專案直接使用，這種模式更多適用於單點資料的查詢的場景，可以基於路由快速定位資料所在的庫表。 **業務分庫** 基於業務特點拆分資料庫，是當前分散式架構下，或者微服務模式的基礎用法，不同業務場景下資料放在一個庫，因為資料關聯性很強，在使用的時候方便，同時與其他業務資料隔離開來，避免單點故障導致資料庫掛掉。  這種模式雖然看起來更合理，但是複雜度也是非常的陡，因為兩種業務場景下的資料不可能絕對沒有關聯，比如訂單庫一定依賴使用者庫的資訊，這就需要訂單服務和使用者服務之間需要通訊，引發的問題就會很多。 **使用者分庫** 在多租戶場景下，會根據客戶流水大小提供不相同的服務和資料庫，這是一個十分現實的策略，畢竟可能一個大客戶的月流水超過幾個小客戶的總和。  既然可以根據客戶情況分庫，也可以基於其他策略，比如地區，常見雲服務的應用，選擇華南，華北，華東區之類的。 # 三、架構體系難點 這裡所提到的涉及問題，是指基於**業務分庫**模式下的出現的問題。 ## 1、服務依賴 在分散式架構體系下，不同服務都有各自的資料庫，但是資料之間一定是有關係的，服務A要用服務C的資料庫，就必須通過服務C提供的介面來獲取，這是基本機制，不然拆分服務和庫就沒意義了，這樣就會導致服務間產生依賴關係。  如上圖，如果訂單服務和論壇服務同時依賴使用者服務，那麼就要考慮如果使用者服務掛掉，會影響多大的範圍，做好權衡，還有一個關鍵點，如果多個服務依賴一個服務，那麼就要保證被依賴的服務有足夠的能力應對，例如這裡，如果訂單服務有10W的流量，論壇服務有10W的流量，那麼就要保證部署上使用者服務起碼要能承受20W的流量。 ## 2、分散式事務 既然資料庫在不同的服務下面，服務之間又存在依賴關係，那麼保證資料的事務一致性就是非常大的難題。 這裡基於支付業務的轉賬場景做一個簡單的演示，從資料來源1的賬戶表中，向資料來源2的賬戶表中操作轉賬，儘管在程式碼層面看添加了事務最高級別的控制，但是卻沒有起到控制作用，導致出賬成功，但是入賬失敗，這就是典型的分散式事務問題。 ```java @Service public class AccountServiceImpl implements AccountService { @Resource private JdbcTemplate jdbcTemplateOne ; @Resource private JdbcTemplate jdbcTemplateTwo ; /** * @param fromUser 出賬 賬戶 * @param toUser 入賬 賬戶 * @param money 涉及 金額 */ @Transactional(isolation= Isolation.SERIALIZABLE) @Override public 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 ```  **推薦閱讀：架構設計系列** |序號| 標題| |:---|:---| |00 | [架構設計：單服務.叢集.分散式，基本區別和聯絡](https://mp.weixin.qq.com/s/NGxI3rC-6mWMDnrClaOR3Q)| |01 | [架構設計：分散式業務系統中，全域性ID生成策略](https://mp.weixin.qq.com/s/1TKAwr99rKEHSxqXFixEhQ)| |02 | [架構設計：分散式系統排程，Zookeeper叢集化管理](https://mp.weixin.qq.com/s/Yr4A95poVjlFsQ-Q0dF7hA)| |03 | [架構設計：介面冪等性原則，防重複提交Token管理](https://mp.weixin.qq.com/s/o9sxN6GwxdNYTKZvRexwjg)| |04 | [架構設計：快取管理模式，監控和記憶體回收策略](https://mp.weixin.qq.com/s/jBu-OZ69DbXfmdIf5VC7kQ)| |05 | [架構設計：非同步處理流程，多種實現模式詳解](https://mp.weixin.qq.com/s/RQm1vPJak0rCGW8dll4oAA)| |06 | [架構設計：高併發流量削峰，共享資源加鎖機制](https://mp.weixin.qq.com/s/T13aak6us7ZF36qo