趣店集团「从0到1」的云上架构设计
本次阿里云云栖社区行业圆桌论坛上，趣店集团高级架构师徐章健与阿里云数据库产品经理王义成共同探讨了趣店集团上云实践之路，并且分享了趣店集团对于数据库层面的思考的实践和在基础架构设计上的经验，以及趣店对于消费金融风控的思索和探索。
前言
首先，简单介绍了趣店集团的基本业务情况，趣店集团是2014年3月份成立的，前身是趣分期，在2016年趣分期正式升级为趣店集团。 趣店集团目前整体业务分为两大部分:趣分期和趣店，提供现金和实物分期这两种服务。总体而言，趣店集团属于消费金融行业。
一、上云之路
1.1 对于像趣店这样消费金融类的产品而言，在上云的过程中以及在选择云计算服务提供商的时候，在基础架构的设计层面，考虑到的出发点有哪些呢？
趣店集团的产品从一开始就是构建在云上的，其实在刚开始上云的时候，趣店的确调研了很多的云服务提供商，最终选择阿里云是基于如下几个方面的考虑：
服务的能力、可靠性以及稳定性，对于任何一个企业或者是创业团队而言，这都是比较看被重的方面。基础组件或者说是基础的服务能力，这里面包括核心的RDS数据库支持，Redis以及MQ等等这些服务。这些服务可能有的云厂商能够提供，但是很多厂商却不能。而阿里云拥有这一系列非常丰富的产品，其基础组件的产品线也非常完善。对于像趣店这样的创业团队而言，初期最需要关注的是业务的发展，可能没有太多的人力、物力和财力去做基础架构，这时如果云服务提供商能够为创业团队提供更多的基础服务的保障，当然会被优先选择。市场评价或者说是口碑，趣店也非常看重阿里云的口碑，这一点也是值得创业团队关注的。
所以趣店最终选择阿里云其实是对于服务能力、基础组件以及市场评价这样的几个指标进行综合性评定之后做出的选择。
1.2 趣店作为消费金融类的产品，在上云过程中，有没有政策方面的特殊限制呢？
从这一点来讲，趣店的确和其他互联网公司不完全一样，因为趣店属于消费金融行业。在数据层面，首先消费金融行业对于数据的安全性要求是非常高的；其次，金融监管上存在着两地三中心容灾这样的要求，这一部分与其他互联网公司是不同的。
趣店集团的上云之路，其实是从2014年3月份开始创业时就开始的。在刚开始的时候，团队也没有太多的考虑，因为自建IDC肯定是不现实的，因为对于任何创业团队而言，购买硬件以及各种运维的成本都将是一笔不小的开销，所以趣店在开始时的技术方向就是基于云的。
这时候问题就出现了，就是应该选择哪家云计算服务提供商以及应该选用云上的哪些服务。正如之前所提到的，无论从趣店调研的结果来说，还是对于云计算服务提供商进行的对比来说也好，在进行综合的评定之后，在初期就选择了阿里云的ECS作为最基础的服务。趣店的产品是基于LAMP架构设计的，使用PHP进行开发，后端所使用的Redis和RDS也是非常核心的部分，所以一些核心的数据在最开始也就是在使用阿里云的RDS进行存储。
随着趣店业务的发展，就不断地会有一些更大的挑战和新的需求出现。因为架构设计已经在云上了，此时就需要开始思考如何通过阿里云帮助企业将业务推动得更快，所以在这个过程中趣店就使用了阿里云很多其他的服务，比如使用Cache进行加速，使用MQ服务进行解耦以及进行异步化等等，在这个过程中，阿里云的各个产品线和服务是逐步地被趣店的产品使用起来的。
从整个过程来看，可以说趣店对于阿里云存在着一个深度依赖的关系。只要有需求一来，技术团队首先会去思考阿里云有没有这样的服务，有的话就会去采用。对于创业团队而言，创业项目从0到1的这个过程一定要以最快的方式实现，所以在发展初期时，可能没有太多的精力去维护趣店的基础架构，所以就需要依赖于阿里云强大的支持。选择借助阿里云实现上云是趣店创业将近三年以来选择的比较正确的一条路，这条路帮助趣店基于阿里云实现了对于产品的快速迭代。
1.3 那么作为消费金融领域内的企业，趣店存不存在类似于双11这样的秒杀场景呢？在面临大流量、高并发这样的场景的冲击时，趣店是如何应对挑战的呢？
双11对于趣店而言，其实也和双11对于阿里一样是一个非常大的考验。接下来，简单地分享了趣店为了应对双11所做的准备，也就是从消费金融行业的角度分享了如何应对双11的大流量、高并发场景的考验。
首先趣店也会有全链路压测机制，每年会进行三轮的全链路压测，大约会在3月份、8月份和10月份，全程为双11做准备。其次，因为流量会存在脉冲，有时会出现流量的波峰。那么为了应对这样的大流量，趣店会对于一些原本长链路的服务进行扁平化处理，在架构层面进行一些调整，比如加入MQ进行解耦和削峰，当流量过来时，先在MQ中进行缓存，后端基于不同的处理能力加上不同的Worker，将MQ中的消息向后端的RDS和Redis进行分发，这样做的核心目的就是为了保障后端服务的稳定性，保证后端不被这波流量击垮。最后一部分，就是在RDS或者说DB层面，也需要进行专项的优化。
二、趣店数据库选型的思考
2.1 其实最近几年数据库技术发展还是比较迅速的，从最初的关系型数据库发展到NoSQL数据库再到分析型数据库。那么对于趣店而言，在对数据库类型进行选型时是基于什么样的思考呢？
对于关系型数据库而言，趣店核心部分采用的是阿里云的RDS，除此之外还会使用到一些PG，也就是目前用到了MySQL和PG这两个开源的数据库。另外就是对于NoSQL而言，趣店目前主要使用了Redis，以及阿里云能够提供集群支持的MongoDB数据库。
其实，趣店最初做Redis时还是自己创建并维护的，但是后来发现运维以及故障解决方面存在问题，或者说技术处理问题的能力水平还是不够的，所以最后进行了转型，将自建Redis这部分转移到阿里云提供的Redis集群上去，其实阿里云的Redis服务在公测时还是不稳定的，但是经过了一年多的磨合，目前来看，阿里云的Redis服务已经上了一个大的台阶，有了很大改善和提升，而且相信在未来阿里云的Redis服务也会有更大的发展空间。
2.2 正如上面谈到的，趣店的数据库其实分为了两大类，也就是像MySQL这样的传统的关系型数据库以及像Redis和MongoDB这样的NoSQL数据库，但是新型的数据库与传统关系型数据库在业务需求上往往是不一致的，那么对于像趣店这样的偏向于金融类的业务而言，对于传统型数据库的诉求和需求是什么呢？
对于传统数据库而言，首先会对于其服务的稳定性非常看重，对于像RDS这样集群性质的数据库而言，其可靠性、可扩展性以及安全性都是互联网金融行业的企业比较关注的。而对于NoSQL这部分来说，趣店更看重的是稳定性和性能，特别是对于在像双十一这种场景下，大流量过来的时候，需要去考虑性能问题应该如何解决，这时NoSQL就派上用场了。
对于RDS的稳定性而言，趣店使用了RDS已经经过了三年的时间，阿里云的RDS总体上而言是比较稳定的，但同时对于趣店而言，在稳定性上则会有更高的要求，主要表现在以下的两个方面：
数据安全，趣店所有的用户信息以及交易记录都是存储在RDS中的，那么如何保证这部分数据不丢失，这是一个重要的需求。弹性扩展，业务的交易量是不断扩增的，那么如何保证数据不会成为存储的瓶颈，以及如何使存储能够更好地扩展而不会影响业务的快速发展，这也是目前比较关心的。
对于RDS的基于逻辑业务的拆分，也就是大家说的分库分表的功能来讲，目前来看，通过阿里云提供的服务以及趣店自身的策略已经可以非常好地满足需求了。而在另外一个层面上，趣店还会有更高的要求，就是需要构建两地三中心，所以在RDS层面会有一些灾备的需求。所以趣店后来选择了阿里云的RDS的灾备功能，目前在多个机房对于核心数据库都进行了备份。基于这样的场景，再深入一点去考虑，其实趣店希望不通过业务去干预RDS层面的分库分表，而是希望在DB层面或者是组件层面去做这样的事情。所以后来趣店调研了阿里云的DRDS，后续也希望通过DRDS实现业务方不需要感知底层的存储，而是能够通过数据库层面的核心技术组件来解决问题。
而对于数据库的安全层面而言，趣店目前在做三个维度的安全：
链路层面，目前趣店使用了阿里的云盾服务来保证请求的安全。引擎层面，阿里云数据库服务的底层会对于数据进行加密，即便被脱库，对方得到的也只是加密后的文件，需要有密匙才能进行解析，所以能够实现引擎层面的安全。核心业务层面的字段加密，这部分与业务的关联关系会更重一些，比如金融行业的几个要素：身份证、密码以及手机号等等这些都是要进行字段加密的。
总结而言，趣店对于传统型数据库的需求一部分在于可靠性上，需要两地三中心的模式，需要主区域存在多个可用区，而在异地则需要实时的备库，而趣店借助阿里云的RDS实现了两地三中心的策略。另一部分的需求则在于数据库的可扩展性上，核心诉求集中在对于业务无限扩展以及海量并发数据的支持上，这部分可以使用阿里云的分布式数据库DDRS实现。另外最核心的问题还是安全，包括链路安全、引擎存储安全以及字段的安全，字段安全主要依靠业务方面实现，而链路和存储部分的安全则可以借助阿里云提供的服务实现。
而趣店对于新型数据库的诉求集中在稳定性和性能部分，也许阿里云的Redis服务在最初公测时期的稳定性表现并不算特别优秀，但是最近一年，阿里云的Redis数据库进行了大幅度的提升，进行了包括系统架构上的优化以及与大的中台系统进行合并等，整体上迅速提升了稳定性。
2.3 而在性能方面，比如像面对双十一的挑战时，Redis有没有能够帮助业务快速成长的点呢？
其实对于初创型公司，在进行基础架构设计的时候，需要需要关注于重点。
从趣店的角度而言，在成长初期的时候，不适宜引入中间件这样的技术组件，首先因为初创公司的技术资源是非常有限的，所以需要聚焦于自身的业务发展，对于基础架构的投入不可能会非常多。在这种情况下，如果要引入中间件或者技术组件，就需要深入地了解其内部的机制，对于出现的问题需要能够跟进，如果不能达到这种能力，那么就最好就不要引入中间件，特别是存储中间件。
如果在业务能够接受的情况下，就去云上通过像阿里云的Redis集群这样的服务去实现，这样其实就往往能够满足需求，如果还有更高的需求，比如像容灾、主备这些需求，在业务的架构层面就需要进行更多的思考，不能完全依赖于Redis，因为任何一个版本的Redis或多或少都有出现问题的概率，针对这样的问题一定要在业务层面采取一定的预防措施。
三、趣店基础架构设计实践经验
3.1 趣店在架构设计方面有什么样的经验可以进行分享？
对于初创型公司的基础架构层面的把握来说，以趣店为例，首先为了快速地推进业务发展，趣店在技术上采用了LAMP架构。这样的基础架构从整个业务层面来看，核心就在于后端的存储。因为对于LAMP架构的应用而言，PHP开发起来会非常快速，无论是性能还是开发成本而言都是比较不错的，所以对于正在创业路上的朋友们，一定要更多地关注DB层面，首先就应该建立DB的规范。
- 趣店创业初期架构图
- 业务快速发展期架构图
趣店之前出现过一个很痛苦的事情，由于原来没有DB的规范，所以在MySQL里面的一些数据库的列无限多，有的达到上百列，并且还存在各种大的字段。这样的不规范就为后续的工作埋下了巨大的坑，之后为了填上这个坑，技术团队花费了非常大的代价。如果能够在初期花更多的时间在DB层面设计评审上，后期维护以及扩展就会非常方便。
而对于另外一部分，就是服务稳定性以及性能提升而言，可能大家都知道使用缓存机制，其实在任何一层都可以使用缓存。但是在业务构建初期的时候，不可能层层都加上缓存，建议在DB层面之前一定要加入缓存，无论使用Redis还是MemCache，都是为了防止DB被打垮。所以DB其实是最值得关注的核心点，如果DB保不住，整个系统也就会处于瘫痪的状态。总而言之，在进行架构设计时需要对DB层面进行规范，另外还需要适当地使用缓存机制。
其实很多时候，在最初设计架构时并不能预测未来的发展，但是随着业务的发展，架构也需要进行不断优化，所以对于架构的优化而言，没有一个开始点也没有一个结束点，处于始终在路上的状态，需要不断去适应业务发展并调整自己的架构。
四、消费金融风控的思索和探索
4.1 趣店集团作为消费金融类的企业，并且一个主打业务是分期类购物，口号是“零首付分期，一秒钟体验”，那么在为用户服务的过程中，如何防止坏账的出现呢？在办理借贷、分期业务时如何保证有借有还呢？在信用评价部分，趣店是怎样做的呢？
其实如何将风控做的更好，这部分就是趣店的核心竞争力。风控的核心就是为了降低逾期率，防止坏账的出现。其实趣店去年从美国引入了CRO，他就是资深的风控专家。从趣店来看，构建风控体系大概涉及到几个维度：
趣店深度依赖于芝麻信用，所以对于芝麻信用分的使用上会进行进一步的细分。趣店具有自建的风控模型，趣店经过三年的发展沉淀下来了很多的交易记录以及借还记录，可以基于这些大数据构建风控模型。这样当用户登录之后，基本上就可以对于用户的信用程度进行判断。趣店会和业界主流的信用机构进行合作，通过合作获取像央行的征信记录这样的数据信息，并使用这些数据对用户进行信用评级来实现风险控制。
总之而言，就是在不同的维度做不同事情，整体上保护趣店的交易，降低逾期率，提高风控层级。
五、趣店的安全运维经验
5.1 其实在2016年发生了很多的安全事件，比如像MongoDB黑客赎金事件、GitLab事件等，那么趣店是如何看待这样的事件呢？在技术运维部分又有哪些经验可以分享呢？
安全问题一直是困扰着互联网企业的大问题。首先当GitLab事件发生之后，趣店集团的CTO就提出要迅速地Review自身的安全机制和数据备份机制以及容灾机制。所以当时技术团队就开始做了以下几个事情：
- 对于代码安全或以及备份机制进行审查，判定是否合理。之前趣店代码备份是每一个小时进行一次的，但是目前已经变为每15分钟就进行异地机房备份。
- 在DB安全层面进行预案演练，刚才已经提到阿里云的两地三中心分布式架构在很大程度上已经能够保证安全了，而趣店在此基础上进行了预案演练，如果真的出现某一个IDC的数据被删掉了，需要保证另一个IDC能够立刻运行起来。所以，针对于趣店的运维而言，每个月都会进行预案演练，甚至在双十一之前还会进行多轮的演练，所以也积累了多种多样的输出方法。
而针对于MongoDB事件，趣店在这一点上可以说借助了阿里云的安全能力对于一些安全事故进行了屏蔽，包括之前的几起Redis事件，也没有能够对于趣店造成太大的影响，因为趣店是处于阿里云的专有网络VPC上，基本上对于一些安全问题都是可控的。
