網際網路金融行業快速發展的浪潮中，面對海量增長的資料，買單俠走出了自己的資料庫架構之路。
本文是買單俠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等做進一步的處理和分析，算是大資料應用在資料庫監控的場景，目前在嘗試。
最近Oracle的OOW大會有提出一個新的名詞：自治資料庫，把18c定位為可以自動駕駛的自治資料庫，結合機器學習實作了自我管理、自我調節、自我安全和自我修複等功能。
目前阿裡雲已有16種資料庫産品，最近阿裡雲也有釋出CloudDBA、PolarDB，而且我們所有的資料庫都托管在阿裡雲上。
雲最大的好處是開箱即用和彈性伸縮，基礎運維的工作基本已被取代，再加上CloudDBA、DTS、DMS等DevOps把雲端整個資料庫運維打通，形成了閉環。
在雲端不需要開發運維就可以快速實作運維的自動化和智能化，感覺我們的末日就要來了。
但仔細想想AI要完全取代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發展，注重于結合業務場景的資料庫設計，資料管理和資料應用，用資料來驅動業務為企業創造更大價值。