一．背景
為了適應業務增長,數據庫數據量快速增長，性能日趨下降，穩定性不佳的實際情況，急需架構逐步演變適應未來的業務發展。
二．現狀
【穩定性】數據庫為單點，沒有高可用和穩定性方案。
【數據量大】數據庫目前400G左右，每個月大約100G的增量；
單表數據只增不刪，數據持續增長;
【業務優化，剝離難】業務比較復雜，單純的業務梳理剝離和優化，涉及業務方溝通及方案確立周期太長;
【查詢慢】單機性能已出現過cpu瓶頸導致響應緩慢，大量的慢查詢。
三．架構升級方案概要
數據庫架構演變順序:
1) 大表表級拆分多表方案【風險:中 效果:不會特別明顯】
優點:通過拆分大表，拆分冷熱數據，從而減少單表的數據掃描，進而優化數據庫性能。
缺點:只能緩解大表的數據增量，但是不能徹底解決快速增長數據的本質問題。以目前的業務增量，即便做了冷熱數據分離，也最多多支持幾個月時間。
總結:只能緩解增量的症狀[避免全表掃描的不必要的數據篩選]，但不能解決本質問題。
2) UUID轉int方案【風險:高 效果:應該比較明顯】
優點:保守估計性能大約有6倍左右的提升（連表操作），索引及內存存儲量降低為原來的1/4左右，表大小，數據庫大小都會有相應的減少。
缺點:現有的數據庫太大約400g，整體遷移過程和步驟相對非常復雜，需要自行通過編碼實現遷移，難度很高。
總結:在cpu運算上和內存上會有明顯優化，但是解決不了數據量（磁盤）本質問題。
3) 用戶維度拆分方案【風險:高 效果:最好】
優點:通過用戶維度拆分多個用戶庫和主庫（這里的主庫不一定是一個庫，也可以是垂直拆分的多庫），從而分散數據量，增加多個表和庫鎖的粒度，數據庫的連接池，硬件資源等；用戶維度性能提升n倍,主庫可以通過讀寫分離提升性能；足夠業務n年的數據發展和平滑擴展。
缺點:拆分多庫，可用性和服務器穩定性下降（但是理論上出問題僅影響部分用戶，可以保證總體可用性不會降低）。后期維護索引和更新，運維工作量加大多倍。業務代碼基本大部分稍微調整（需要選擇分庫），部分業務代碼需要分布式事務支持（基本現有代碼的所有一致性事務需要調整）。
總結:全維度（cpu，內存，磁盤）優化數據庫，較徹底解決數據庫平行擴展和性能問題（除主庫外）。相應的業務運維和運營的工作量加大和調整，但外圍業務用戶基本無感知架構變化。
4) 業務降低事務化方案【風險:中，效果：高並發下面效果好】
優點:通過降低事務等級，減少讀共享鎖，避免部分業務更新操作的阻塞；從而提升並發處理的性能（類似java讀寫鎖原理，現在讓數據庫讀不加鎖或者部分加鎖）。
缺點:部分數據會出現臟讀（但是用戶基本無感知）(資金財務相關的不得降低事務等級),但去鎖並不會加快單條數據查詢的速度。業務代碼基本大部分需要根據業務場景，進行細粒度的事務等級控制（原則上一些查詢校驗，能不用事務就不用事務；大塊事務盡量拆開多個事務；能通過Tcc或者最終一致性的業務冪等解決就不用強事務）（類似java方法級的鎖，修改成方法內的多條代碼級鎖，減少鎖粒度，保證盡快釋放事務和鎖）。
總結:有效的降低鎖競爭導致的阻塞問題，能夠有效提升業務高並發下面的總體並發能力，但是對無高並發下面的單筆業務處理耗時不會有明顯提升，同時業務代碼改動和梳理時間略費時間，但可根據情況自行取舍。mysql和sqlserver事務鎖處理可能略有不同，但是總體降低事務等級思路不變。
5) 數據庫讀寫分離方案【風險:中 效果:比較好】
優點:基於用戶維度拆分后，特別是針對主庫進行讀寫分離（根據用戶維度讀指定的讀庫）; 將一些報表性查詢，根據業務的實際情況選擇讀庫或者寫庫(再加上低事務等級)，極大的提升數據庫的性能（主庫中一些全局的配置可以做讀寫分離，用戶維度考慮硬件層面讀備熱切換和讀寫分離）。
缺點:需要代碼級別支持讀庫宕機，移除節點，平滑故障（需要分庫分表中間件支持配置中心和數據庫故障檢測信息打通，自動故障轉移）。要梳理業務邏輯，使一部分業務代碼的查詢切換到讀庫。
總結:讀寫分離主要解決用戶維度拆分后，主庫的讀壓力(也可以部分分布式緩存解決)和穩定性。從二八理論上講，能分擔大部分的性能到從庫，但是從庫會有數據延遲的可能性，故在業務讀寫分離處理時需考慮。
6) 絕對低耦合(獨立性)服務數據庫垂直拆分【風險:中 效果：未知】
優點:低耦合的服務化數據庫拆分成獨立服務或者功能，此服務化數據庫又可以按照多維和技術特性進行更細粒度的服務化拆分和高性能，可以提供服務復用性和獨立穩定性規划。進一步降低業務數據量，提高業務的純性能。（一般獨立服務拆分有個特點: 要么是共性業務，要么不帶業務屬性的功能，而且這種服務數據量不少或穩定性要求極高）
缺點:未來業務確保不會出現耦合度粘性的發展，細粒度服務會更多，但是開發穩定后一般不會更改。
總結:只拆絕對低耦合的業務為服務(如沒把握，寧可不拆)
四．架構簡單示意圖
by 車江毅