先简单介绍下趣店集团的基本业务情况，趣店集团是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或多或少都有出现问题的概率，针对这样的问题一定要在业务层面采取一定的预防措施。