先簡單介紹下趣店集團的基本業務情況，趣店集團是2014年3月份成立的，前身是趣分期，在2016年趣分期正式升級為趣店集團。趣店集團目前整體業務分為兩大部分：來分期和趣店，提供現金和實物分期這兩種服務。總體而言，趣店集團屬於消費金融行業。
雲平臺的選擇
趣店集團的產品從一開始就是構建在雲上的，其實在剛開始上雲的時候，趣店的確調研了很多的雲服務提供商，最終選擇阿里雲是基於如下幾個方面的考慮：
- 服務的能力、可靠性以及穩定性，對於任何一個企業或者是創業團隊而言，這都是比較看被重的方面。
- 基礎組件或者說是基礎的服務能力，這裡麵包括核心的RDS數據庫支持，Redis以及MQ等等這些服務。這些服務可能有的雲廠商能夠提供，但是很多廠商卻不能。而阿里雲擁有這一系列非常豐富的產品，其基礎組件的產品線也非常完善。對於像趣店這樣的創業團隊而言，初期最需要關注的是業務的發展，可能沒有太多的人力、物力和財力去做基礎架構，這時如果雲服務提供商能夠為創業團隊提供更多的基礎服務的保障，當然會被優先選擇。
- 市場評價或者說是口碑，趣店也非常看重阿里雲的口碑，這一點也是值得創業團隊關注的。
所以趣店最終選擇阿里雲其實是對於服務能力、基礎組件以及市場評價這樣的幾個指標進行綜合性評定之後做出的選擇。
上雲之路
趣店屬於消費金融行業，和其他互聯網公司不完全一樣。在數據層面，首先消費金融行業對於數據的安全性要求是非常高的；其次，金融監管上存在著兩地三中心容災這樣的要求，這一部分與其他互聯網公司是不同的。
趣店集團的上雲之路，其實是從2014年3月份開始創業時就開始的。在剛開始的時候，團隊也沒有太多的考慮，因為自建IDC肯定是不現實的，因為對於任何創業團隊而言，購買硬件以及各種運維的成本都將是一筆不小的開銷，所以趣店在開始時的技術方向就是基於雲的。
我們在初期就選擇了阿里雲的ECS作為最基礎的服務。趣店的產品是基於LAMP架構設計的，使用PHP進行開發，後端所使用的Redis和RDS也是非常核心的部分，所以一些核心的數據在最開始也就是在使用阿里雲的RDS進行存儲。
阿里雲的RDS總體上而言是比較穩定的，但同時對於趣店而言，在穩定性上則會有更高的要求，主要表現在以下的兩個方面：
- 數據安全，趣店所有的用戶信息以及交易記錄都是存儲在RDS中的，那麼如何保證這部分數據不丟失，這是一個重要的需求。
- 彈性擴展，業務的交易量是不斷擴增的，那麼如何保證數據不會成為存儲的瓶頸，以及如何使存儲能夠更好地擴展而不會影響業務的快速發展，這也是目前比較關心的。
其實，趣店最初做Redis時還是自己創建並維護的，但是後來發現運維以及故障解決方面存在問題，或者說技術處理問題的能力水平還是不夠的，所以最後進行了轉型，將自建Redis這部分轉移到阿里雲提供的Redis集群上去，其實阿里雲的Redis服務在公測時還是不穩定的，但是經過了一年多的磨合，目前來看，阿里雲的Redis服務已經上了一個大的臺階，有了很大改善和提升，而且相信在未來阿里雲的Redis服務也會有更大的發展空間。
除此之外還會使用到一些PG，也就是目前用到了MySQL和PG這兩個開源的數據庫。
雲端架構優化
趣店為了快速地推進業務發展，在技術上採用了LAMP架構。這樣的基礎架構從整個業務層面來看，核心就在於後端的存儲。因為對於LAMP架構的應用而言，PHP開發起來會非常快速，無論是性能還是開發成本而言都是比較不錯的，需要注意的是，一定要更多地關注DB層面，首先就應該建立DB的規範。
趣店創業初期架構圖如下。
隨著趣店業務的發展，就不斷地會有一些更大的挑戰和新的需求出現。因為架構設計已經在雲上了，此時就需要開始思考如何通過阿里雲幫助企業將業務推動得更快，所以在這個過程中趣店就使用了阿里雲很多其他的服務，比如使用Cache進行加速，使用MQ服務進行解耦以及進行異步化等等，在這個過程中，阿里雲的各個產品線和服務是逐步地被趣店的產品使用起來的。
業務快速發展期架構圖如下。
從整個過程來看，可以說趣店對於阿里雲存在著一個深度依賴的關係。只要有需求一來，技術團隊首先會去思考阿里雲有沒有這樣的服務，有的話就會去採用。對於創業團隊而言，創業項目從0到1的這個過程一定要以最快的方式實現，所以在發展初期時，可能沒有太多的精力去維護趣店的基礎架構，所以就需要依賴於阿里雲強大的支持。選擇藉助阿里雲實現上雲是趣店創業將近三年以來選擇的比較正確的一條路，這條路幫助趣店基於阿里雲實現了對於產品的快速迭代。
性能及安全
雙11對於趣店而言，其實也是一個非常大的考驗。趣店每年會進行三輪的全鏈路壓測，大約會在3月份、8月份和10月份，全程為雙11做準備。
因為流量會存在脈衝，有時會出現流量的波峰。那麼為了應對這樣的大流量，趣店會對於一些原本長鏈路的服務進行扁平化處理，在架構層面進行一些調整，比如加入MQ進行解耦和削峰，當流量過來時，先在MQ中進行緩存，後端基於不同的處理能力加上不同的Worker，將MQ中的消息向後端的RDS和Redis進行分發，這樣做的核心目的就是為了保障後端服務的穩定性，保證後端不被這波流量擊垮。最後一部分，就是在RDS或者說DB層面，也需要進行專項的優化。
對於Redis的性能而言，面對雙11的挑戰是沒有問題的。阿里雲Redis的擴展性以及集群的模型對於性能天然上就有非常不錯的支持，而Redis本身的引擎也非常強，所以性能方面的整體是比較不錯的。
對於安全層面而言，趣店目前在做三個維度的安全：
- 鏈路層面，目前趣店使用了阿里的雲盾服務來保證請求的安全。
- 引擎層面，阿里雲數據庫服務的底層會對於數據進行加密，即便被脫庫，對方得到的也只是加密後的文件，需要有密匙才能進行解析，所以能夠實現引擎層面的安全。
- 核心業務層面的字段加密，這部分與業務的關聯關係會更重一些，比如金融行業的幾個要素：身份證、密碼以及手機號等等這些都是要進行字段加密的。
總結而言，趣店對於傳統型數據庫的需求一部分在於可靠性上，需要兩地三中心的模式，需要主區域存在多個可用區，而在異地則需要實時的備庫，而趣店藉助阿里雲的RDS實現了兩地三中心的策略。另一部分的需求則在於數據庫的可擴展性上，核心訴求集中在對於業務無限擴展以及海量併發數據的支持上，這部分可以使用阿里雲的分佈式數據庫DDRS實現。另外最核心的問題還是安全，包括鏈路安全、引擎存儲安全以及字段的安全，字段安全主要依靠業務方面實現，而鏈路和存儲部分的安全則可以藉助阿里雲提供的服務實現。
而趣店對於新型數據庫的訴求集中在穩定性和性能部分，也許阿里雲的Redis服務在最初公測時期的穩定性表現並不算特別優秀，但是最近一年，阿里雲的Redis數據庫進行了大幅度的提升，進行了包括系統架構上的優化以及與大的中臺系統進行合併等，整體上迅速提升了穩定性。
遇到的問題
趣店之前出現過一個很痛苦的事情，由於原來沒有DB的規範，所以在MySQL裡面的一些數據庫的列無限多，有的達到上百列，並且還存在各種大的字段。這樣的不規範就為後續的工作埋下了巨大的坑，之後為了填上這個坑，技術團隊花費了非常大的代價。如果能夠在初期花更多的時間在DB層面設計評審上，後期維護以及擴展就會非常方便。
而對於另外一部分，就是服務穩定性以及性能提升而言，可能大家都知道使用緩存機制，其實在任何一層都可以使用緩存。但是在業務構建初期的時候，不可能層層都加上緩存，建議在DB層面之前一定要加入緩存，無論使用Redis還是MemCache，都是為了防止DB被打垮。所以DB其實是最值得關注的核心點，如果DB保不住，整個系統也就會處於癱瘓的狀態。總而言之，在進行架構設計時需要對DB層面進行規範，另外還需要適當地使用緩存機制。
其實很多時候，在最初設計架構時並不能預測未來的發展，但是隨著業務的發展，架構也需要進行不斷優化，所以對於架構的優化而言，沒有一個開始點也沒有一個結束點，處於始終在路上的狀態，需要不斷去適應業務發展並調整自己的架構。
上雲經驗分享
從趣店的角度而言，在成長初期的時候，不適宜引入中間件這樣的技術組件，首先因為初創公司的技術資源是非常有限的，所以需要聚焦於自身的業務發展，對於基礎架構的投入不可能會非常多。在這種情況下，如果要引入中間件或者技術組件，就需要深入地瞭解其內部的機制，對於出現的問題需要能夠跟進，如果不能達到這種能力，那麼就最好就不要引入中間件，特別是存儲中間件。
如果在業務能夠接受的情況下，就去雲上通過像阿里雲的Redis集群這樣的服務去實現，這樣其實就往往能夠滿足需求，如果還有更高的需求，比如像容災、主備這些需求，在業務的架構層面就需要進行更多的思考，不能完全依賴於Redis，因為任何一個版本的Redis或多或少都有出現問題的概率，針對這樣的問題一定要在業務層面採取一定的預防措施。
閱讀更多 企業上雲那些事 的文章
