朝着微服務的方向去作一次數據庫拆分
1、現狀
咱們將一個大而全的系統一拆爲三，容器，發佈，測試都已經獨立出去，可是原始的數據庫仍是一套，如今須要將數據庫作一個拆分，A、B、C三個系統有各自的數據庫以後，咱們的微服務化在現有部署、測試等已經獨立的基礎上纔算最終完成，造成三個各自獨立的單元。所以本篇文章敘述的不是數據庫的水平拆分也不是垂直拆分，不是講述分庫分表，而是講述從業務系統去拆分數據庫，把業務最終微服務化。前端
2、方法
2.一、SOA
經過提供RPC接口，將原先共用的表有一方系統提供接口服務，另外一方系統來調用該接口。這種狀況下系統之間是解耦了，可是數據調用的時候一方仍是要強依賴另外一方。這個時候要從新關注接口服務方若是down掉或者延時發生，須要有容錯機制，好比熔斷、降級等。同時要考慮好數據的託底展現，好比本機緩存，remote緩存。詳細可參看《微服務下的網關與容錯》裏面有專項介紹。mysql
2.二、數據異構
經過數據異構的方式，好比B系統與C系統原來是一張表，數據庫拆分以後這張表的數據放在了C系統，可是B系統只須要這張表的部分字段，這個時候能夠經過異構平臺把C系統的表按需異構到B系統中的一張表。這樣兩個系統之間完全解耦，各自微服務化，也沒有了SOA方式的強依賴問題。關於數據異構的詳細介紹能夠參看這篇文章
《數據異構的武器-BINLOG+MQ》sql
3、拆庫的步驟(mysql)
集羣A(源庫)
集羣B(新搭建)
集羣C(新搭建)數據庫
注意此方案須要停寫！編程
步驟1、搭建集羣B、C
將集羣B、C以從庫形式掛載到集羣A緩存
步驟2、將以下集羣A主庫設置爲只讀模式
192.168.x.x xx.mysql.xxx.com
命令：set global read_only=on;架構
步驟3、待從庫無延遲後，集羣B、C中止複製，執行以下操做
命令：stop slave;
此時A、B、C三套集羣均爲只讀模式框架
步驟4、研發人員修改應用url指向到正確的數據庫集羣，待確認無誤後，（此時可回退，打開寫後不可回退）
通知DBA將集羣A、B、C三套打開讀寫
命令：set global read_only=off;運維
步驟5、拆分完成分佈式
步驟六
觀察一段時間後drop冗餘表，DBA在複製的時候其實是全量複製，所以後續咱們須要drop掉各自系統內不須要的表。能夠用rename的方式先行標出，一段時間後再drop掉。
===================================================================
回退方案
步驟1、集羣B、C打開復制
命令：start slave;
步驟2、打開集羣A的讀寫
命令：set global read_only=on;
4、SOA和微服務
SOA面向服務架構，是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。關鍵點是接口調用，這是目前分佈式系統中經常使用的方法。目前開源的RPC框架也有不少好比知名的DUBBO服務等。
微服務的重點是業務系統要完全組件化和服務化，原有的單體應用系統會拆分爲多個能夠獨立開發、運行、部署和運維的小應用。這些小的應用之間若是須要交互就經過服務來完成，好比提供DUBBO接口服務。每一個小應用內部從前端WEB到業務邏輯處理，到數據庫訪問，以及數據庫都是獨立的。
5、總結
業務簡單，團隊組織規模較小的時候一個單體應用就能夠支持當時的業務發展。隨着業務的發展規模愈來愈大，過程當中若是技術架構升級沒有跟上，就會面臨後期拆系統，拆庫的的階段。本篇文章結合我工做中自身的經歷集中對數據庫的業務拆分作了描述，拆庫的原則以及數據庫新集羣的建立方法。對於拆分，咱們要拆的粒度有多大，或者多小，沒有一個標準，關於這方面，推薦你們閱讀一本書《恰如其分的軟件架構》。
轉載請註明做者及出處，並附上連接http://www.jianshu.com/p/590037e67162