一、現狀

現狀.png

我們將一個大而全的系統一拆為三，容器，發布，測試都已經獨立出去，但是原始的數據庫還是一套，現在需要將數據庫做一個拆分，A、B、C三個系統有各自的數據庫之后，我們的微服務化在現有部署、測試等已經獨立的基礎上才算最終完成，形成三個各自獨立的單元。因此本篇文章敘述的不是數據庫的水平拆分也不是垂直拆分，不是講述分庫分表，而是講述從業務系統去拆分數據庫，把業務最終微服務化。

二、方法

拆分方案.png

2.1、SOA

通過提供RPC接口，將原先共用的表有一方系統提供接口服務，另一方系統來調用該接口。這種情況下系統之間是解耦了，但是數據調用的時候一方還是要強依賴另一方。這個時候要重新關注接口服務方如果down掉或者延時發生，需要有容錯機制，比如熔斷、降級等。同時要考慮好數據的托底展示，比如本機緩存，remote緩存。詳細可參看《微服務下的網關與容錯》里面有專項介紹。

2.2、數據異構

通過數據異構的方式，比如B系統與C系統原來是一張表，數據庫拆分之后這張表的數據放在了C系統，但是B系統只需要這張表的部分字段，這個時候可以通過異構平臺把C系統的表按需異構到B系統中的一張表。這樣兩個系統之間徹底解耦，各自微服務化，也沒有了SOA方式的強依賴問題。關于數據異構的詳細介紹可以參看這篇文章

《數據異構的武器-BINLOG+MQ》

三、拆庫的步驟(mysql)

集群A(源庫)

集群B(新搭建)

集群C(新搭建)

DB拆庫起始位置.png

注意此方案需要停寫！

步驟一、搭建集群B、C

將集群B、C以從庫形式掛載到集群A

步驟二、將如下集群A主庫設置為只讀模式

192.168.x.x xx.mysql.xxx.com

命令：set global read_only=on;

步驟三、待從庫無延遲后，集群B、C停止復制，執行如下操作

命令：stop slave;

此時A、B、C三套集群均為只讀模式

步驟四、研發人員修改應用url指向到正確的數據庫集群，待確認無誤后，(此時可回退，打開寫后不可回退)

通知DBA將集群A、B、C三套打開讀寫

命令：set global read_only=off;

步驟五、拆分完成

DB最終位置.png

步驟六

觀察一段時間后drop冗余表，DBA在復制的時候實際上是全量復制，因此后續我們需要drop掉各自系統內不需要的表。可以用rename的方式先行標出，一段時間后再drop掉。

===================================================================

回退方案

步驟一、集群B、C打開復制

命令：start slave;

步驟二、打開集群A的讀寫

命令：set global read_only=on;

四、SOA和微服務

SOA面向服務架構，是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。關鍵點是接口調用，這是目前分布式系統中常用的方法。目前開源的RPC框架也有很多比如知名的DUBBO服務等。

微服務的重點是業務系統要徹底組件化和服務化，原有的單體應用系統會拆分為多個可以獨立開發、運行、部署和運維的小應用。這些小的應用之間如果需要交互就通過服務來完成，比如提供DUBBO接口服務。每個小應用內部從前端WEB到業務邏輯處理，到數據庫訪問，以及數據庫都是獨立的。

五、總結

業務簡單，團隊組織規模較小的時候一個單體應用就可以支持當時的業務發展。隨著業務的發展規模越來越大，過程中如果技術架構升級沒有跟上，就會面臨后期拆系統，拆庫的的階段。本篇文章結合我工作中自身的經歷集中對數據庫的業務拆分做了描述，拆庫的原則以及數據庫新集群的創建方法。對于拆分，我們要拆的粒度有多大，或者多小，沒有一個標準，關于這方面，推薦大家閱讀一本書《恰如其分的軟件架構》。

關注公眾號同步更新技術文

總結

以上是生活随笔為你收集整理的mysql构建栋_【转载】这次拆库 应是微服务化的拆分方式的全部內容，希望文章能夠幫你解決所遇到的問題。

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