架構設計:分佈式服務,庫表拆分模式詳解

本文源碼:GitHub·點這裡 || GitEE·點這裡

一、服務間隔離

1、分佈式結構

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

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

2、隔離思想

分佈式的架構體系中,涉及一個根本思想邏輯:隔離;

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

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

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

二、數據庫設計

1、拆分思想

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

水平拆分

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

垂直拆分

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

2、拆分模式

讀寫分離

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

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

分庫分表

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

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

業務分庫

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

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

用戶分庫

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

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

三、架構體系難點

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

1、服務依賴

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

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

2、分佈式事務

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

這裡基於支付業務的轉賬場景做一個簡單的演示,從數據源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});
    }
}

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

四、源代碼地址

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

推薦閱讀:架構設計系列

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