架構設計：分佈式服務，庫表拆分模式詳解

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、服務間隔離

一、分佈式結構

分佈式系統架構的明顯特色，就是按照業務系統的功能，拆分紅各類服務，每一個服務下面都有本身獨立的數據庫，以此下降業務間的耦合度，隔離不一樣的數據庫保證系統最大的穩定性等。

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

二、隔離思想

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

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

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

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

2、數據庫設計

一、拆分思想

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

水平拆分

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

垂直拆分

把單表中數據按照不一樣特色，拆分紅兩張不一樣的表，常見的策略是根據數據是修改多，仍是讀取多，把修改頻繁的字段放一張表，讀取頻繁的放另外一張表，這是表層面；若是根據業務特色，拆分不一樣庫，這就是數據庫層面。

二、拆分模式

讀寫分離

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

這種方式實現的數據庫拆分雖然相對容易，若是出現主從複製掛掉的狀況，就會致使數據讀不到，或者數據讀取延時，因此在強一致的要求的狀況下，使用很少。

分庫分表

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

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

業務分庫

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

這種模式雖然看起來更合理，可是複雜度也是很是的陡，由於兩種業務場景下的數據不可能絕對沒有關聯，好比訂單庫必定依賴用戶庫的信息，這就須要訂單服務和用戶服務之間須要通訊，引起的問題就會不少。

用戶分庫

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

既然能夠根據客戶狀況分庫，也能夠基於其餘策略，好比地區，常見雲服務的應用，選擇華南，華北，華東區之類的。

3、架構體系難點

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

一、服務依賴

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

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

二、分佈式事務

既然數據庫在不一樣的服務下面，服務之間又存在依賴關係，那麼保證數據的事務一致性就是很是大的難題。

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

@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});
    }
}

這裏只是先演示分佈式事務的問題，如何解決分佈式事務問題，須要不少的篇幅描述，後面的連續幾篇文章再細說。

4、源代碼地址

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

推薦閱讀：架構設計系列

序號	標題
00	架構設計：單服務.集羣.分佈式，基本區別和聯繫
01	架構設計：分佈式業務系統中，全局ID生成策略
02	架構設計：分佈式系統調度，Zookeeper集羣化管理
03	架構設計：接口冪等性原則，防重複提交Token管理
04	架構設計：緩存管理模式，監控和內存回收策略
05	架構設計：異步處理流程，多種實現模式詳解
06	架構設計：高併發流量削峯，共享資源加鎖機制