<b>摘要：</b>在2017杭州雲栖大會阿裡雲HTAP技術專場上，上海秦蒼資訊科技有限公司DBA負責人趙懷剛為大家分享了HTPA型資料庫産品在現實中的落地應用以及企業級資料庫架構設計中的HTPA的應用。
<b>本文内容根據嘉賓演講視訊以及PPT整理而成。</b>
本次分享的主題是買單俠資料庫架構之路。秦蒼科技是一家網際網路消費金融公司，我們所有的産品基本都是托管在阿裡雲上的，在自己的系統中大概應用了20多種阿裡雲資料庫産品。基于阿裡雲平台，秦蒼科技的資料庫架構與傳統RDS資料運維相比存在着本質的差別。接下來着重介紹一下在産品公司業務快速發展的情況下，系統資料庫架構的演變曆程。
本次分享的主題主要分為以下四個部分：
一、關于秦蒼科技
二、在業務的快速發展中遇到的問題
三、資料庫架構演變過程和案例分析
四、基于雲資料庫運維的思考
<b>一、關于秦蒼科技</b>
如圖所示的是秦蒼科技的兩個産品，最左邊叫做買單俠，主要針對的是年輕藍領客戶群體，主要提供一些消費場景下的分期金融服務。右邊這個産品主要目标使用者群體是年輕的女性白領，主要為她們提供一些醫療美容的消費分期金融服務。目前秦蒼科技公司的使用者數大概為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以及一些分析的提取都耦合不到一起。
<b>二、在業務的快速發展中遇到的問題</b>
資料庫架構演變的過程當中遇到了很多問題，是以秦蒼科技的所有的技術全部選擇都是在阿裡雲上的，包括了對于資料庫的選擇。使用阿裡雲RDS比較直接的好處就是它可以開箱即用并且可以彈性擴容。随着業務量的增加，可以輕松地更新，比如硬體上的更新，以及外圍輔助的更新，還可以非常友善地實作資料遷移，後來阿裡雲還提供了DTS服務，可以輕松實作異構資料遷移。最初因為設計的問題，所有的資料是放在同一個執行個體庫下，是以當出現比較高的并發時就會導緻執行個體的CPU爆掉，進而導緻資料庫服務不可用。這就是所面臨的問題，也是這兩年時間一直在做的事情——遷移、解耦和拆分。
在這個過程中，我們遇到了異構資料遷移的問題。另外随着公司業務的發展，規模的不斷變大，在整個資料庫運維當中出現了效率上的問題，主要是現在有大量的SQL稽核工作要做，而且有頻繁的生産釋出，而每次釋出都要等到比較晚的時間比如業務的低谷期來釋出。還有一些高頻的資料查詢和變更需求。主要是研發同學需要去定位Bug要擷取一些資料，以上這些就是之前面臨的一些問題。在開始資料規模比較小的時候使用的是比較粗暴的做法也就是人肉支撐。當發展到現在的量級，現在有3個研發中心，300多個研發同學，而DBA隻有四個人，需要從DevOps角度考慮如何去支撐這麼多的使用者。
<b>三、資料庫架構演變過程和案例分析</b>
如圖所示是秦蒼科技最早資料庫的架構設計，是一個比較簡單的單體架構，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裡進一步做分析，進行主動監控，目前我們正在嘗試。
<b>四、基于雲資料庫運維的思考</b>
最後一部分是基于雲資料庫運維的思考。其實将所有的東西放在阿裡雲上使我們的工作發生了本質變化。第一個是工作前置化成為可能，使DBA向DA轉變成為了可能，從之前資料庫運維管理到資料的應用。向資料生命周期管理的方向靠攏是目前一個工作重心，系統有生命周期，資料一樣也應該有生命周期。資料的生命周期從最初的設計到釋出、維護，再到下線。而現在好多資料在設計時沒有考慮它的生命周期，資料很難産生最大價值，如果把一個比較小的系統設計成高并發或者高可用的方案，會造成額外的運維和經濟成本。
我們對整個DBA行業做了分類，大概分為運維DBA、應用DBA以及業務DBA。每個角色的工作重點各不一樣，運維DBA更加偏重于資料庫的安裝和配置、HA高可用、備份容災以及更新擴容等，這些已經被雲做掉了；應用DBA是我們目前所處的階段，主要偏重于資料庫相關技術選型、容量規劃、性能優化和運維自動化等，其實阿裡雲也在将該部分工作實作自動化和智能化，包括CloudDBA、DMS、DTS等外圍增值服務,推動我們從應用DBA轉向業務DBA。目前我們也在向這方面去靠攏和思考，後面的工作重心會更多地放在資料庫的架構以及資料的應用上，讓資料産生更多的價值，為業務提供資料支援。
下圖是秦蒼科技的技術公衆号，上面會定期公布一些技術文章，感興趣的同學可以關注一下。