摘要：本次阿里云云棲社區行業圓桌論壇上，趣店集團總架構師徐章健與阿里雲數據庫產品經理王義成共同探討了趣店集團上雲實踐之路，並且分享了趣店集團對於數據庫層面的思考的實踐和在基礎架構設計上的經驗，以及趣店對於消費金融風控的思索和探索。對話行業大咖，引領雲端科技，暢談雲上話題，盡在阿里云云棲社區行業圓桌論壇。
以下內容根據阿里雲行業圓桌論壇視頻整理而成。
本期嘉賓介紹：
徐章健，趣店集團總架構師；
王義成，阿里雲數據庫產品經理。
首先，徐章健簡單介紹了趣店集團的基本業務情況，趣店集團是2014年3月份成立的，前身是趣分期，在2016年趣分期正式升級為趣店集團。趣店集團目前整體業務分為兩大部分:來分期和趣店，提供現金和實物分期這兩種服務。總體而言，趣店集團屬於消費金融行業。
上雲之路
對於像趣店這樣消費金融類的平臺而言，在上雲的過程中以及在選擇雲計算服務提供商的時候，在基礎架構的設計層面，考慮到的出發點有哪些呢？
徐章健談到趣店集團的產品從一開始就是構建在雲上的，其實在剛開始上雲的時候，趣店的確調研了很多的雲服務提供商，最終選擇阿里雲是基於如下幾個方面的考慮：
- 服務的能力、可靠性以及穩定性，對於任何一個企業或者是創業團隊而言，這都是被看重的方面。
- 基礎組件或者說是基礎的服務能力，這裡麵包括核心的RDS數據庫支持，Redis以及MQ等等這些服務。這些服務可能有的雲廠商能夠提供，但是很多廠商卻不能。而阿里雲擁有這一系列非常豐富的產品，其基礎組件的產品線也非常完善。對於像趣店這樣的創業團隊而言，初期最需要關注的是業務的發展，可能沒有太多的人力、物力和財力去做基礎架構，這時如果雲服務提供商能夠為創業團隊提供更多的基礎服務的保障，當然會被優先選擇。
- 市場評價或者說是口碑，趣店也非常看重阿里雲的口碑，這一點也是值得創業團隊關注的。
所以趣店最終選擇阿里雲其實是對於服務能力、基礎組件以及市場評價這樣的幾個指標進行綜合性評定之後做出的選擇。
趣店作為消費金融類的平臺，在上雲過程中，有沒有政策方面的特殊限制呢？
徐章健談到從這一點來講，趣店的確和其他互聯網公司不完全一樣，因為趣店屬於消費金融行業。在數據層面，首先消費金融行業對於數據的安全性要求是非常高的；其次，金融監管上存在著兩地三中心容災這樣的要求，這一部分與其他互聯網公司是不同的。
趣店集團的上雲之路，其實是從2014年3月份開始創業時就開始的。在剛開始的時候，團隊也沒有太多的考慮，因為自建IDC肯定是不現實的，因為對於任何創業團隊而言，購買硬件以及各種運維的成本都將是一筆不小的開銷，所以趣店在開始時的技術方向就是基於雲的。
這時候問題就出現了，就是應該選擇哪家雲計算服務提供商以及應該選用雲上的哪些服務。正如之前所提到的，無論從趣店調研的結果來說，還是對於雲計算服務提供商進行的對比來說也好，在進行綜合的評定之後，在初期就選擇了阿里雲的ECS作為最基礎的服務。趣店的產品是基於LAMP架構設計的，使用PHP進行開發，後端所使用的Redis和RDS也是非常核心的部分，所以一些核心的數據在最開始也就是在使用阿里雲的RDS進行存儲。
隨著趣店業務的發展，就不斷地會有一些更大的挑戰和新的需求出現。因為架構設計已經在雲上了，此時就需要開始思考如何通過阿里雲幫助企業將業務推動得更快，所以在這個過程中趣店就使用了阿里雲很多其他的服務，比如使用Cache進行加速，使用MQ服務進行解耦以及進行異步化等等，在這個過程中，阿里雲的各個產品線和服務是逐步地被趣店的產品使用起來的。
從整個過程來看，可以說趣店對於阿里雲存在著一個比較深的合作關係。只要有需求一來，技術團隊首先會去思考阿里雲有沒有這樣的服務，有的話就會去採用。徐章健談到對於創業團隊而言，創業項目從0到1的這個過程一定要以最快的方式實現，所以在發展初期時，可能沒有太多的精力去維護趣店的基礎架構，所以就需要依賴於阿里雲強大的支持。徐章健表示選擇藉助阿里雲實現上雲是趣店創業將近三年以來選擇的比較正確的一條路，這條路幫助趣店基於阿里雲實現了對於產品的快速迭代。
那麼作為消費金融領域內的企業，趣店存不存在類似於雙11這樣的秒殺場景呢？在面臨大流量、高併發這樣的場景的衝擊時，趣店是如何應對挑戰的呢？
徐章健談到雙11對於趣店而言，其實也和雙11對於阿里一樣是一個非常大的考驗。接下來，徐章健簡單地分享了趣店為了應對雙11所做的準備，也就是從消費金融行業的角度分享瞭如何應對雙11的大流量、高併發場景的考驗。
首先徐章健談到趣店也會有全鏈路壓測機制，每年會進行三輪的全鏈路壓測，大約會在3月份、8月份和10月份，全程為雙11做準備。其次，因為流量會存在脈衝，有時會出現流量的波峰。那麼為了應對這樣的大流量，趣店會對於一些原本長鏈路的服務進行扁平化處理，在架構層面進行一些調整，比如加入MQ進行解耦和削峰，當流量過來時，先在MQ中進行緩存，後端基於不同的處理能力加上不同的Worker，將MQ中的消息向後端的RDS和Redis進行分發，這樣做的核心目的就是為了保障後端服務的穩定性，保證後端不被這波流量擊垮。最後一部分，就是在RDS或者說DB層面，也需要進行專項的優化。
趣店平臺架構體系圖
趣店數據庫選型的思考
其實最近幾年數據庫技術發展還是比較迅速的，從最初的關係型數據庫發展到NoSQL數據庫再到分析型數據庫。那麼對於趣店而言，在對數據庫類型進行選型時是基於什麼樣的思考呢？
徐章健談到對於關係型數據庫而言，趣店核心部分採用的是阿里雲的RDS，除此之外還會使用到一些PG，也就是目前用到了MySQL和PG這兩個開源的數據庫。另外就是對於NoSQL而言，趣店目前主要使用了Redis，以及阿里雲能夠提供集群支持的MongoDB數據庫。
其實，趣店最初做Redis時還是自己創建並維護的，但是後來發現運維以及故障解決方面存在問題，或者說技術處理問題的能力水平還是不夠的，所以最後進行了轉型，將自建Redis這部分轉移到阿里雲提供的Redis集群上去，其實阿里雲的Redis服務在公測時還是不穩定的，但是經過了一年多的磨合，目前來看，阿里雲的Redis服務已經上了一個大的臺階，有了很大改善和提升，而且相信在未來阿里雲的Redis服務也會有更大的發展空間。
正如上面談到的，趣店的數據庫其實分為了兩大類，也就是像MySQL這樣的傳統的關係型數據庫以及像Redis和MongoDB這樣的NoSQL數據庫，但是新型的數據庫與傳統關係型數據庫在業務需求上往往是不一致的，那麼對於像趣店這樣的偏向於金融類的業務而言，對於傳統型數據庫的訴求和需求是什麼呢？
徐章健談到對於傳統數據庫而言，首先會對於其服務的穩定性非常看重，對於像RDS這樣集群性質的數據庫而言，其可靠性、可擴展性以及安全性都是互聯網金融行業的企業比較關注的。而對於NoSQL這部分來說，趣店更看重的是穩定性和性能，特別是對於在像雙十一這種場景下，大流量過來的時候，需要去考慮性能問題應該如何解決，這時NoSQL就派上用場了。
對於RDS的穩定性而言，趣店使用了RDS已經經過了三年的時間，徐章健認為阿里雲的RDS總體上而言是比較穩定的，但同時對於趣店而言，在穩定性上則會有更高的要求，主要表現在以下的兩個方面：
- 數據安全，趣店所有的用戶信息以及交易記錄都是存儲在RDS中的，那麼如何保證這部分數據不丟失，這是一個重要的需求。
- 彈性擴展，業務的交易量是不斷擴增的，那麼如何保證數據不會成為存儲的瓶頸，以及如何使存儲能夠更好地擴展而不會影響業務的快速發展，這也是目前比較關心的。
對於RDS的基於邏輯業務的拆分，也就是大家說的分庫分表的功能來講，目前來看，通過阿里雲提供的服務以及趣店自身的策略已經可以非常好地滿足需求了。而在另外一個層面上，趣店還會有更高的要求，就是需要構建兩地三中心，所以在RDS層面會有一些災備的需求。所以趣店後來選擇了阿里雲的RDS的災備功能，目前在多個機房對於核心數據庫都進行了備份。基於這樣的場景，再深入一點去考慮，其實趣店希望不通過業務去幹預RDS層面的分庫分表，而是希望在DB層面或者是組件層面去做這樣的事情。所以後來趣店調研了阿里雲的DRDS，後續也希望通過DRDS實現業務方不需要感知底層的存儲，而是能夠通過數據庫層面的核心技術組件來解決問題。
而對於數據庫的安全層面而言，趣店目前在做三個維度的安全：
- 鏈路層面，目前趣店使用了阿里的雲盾服務來保證請求的安全。
- 引擎層面，阿里雲數據庫服務的底層會對於數據進行加密，即便被脫庫，對方得到的也只是加密後的文件，需要有密匙才能進行解析，所以能夠實現引擎層面的安全。
- 核心業務層面的字段加密，這部分與業務的關聯關係會更重一些，比如金融行業的幾個要素：身份證、密碼以及手機號等等這些都是要進行字段加密的。
總結而言，趣店對於傳統型數據庫的需求一部分在於可靠性上，需要兩地三中心的模式，需要主區域存在多個可用區，而在異地則需要實時的備庫，而趣店藉助阿里雲的RDS實現了兩地三中心的策略。另一部分的需求則在於數據庫的可擴展性上，核心訴求集中在對於業務無限擴展以及海量併發數據的支持上，這部分可以使用阿里雲的分佈式數據庫DDRS實現。另外最核心的問題還是安全，包括鏈路安全、引擎存儲安全以及字段的安全，字段安全主要依靠業務方面實現，而鏈路和存儲部分的安全則可以藉助阿里雲提供的服務實現。
而趣店對於新型數據庫的訴求集中在穩定性和性能部分，也許阿里雲的Redis服務在最初公測時期的穩定性表現並不算特別優秀，但是最近一年，阿里雲的Redis數據庫進行了大幅度的提升，進行了包括系統架構上的優化以及與大的中臺系統進行合併等，整體上迅速提升了穩定性。
而在性能方面，比如像面對雙十一的挑戰時，Redis有沒有能夠幫助業務快速成長的點呢？
徐章健談到對於Redis的性能而言，面對雙十一的挑戰是沒有問題的。阿里雲Redis的擴展性以及集群的模型對於性能天然上就有非常不錯的支持，而Redis本身的引擎也非常強，所以性能方面的整體是比較不錯的。
趣店最初使用了自建的Redis，而現在為了應對擴展性使用了阿里雲的集群版Redis，那麼針對於兩種方式的對比，對於業內的技術朋友有什麼樣的建議呢？什麼樣的方式會更適合於初創企業的成長呢？
其實對於初創型公司，在進行基礎架構設計的時候，需要關注於重點。
從趣店的角度而言，在成長初期的時候，不適宜引入中間件這樣的技術組件，首先因為初創公司的技術資源是非常有限的，所以需要聚焦於自身的業務發展，對於基礎架構的投入不可能會非常多。在這種情況下，如果要引入中間件或者技術組件，就需要深入地瞭解其內部的機制，對於出現的問題需要能夠跟進，如果不能達到這種能力，那麼就最好就不要引入中間件，特別是存儲中間件。
徐章健在給出的建議中還談到，如果在業務能夠接受的情況下，就去雲上通過像阿里雲的Redis集群這樣的服務去實現，這樣其實就往往能夠滿足需求，如果還有更高的需求，比如像容災、主備這些需求，在業務的架構層面就需要進行更多的思考，不能完全依賴於Redis，因為任何一個版本的Redis或多或少都有出現問題的概率，針對這樣的問題一定要在業務層面採取一定的預防措施。
趣店基礎架構設計實踐經驗
趣店在架構設計方面有什麼樣的經驗可以進行分享？
徐章健談到對於初創型公司的基礎架構層面的把握來說，以趣店為例，首先為了快速地推進業務發展，趣店在技術上採用了LAMP架構。這樣的基礎架構從整個業務層面來看，核心就在於後端的存儲。因為對於LAMP架構的應用而言，PHP開發起來會非常快速，無論是性能還是開發成本而言都是比較不錯的，所以對於正在創業路上的朋友們，一定要更多地關注DB層面，首先就應該建立DB的規範。
趣店創業初期架構圖
業務快速發展期架構圖
趣店之前出現過一個很痛苦的事情，由於原來沒有DB的規範，所以在MySQL裡面的一些數據庫的列無限多，有的達到上百列，並且還存在各種大的字段。這樣的不規範就為後續的工作埋下了巨大的坑，之後為了填上這個坑，技術團隊花費了非常大的代價。如果能夠在初期花更多的時間在DB層面設計評審上，後期維護以及擴展就會非常方便。
而對於另外一部分，就是服務穩定性以及性能提升而言，可能大家都知道使用緩存機制，其實在任何一層都可以使用緩存。但是在業務構建初期的時候，不可能層層都加上緩存，建議在DB層面之前一定要加入緩存，無論使用Redis還是MemCache，都是為了防止DB被打垮。所以DB其實是最值得關注的核心點，如果DB保不住，整個系統也就會處於癱瘓的狀態。總而言之，在進行架構設計時需要對DB層面進行規範，另外還需要適當地使用緩存機制。
其實很多時候，在最初設計架構時並不能預測未來的發展，但是隨著業務的發展，架構也需要進行不斷優化，所以對於架構的優化而言，沒有一個開始點也沒有一個結束點，處於始終在路上的狀態，需要不斷去適應業務發展並調整自己的架構。
消費金融風控的思索和探索
趣店集團作為消費金融類的企業，並且一個主打業務是分期類購物，口號是“零首付分期，一秒鐘體驗”，那麼在為用戶服務的過程中，如何防止壞賬的出現呢？在辦理借貸、分期業務時如何保證有借有還呢？在信用評價部分，趣店是怎樣做的呢？
其實如何將風控做的更好，這部分就是趣店的核心競爭力。風控的核心就是為了降低逾期率，防止壞賬的出現。其實趣店去年從美國引入了CRO，她就是資深的風控專家。從趣店來看，構建風控體系大概涉及到幾個維度：
- 趣店合理地使用了芝麻信用，而且對於芝麻信用分的使用上會進行進一步的細分。
- 趣店具有自建的風控模型，趣店經過三年的發展沉澱下來了很多的交易記錄以及借還記錄，可以基於這些大數據構建風控模型。這樣當用戶登錄之後，基本上就可以對於用戶的信用程度進行判斷。
- 趣店會和業界主流的信用機構進行合作，通過合作獲取像央行的徵信記錄這樣的數據信息，並使用這些數據對用戶進行信用評級來實現風險控制。
總之而言，就是在不同的維度做不同事情，整體上保護趣店的交易，降低逾期率，提高風控層級。
趣店的安全運維經驗
其實在2016年發生了很多的安全事件，比如像MongoDB黑客贖金事件、GitLab事件等，那麼趣店是如何看待這樣的事件呢？在技術運維部分又有哪些經驗可以分享呢？
安全問題一直是困擾著互聯網企業的大問題。首先當GitLab事件發生之後，趣店集團的CTO就提出要迅速地Review自身的安全機制和數據備份機制以及容災機制。所以當時技術團隊就開始做了以下幾個事情：
- 對於代碼安全或以及備份機制進行審查，判定是否合理。之前趣店代碼備份是每一個小時進行一次的，但是目前已經變為每15分鐘就進行異地機房備份。
- 在DB安全層面進行預案演練，剛才已經提到阿里雲的兩地三中心分佈式架構在很大程度上已經能夠保證安全了，而趣店在此基礎上進行了預案演練，如果真的出現某一個IDC的數據被刪掉了，需要保證另一個IDC能夠立刻運行起來。所以，針對於趣店的運維而言，每個月都會進行預案演練，甚至在雙十一之前還會進行多輪的演練，所以也積累了多種多樣的輸出方法。
而針對於MongoDB事件，趣店在這一點上可以說藉助了阿里雲的安全能力對於一些安全事故進行了屏蔽，包括之前的幾起Redis事件，也沒有能夠對於趣店造成太大的影響，因為趣店是處於阿里雲的專有網絡VPC上，基本上對於一些安全問題都是可控的。
王義成也介紹了阿里雲的數據庫能夠幫助用戶在哪些層面進行防護。其實對於數據安全防護而言，可以大致分為幾個階段：事前防護、事中防護以及事後的補救。
在事前防護階段，阿里雲提供了VPC網絡，在VPC網絡之下強制用戶設置白名單，前端的DDoS防攻擊策略以及密碼的強認證等，這些都是幫助用戶在事前進行防護的策略。對於像Redis或者MongoDB，在業內很多用戶都是直接將其暴露於公網之上的，並且密碼設置的往往會比較簡單，經常會出現類似黑客贖金事件這樣比較惡劣的攻擊。而在雲上則對於這一部分進行了保護，包括禁止公網內的訪問，並且強制用戶輸入安全等級非常高的密碼來進行事前的防護。
而對於事中防護而言，則是通過對一些數據的判斷來分析出哪些SQL語句或者操作可能發生脫庫或者誤刪除的情況，這一部分後續將通過阿里雲強大引擎分析加入到事中防護部分。
而在事後進行補救的策略方面，阿里雲的數據庫還是做了比較多的一些事情的。比如阿里雲全線的數據庫產品，包括RDS、Redis以及Mongo都擁有日誌審計的功能。雖然兩地三中心是防護系統故障層面的比較好的策略，但是防不了內鬼或者脫庫行為，所以阿里雲可以提供日誌審計的功能，使用戶可以訪問近期的詳細時間點、IP地址以及相應操作的日誌，以此來找出究竟是誰進行了操作。另外一部分就是數據庫回滾，比方在進行大的發佈時漏了一些事情時，可以直接基於7天內的任何一個時間點將數據回滾出來，這也是事後的防護工作。所以使用阿里雲的數據防護能夠幫助用戶免去很多工作，減少在自建數據庫中需要面對的痛苦。
閱讀更多 企業上雲那些事 的文章
