894
阿裏雲 技術社區[雲棲]
買單俠數據庫架構之路
摘要：在2017杭州雲棲大會阿裏雲HTAP技術專場上，上海秦蒼信息科技有限公司DBA負責人趙懷剛為大家分享了HTPA型數據庫產品在現實中的落地應用以及企業級數據庫架構設計中的HTPA的應用。
本文內容根據嘉賓演講視頻以及PPT整理而成。
本次分享的主題是買單俠數據庫架構之路。秦蒼科技是一家互聯網消費金融公司，我們所有的產品基本都是托管在阿裏雲上的，在自己的係統中大概應用了20多種阿裏雲數據庫產品。基於阿裏雲平台，秦蒼科技的數據庫架構與傳統RDS數據運維相比存在著本質的區別。接下來著重介紹一下在產品公司業務快速發展的情況下，係統數據庫架構的演變曆程。
本次分享的主題主要分為以下四個部分：
一、關於秦蒼科技
二、在業務的快速發展中遇到的問題
三、數據庫架構演變過程和案例分析
四、基於雲數據庫運維的思考
一、關於秦蒼科技
如圖所示的是秦蒼科技的兩個產品，最左邊叫做買單俠，主要針對的是年輕藍領客戶群體，主要提供一些消費場景下的分期金融服務。右邊這個產品主要目標用戶群體是年輕的女性白領，主要為她們提供一些醫療美容的消費分期金融服務。目前秦蒼科技公司的用戶數大概為400多萬，每個月新增大概20萬用戶，每天日活用戶大概是在百萬左右。秦蒼科技目前做單的模式並沒有完全放在線上，還是偏傳統一點，會與線下的手機門店、醫院、電動車銷售商等這些商家合作，通過線下入口而不是直接通過APP進行操作，所以可以說秦蒼科技的商業模式還是比較偏傳統的。
如圖所示的是秦蒼科技的技術棧，主要是用的後台技術是基於Spring Cloud的微服務架構，部署則采用的是Docker技術，當然用的也是阿裏雲的容器服務。
秦蒼科技公司成立於2014年3月，到現在大概經曆了三年半的時間，目前大概遍布了全國的300個城市。係統最開始的數據庫是單體架構的，所有東西都放到一起。而現在數據庫有將近200個，並且對於數據庫也做了拆分，目前線上的數據量已經達到了3 TB。
目前所使用的數據庫架構主要采用了阿裏雲RDS。秦蒼科技所處的是一個互金行業，所以會從一些第三方數據源那裏拿數據，並與資方做交互。這些數據的變更可能比較頻繁，需要依賴於第三方。對於這些數據而言，我們采取MongoDB進行存儲，緩存層采用阿裏雲的Redis，總體而言都是采用阿裏雲RDS服務。
互金行業核心就是風控，秦蒼科技自研了一個風控模型，這個模型叫做抱團算法，接下來大概簡單介紹一下它的實現。什麼是抱團呢？比如你的身邊有十個朋友，如果十個朋友當中有八個朋友信用都存在問題，或者之前發生過借貸關係，但信用不是太好，就會認為你這個人有可能信用上存在問題。這個風控模型的後台采用的是neo4j圖數據庫集群，目前RDS的規模大概在150個MySQL、20多個MongoDB以及20個Redis。剛開始的時候采取.Net + SQL server構建的，後來把數據從SQL server遷移到了MySQL，這是因為在使用SQL server的過程當中遇到很多問題，SQL server目前不支持隻讀實例，在擴展性和靈活性上對業務造成了很大困擾。因為數據中心需要做數據分析，要從線上取數據，這樣OLTP以及一些分析的提取都耦合不到一起。
二、在業務的快速發展中遇到的問題
數據庫架構演變的過程當中遇到了很多問題，所以秦蒼科技的所有的技術全部選擇都是在阿裏雲上的，包括了對於數據庫的選擇。使用阿裏雲RDS比較直接的好處就是它可以開箱即用並且可以彈性擴容。隨著業務量的增加，可以輕鬆地升級，比如硬件上的升級，以及外圍輔助的升級，還可以非常方便地實現數據遷移，後來阿裏雲還提供了DTS服務，可以輕鬆實現異構數據遷移。最初因為設計的問題，所有的數據是放在同一個實例庫下，所以當出現比較高的並發時就會導致實例的CPU爆掉，進而導致數據庫服務不可用。這就是所麵臨的問題，也是這兩年時間一直在做的事情——遷移、解耦和拆分。
在這個過程中，我們遇到了異構數據遷移的問題。另外隨著公司業務的發展，規模的不斷變大，在整個數據庫運維當中出現了效率上的問題，主要是現在有大量的SQL審核工作要做，而且有頻繁的生產發布，而每次發布都要等到比較晚的時間比如業務的低穀期來發布。還有一些高頻的數據查詢和變更需求。主要是研發同學需要去定位Bug要獲取一些數據，以上這些就是之前麵臨的一些問題。在開始數據規模比較小的時候使用的是比較粗暴的做法也就是人肉支撐。當發展到現在的量級，現在有3個研發中心，300多個研發同學，而DBA隻有四個人，需要從DevOps角度考慮如何去支撐這麼多的用戶。
三、數據庫架構演變過程和案例分析
如圖所示是秦蒼科技最早數據庫的架構設計，是一個比較簡單的單體架構，all in one，所有數據全部放在一個庫裏，可能有好幾百張表。而且隨著數據量的增加，OLTP都達到千萬級，對於數據可用性就沒法保障了。隨著業務的發展，後台服務要進行微服務化架構，進行服務改造。數據庫應該盡量配合後台進行微服務化的改造，這是需要思考的問題。如何進行微服務拆分呢？後來數據庫團隊也是在不斷地摸索和思考這個問題，最後總結出拆分的大致思路，就是采取分組分層的方法，對於整個數據庫進行架構的調整。
分層就是根據業務的需求特征進行分類劃分主題域，這有點像數倉分析建模的概念。我們會將數據庫分成不同的層次，比如可以根據需求特征分為業務、平台等層次。分組就是對主題域數據進行進一步抽象和歸納，可以抽象出來很多的邏輯組，並將邏輯組再根據具體的功能模塊進一步做拆分，這可能會包含多個實例或者多個庫。而針對一些業務量特別大的場景，也有使用阿裏雲DRDS實現水平的分表分庫方案。
在分組分層時，為了節省資源和方便管理，我們做了一個小技巧，就是把不同的數據庫暫時放在同一個實例上，但數據庫的賬號卻是完全隔離的，這個賬號隻擁有訪問某些數據庫的權限。剛開始時業務量比較小，所以基於成本的考慮會放到一起。隨著業務量的增加，如果出現性能問題，就可以基於阿裏雲DTS數據遷移服務，把數據拆分開遷入到性能比較好的實例上去。
基於上麵分組分層的思想，出現了一個中間的過渡架構，這個架構也沒有什麼特別的，主要跟之前單體架構相比多了一個緩存層。之前的SQL Server不支持讀寫分離，全部遷入到MySQL之後就做了讀寫分離，來滿足業務上讀負載的瓶頸。再看一下如下圖所示的現在的架構。根據業務的重要性，把整個係統分為兩類，核心係統和外圍係統。核心係統就是做單的係統，相當於大家到淘寶買東西，用戶從商品選擇到最後下單，整個流程走完是一個訂單核心的係統。剩下的非做單係統，也就是大外圍的係統。後台架構采用了分布式的微服務架構，服務的拆分粒度也比較細，但是這樣也會遇到一些問題。
現在線上做單數據調用的服務，也會被用於分析的運營支撐係統調用，取用戶訂單相關信息要調多個服務，才能滿足運營或分析的需求。這樣，做單係統和運營支撐係統訪問，數據層是耦合到一起的。於是，又找了一個折中的方法。這個折中的方法，就是選擇HybirdDB，它就相當於一個大數據資源池，於是增加了Hybird DB作為數據的交換平台，主要提供核心係統和外圍係統數據交換，內部叫做數據交換平台。
數據交換平台會把所有線上數據進行匯總，這樣一些外圍係統或者非實時請求就可以通過訪問數據交換平台獲取數據，這樣其實對於數據交換平台提出了很大的要求：首先這個平台需要足夠的大，因為現在線上數據也有3 TB，RDS實例本身沒法支撐到這麼大的數據量。第二，要能夠很好地進行水平拆分和擴展。此外，還要完全兼容MySQL的協議。於是我們選擇了HybirdDB，它解決了大的數據資源池問題。
我們同時引入了阿裏運數據管理的工具——DMS，主要解決了線上實時數據的查詢問題，能夠做到安全的管控。另外對大數據平台計算之後的數據也做了集中的管控，可以為線上提供一些數據支撐。
微服務分布式架構演變過程中少不了數據遷移，數據遷移必然會涉及到對老模型分析、新模型設計以及新老模型之間的映射和轉碼等問題，所以遷移之前要做好充分準備。首先要製定遷移總體方案，包括遷移準備、實施步驟、關鍵點控製、應急預案等。我們借助阿裏雲DRDS中間件實現對核心表的水平拆分，圖中的虛線部分是預案，因為屬於核心的係統，這裏不能有太多停機時間，需要保證數據同步。在上線過程當中，借助阿裏雲DTS數據遷移和訂閱服務大大降低了停機時間並實現了應急預案。
如圖所示的是數據庫的自動化部署。SQL腳本的部署借鑒了係統發布的思路，首先要有個思維上的轉變，把SQL當做是代碼的一部分來運維，即：SQL as code；研發設計好數據庫後，會提交一個SQL request到gitlab代碼倉庫，DBA收到請求後做腳本的審核，通過後會把SQL代碼merge到release分支（隻能DBA merge），未通過的SQL DBA會備注審核建議後駁回到研發進行調整，調整後繼續走剛才審核流程。數據庫發布我們采用的是flyway，在部署服務時，首先會檢測本次上線發布是否有數據庫的變更，如果有的話就去執行，沒有就跳過。如果在執行過程當中報錯或者有問題，就會通知運維進行處理，但是這種機率很小，99%以上都會成功。目前阿裏雲DMS實現了一些自主化審核的功能，基於定義好的規範、規則進行自動化的審核，這樣就可以把上麵對人依賴的點解決掉。
如圖所示的是我們的監控，主要分為兩個部分：對於基礎資源的監控和數據的監控。基礎資源的監控，是借助阿裏雲的監控實現的。阿裏雲的雲監控支持短信、郵件等方式，但是不支持電話報警，所以我們又開發了自己一套電話報警機製。數據監控我們主要借助Zabbix對數據庫的業務數據進行探測，如果發現異常之後會上報到電話報警平台，其也是一個第三方監控平台，它會電話通知到第一責任人。而且這個電話報警支持報警升級，如果接聽人沒有處理，就會打電話給負責人，使問題得到解決。上麵兩種監控都屬於事中監控，事前監控現在比較傳統主要靠DBA主動優化和巡檢提前發現並解決。因為RDS會提供豐富的API，目前所有數據都可以通過API獲取到，把這些數據丟到HybirdDB裏進一步做分析，進行主動監控，目前我們正在嚐試。
四、基於雲數據庫運維的思考
最後一部分是基於雲數據庫運維的思考。其實將所有的東西放在阿裏雲上使我們的工作發生了本質變化。第一個是工作前置化成為可能，使DBA向DA轉變成為了可能，從之前數據庫運維管理到數據的應用。向數據生命周期管理的方向靠攏是目前一個工作重心，係統有生命周期，數據一樣也應該有生命周期。數據的生命周期從最初的設計到發布、維護，再到下線。而現在好多數據在設計時沒有考慮它的生命周期，數據很難產生最大價值，如果把一個比較小的係統設計成高並發或者高可用的方案，會造成額外的運維和經濟成本。
我們對整個DBA行業做了分類，大概分為運維DBA、應用DBA以及業務DBA。每個角色的工作重點各不一樣，運維DBA更加偏重於數據庫的安裝和配置、HA高可用、備份容災以及升級擴容等，這些已經被雲做掉了；應用DBA是我們當前所處的階段，主要偏重於數據庫相關技術選型、容量規劃、性能優化和運維自動化等，其實阿裏雲也在將該部分工作實現自動化和智能化，包括CloudDBA、DMS、DTS等外圍增值服務,推動我們從應用DBA轉向業務DBA。目前我們也在向這方麵去靠攏和思考，後麵的工作重心會更多地放在數據庫的架構以及數據的應用上，讓數據產生更多的價值，為業務提供數據支持。
下圖是秦蒼科技的技術公眾號，上麵會定期公布一些技術文章，感興趣的同學可以關注一下。
最後更新：2017-11-02 19:33:42
