640
雲棲大會分享：買單俠的數據庫架構之路
互聯網金融行業快速發展的浪潮中，麵對海量增長的數據，買單俠走出了自己的數據庫架構之路。
本文是買單俠DBA負責人趙懷剛在杭州雲棲大會上的分享，介紹了數據庫運維中遇到的問題、基於阿裏雲平台數據庫架構的演變和案例和雲數據庫運維的思考。
圖1 趙懷剛在分享
秦蒼科技是一家專注於為年輕人提供消費分期服務互聯網消費金融公司，目前有“買單俠”和“星計劃”係列產品，“買單俠”麵向中國年輕藍領用戶，提供移動端消費分期服務。“星計劃”為年輕女性用戶提供醫療美容的消費金融服務。
我們目前有數百萬用戶，日活在百萬以上，每月新增20萬用戶，增長速度快。
消費金融區別於電商，電商重在庫存管理和物流，而分期業務則更偏重於風控。因為有主動借款需求的用戶信用度較差，買單俠獲客的渠道偏於跟線下手機門店合作。
圖2 買單俠數據庫的發展
互聯網金融行業發展速度很快，買單俠從2014年3月成立到現在三年半時間，數據庫的規模和數量級也在不斷的增長。
目前生產中的數據庫實例已經達到200+，DB數量達到了400+，在線數據量在3TB左右（不包含歸檔曆史數據）。
買單俠的技術棧
買單俠後台技術采用的是基於 SpringCloud Netflix + Node.js的微服務架構。
服務部署采用的是阿裏雲的容器服務，目前微服務數量達到了400+，大部分核心業務已容器化。
目前生產中使用了SQL Server、MySQL等關係型數據庫，緩存采用的是Redis，另外一些數據源和第三方的數據采用的是MongoDB存儲。
風控技術上有自研抱團算法，風控決策模型可以協助區分好人和壞人，底層使用的是一組圖數據庫neo4j的集群，生產持久層90%以上是以MySQL為主。
因為最早的技術棧是.net& SQL Server，還有少部分的SQL Server在使用。
發展中遇到的問題
DBA屬於運維的一種，買單俠的DBA屬於大的運維部門，也是把腦袋拴在別人褲腰帶上幹活的。
要對生產穩定負責，功勞難量化，有鍋就得背，但這也體現了我們的專業性。
即使經常會看到上海陸家嘴的日出，但我們也有自己的目標：
不僅要活著，更要活得好。我們還要有理想，萬一實現了呢？
說到這肯定會有人要問，數據庫服務都托管到阿裏雲上，你們DBA每天還要幹什麼呢？
其實我們也一直在思考這個問題，怎樣才能順應時代的發展，完成個人和DBA工作的升級迭代。
我們的係統最早是單體架構數據庫層全部耦合在一起，數據存放在一個實例一個庫下麵，數據庫服務的可用性沒辦法保證。
在服務改造和拆分過程中同樣存在大量的數據遷移，包括大量的異構數據遷移等。
隨著公司業務快速發展和數據量增加，DBA麵臨大量的數據運維工作，如SQL腳本審核、頻繁的生產發布以及在安全的前提下滿足生產數據查詢和變更等需求。
隨著阿裏雲數據庫產品的不斷完善和升級迭代，怎樣結合公司業務很好的集成應用將成為我們工作的重點。
架構演變和案例
最早的架構
最早的架構比較簡單，是All in one的單體架構，沒有緩存層，所有請求直接訪問持久層，在公司初期階段能滿足當時的業務需求。
但隨著業務量的增加問題不斷的暴露出來，一個慢SQL導致實例CPU飆高而使所有的數據庫服務不可用，數據庫架構升級迫在眉睫。
為了解決這個問題，接下來我們完成了數據庫的拆分和代碼的解耦，先是縱向拆分，迫不得已再橫向拆分。
圖3 分組分層的架構
數據庫架構的主體設計思路是：分組分層、分而治之。
首先從業務需求特征出發進行數據分類，劃分主題域，根據主題域分層，分層的本質是職責的分離，讓每層更清晰並且獲得更好的伸縮性。
然後從較高的層次對業務數據進行的抽象、歸納，也就是分組（邏輯組）。
因為微服務粒度太細對數據庫的管理會是很大的挑戰，我們跟後台微服務架構做好映射，但不是一一映射。
我們最終劃分了四個層次，分別為業務線層、平台功能層、路由管理層和第三方交互層。
每個層次包含多個邏輯組，例如每個產品線可以定義為一個邏輯組，每個邏輯組會根據功能模塊垂直拆分為多個物理實例。
例如有信貸核心平台組，下麵會包含賬務、賬戶、借據和交易等功能模塊，每個模塊分散到不同的物理實例，相互間不會產生影響。
個別業務數據量大的實例根據業務鍵的哈希算法進行水平拆分。業務數據通過垂直和水平拆分後全部打散部署。
中間的架構
在分組分層垂直拆分的基礎上，我們增加了Redis作為緩存層，儲存一些數據量小但是訪問頻率很高的數據，比如字典服務、產品配置、費率等相關數據。
圖4 中間的架構
跟之前的單體架構相比，除了增加緩存層和架構上垂直拆分打散部署外，部分業務還增加從庫實現讀寫分離和負載均衡。
現在的架構
隨著業務發展和微服務化的推進，發現服務層做了很好的管控，但數據層並沒有區分，運營和生產做單等還是訪問同一份數據。
於是我們根據業務重要性把數據庫分為了兩類，一個是小核心的做單係統，一個是非做單係統的大外圍，也就是瘦核心的思想。
跟上麵中間架構的區別主要有三點：
圖5 現在的架構
1.增加了一個數據集成區或者叫數據交換平台，是一個數據交換的樞紐，實現核心業務係統與外圍係統間的數據交換。
上麵這個OLTP定義為小核心層提供聯機實時、小數據量的數據服務，保證核心業務服務請求做到實時快速的響應。
數據交換平台層提供批量、大數據量、準實時的數據服務，為運營和準實時數據分析提供數據支持。
舉個例子，如放款服務要依賴於審核服務，要等到審核返回結果後才能繼續處理，這種實時性要求高而且報文不大的可以走OLTP小核心層。
如果對實時性要求不高，可以準實時傳送、數據量又比較大的就走數據交換平台，如每天的對賬業務、運營平台查詢和大數據平台的對接等業務場景。
數據交換平台是一個大的數據資源池，必須滿足兩點要求：一個是要能夠足夠的大，而且能夠很好的水平擴展，第二要兼容MySQL協議。
HybridDB 是阿裏雲自研的數據庫產品，同時支持海量數據在線事務（OLTP）和在線分析（OLAP）的混合型分布式關係型數據庫，高度兼容SQL，支持海量數據，類似於AWS的Redshift，結合阿裏雲的DTS服務可以完全滿足我們的架構需求。
2.對大數據回流數據做了規範化和集中管控，之前是直接回推到生產各個OLTP實例，做法也比較暴力，直接truncate後全量插入，問題是比較分散而且容易對已有實例產生影響。
我們對所有回流數據進行梳理，把所有回流數據當做是其中一個數據集市，不同業務服務所需數據對應到不同的庫和賬號存放在同一個數據集市，采取增量推送模式，同時要求線上業務服務做好容錯機製，如果推送失敗後做好處理避免產生強依賴。
3.引入了DMS數據管理工具，用戶可以通過DMS直接訪問數據交換平台，在安全、穩定的前提下可以滿足研發對生產數據的自助訪問，而且支持數據變更和SQL審核，為數據庫運維提供了一站式的DevOps解決方案，可以釋放DBA做更有價值的業務模型和架構設計。
如何進行數據遷移？
圖6 分表分庫案例
微服務分布式架構演變過程中少不了數據遷移，數據遷移必然會涉及到對老模型分析、新模型設計以及新老模型之間的映射和轉碼等問題，所以遷移之前要做好充分準備。
首先要製定遷移總體方案，包括遷移準備、實施步驟、關鍵點控製、應急預案等。
我們核心賬務係統的迭代過程分三步：
1.代碼做服務化數據庫層不做變動，從單體架構中拆分到獨立的數據庫實例。
2.將數據庫從SQLServer遷移到MySQL並實現讀寫分離。
3.使用DRDS實現對大表的切分，解決了單表數據量大的問題。
右邊虛線框內為第三步Sharding的預案，使用阿裏雲DTS的數據遷移先把RDS數據實時同步到DRDS，借助DTS訂閱和補償機製實現對DRDS Sharding 後數據的匯總實現上線後的應急預案。
而且這兩個操作都可以在線提前執行，服務上線時隻是做個配置變更和重啟秒級完成，大大縮減了停機時間。
如何部署？
圖7 數據運維Pipeline
SQL腳本的部署借鑒了係統發布的思路，首先要有個思維上的轉變，把SQL當做是代碼的一部分來運維（這裏主要是指發布的DDL&DML SQL），即SQL ascode，從最初的數據庫設計到審核到發布和優化看做是SQL 運維的pipeline。
研發設計好數據庫後，會提交一個SQLrequest到gitlab代碼倉庫，DBA收到請求後做腳本的審核，通過後會把SQL代碼merge到release分支（隻能DBA merge）。
未通過的SQL DBA會備注審核建議後駁回到研發進行調整，調整後繼續走剛才審核流程。
上線發布時我們采用了flyway，實現自動部署和以及跟代碼發布的集成，上線相關DDL/DML的SQL會被當做代碼推送到代碼倉庫，代碼部署完成服務啟動時會檢查本次變更是否存在SQL腳本，有的話就執行沒有就跳過。
flyway具備版本控製、rollback機製，因為數據庫是有狀態的服務，我們沒使用這些功能。
如果執行過程中報錯或失敗，將不再啟動服務人工介入排查。數據庫發布和代碼部署做了很好的集成，這樣提高了數據庫運維和發布效率，跟上互聯網快速發展的節奏。
上線後的優化中，主要是慢SQL的管理分為兩類，一類是索引類由DBA後台空窗期維護，另一類是SQL需改寫通過Bug管理流程進行跟蹤，這樣整個數據庫的運維從設計-審核-發布-優化完成了閉環。
上麵流程中SQL審核還是人工執行，肯定會存在瓶頸。
最初我們想做一個類似於代碼檢測或掃描的工具：SQL Scan，可以基於預先定義好的規則進行SQL自動發現並審核，審核有問題的SQL再拋出來給DBA確認，這樣可以節省80%以上的審核時間。
後來我們發現阿裏雲的DMS已具備類似功能，目前正在跟DMS做研發流程上的集成，也算是基於雲端DevOps的快速實現。
數據庫的監控
數據庫的監控分為兩個部分：基礎資源監控和數據監控。
基礎資源監控主要借助阿裏雲監控實現，包括對CPU、磁盤、IOPS、QPS/TPS等常規指標監控，報警方式支持短信、郵件和集成釘釘通知。
數據監控我們主要借助Zabbix對數據庫的業務數據進行探測，發現異常後上報到靈犀報警。
靈犀報警是一個第三方監控平台，支持電話報警，緊急事件可以打電話給第一責任人處理，並且支持報警升級，第一責任人未響應的情況下會繼續上報到backup人員，確保報警得到盡快解決。
另外阿裏雲的監控存在兩個問題，一個是跨度周期長的監控數據會被平均化，很難定位到當時的負載和問題，二是有固定的保留期限，很難查到半年前的監控曆史數據。
而且上麵兩種監控都屬於事中監控，事前監控現在比較傳統主要靠DBA主動優化和巡檢提前發現並解決。
阿裏雲的RDS有對所有監控提供API，能夠通過API獲取到監控數據明細，導入到ELK等做進一步的處理和分析，算是大數據應用在數據庫監控的場景，目前在嚐試。
AI會取代DBA麼？雲數據庫運維的思考
最近Oracle的OOW大會有提出一個新的名詞：自治數據庫，把18c定位為可以自動駕駛的自治數據庫，結合機器學習實現了自我管理、自我調節、自我安全和自我修複等功能。
目前阿裏雲已有16種數據庫產品，最近阿裏雲也有發布CloudDBA、PolarDB，而且我們所有的數據庫都托管在阿裏雲上。
雲最大的好處是開箱即用和彈性伸縮，基礎運維的工作基本已被取代，再加上CloudDBA、DTS、DMS等DevOps把雲端整個數據庫運維打通，形成了閉環。
在雲端不需要開發運維就可以快速實現運維的自動化和智能化，感覺我們的末日就要來了。
但仔細想想AI要完全取代DBA的工作，其實還需要漫長的過程。就好像自動駕駛技術落地一樣。
DBA的工作進化
基於雲平台，我們的工作也發生了很大的變化，雲使工作前置化成為可能，使DBA轉向DA成為可能，從底層運維轉向結合業務場景的數據庫設計，從數據庫管理轉向數據管理和數據應用。
我們目前要求DBA也要參加架構評審，從項目開始便了解業務，多與產品和研發溝通，搞清楚業務的商業價值和後台技術實現，站在DBA的視角給出與數據設計相關的建議，這也是DBA工作前置化的表現，變被動為主動。
DBA主動了解數據庫以外的知識，了解業務、平台、雲等，這樣才能在眾多選擇中做好合理規劃而不至於迷失，完成從DBA到DA的轉型。
數據庫生命周期管理
站在產品的角度看每個係統都是有生命周期的，數據也是一樣，未來會發展成什麼樣子？
將一個在其生命周期內不會產生高並發和大數據量的數據庫，設計成高並發和水平擴展的架構，這種行為就是在耍流氓。
圖8 數據生命周期管理
要充分考慮到數據架構是否對當前業務支持。過度或不合理的設計會帶來額外的運維和經濟成本。
所以我們認為數據生命周期管理將會成為DBA未來工作的重點，DBA將圍繞數據展開工作。
這就要求我們站在係統或產品運營的角度來看待數據運維，這將是一件非常有意義的事情。對於數據的設計我們看做是產品的迭代一樣，采用IPO（input-process-output）的方式，數據從輸入-處理-輸出完成整個生命周期迭代。
思考和總結
梳理下DBA的工作可以分為：運維DBA、應用DBA和業務DBA。
每一個角色的工作重點各不一樣，運維DBA更加偏重於數據庫的安裝和配置、HA高可用、備份容災以及升級擴容等。
圖9 思考和總結
應用DBA是我們當前所處的階段，主要偏重於數據庫相關技術選型、容量規劃、性能優化和運維自動化等。
其實阿裏雲也在將該部分工作實現自動化和智能化，包括CloudDBA、DMS、DTS等外圍增值服務。
隨著雲產品的不斷完善和數據庫技術的快速發展，會向業務DBA發展，注重於結合業務場景的數據庫設計，數據管理和數據應用，用數據來驅動業務為企業創造更大價值。
最後更新：2017-10-27 20:03:45