择要：本次阿里如斯栖社区行业圆桌论坛上，趣店集团总架构师徐章健与阿里云数据库产品经理王义成共同磋商了趣店集团上云实践之路，并且分享了趣店集团对付数据库层面的思考的实践和在根本架构设计上的履历，以及趣店对付消费金融风控的思虑和探索。对话行业大咖，引领云端科技，畅谈云上话题，尽在阿里如斯栖社区行业圆桌论坛。
本期高朋先容：
徐章健，趣店集团总架构师；
王义成，阿里云数据库产品经理。
首先，徐章健大略先容了趣店集团的基本业务情形，趣店集团是2014年3月份成立的，前身是趣分期，在2016年完成了Pre-A IPO轮融资之后，趣分期正式升级为趣店集团。趣店集团目前整体业务分为两大部分:来分期和趣店，供应现金和实物分期这两种做事。总体而言，趣店集团属于消费金融行业。
上云之路
对付像趣店这样消费金融类的产品而言，在上云的过程中以及在选择云打算做事供应商的时候，在根本架构的设计层面，考虑到的出发点有哪些呢？
徐章健谈到趣店集团的产品从一开始便是构建在云上的，其实在刚开始上云的时候，趣店的确调研了很多的云做事供应商，终极选择阿里云是基于如下几个方面的考虑：
做事的能力、可靠性以及稳定性，对付任何一个企业或者是创业团队而言，这都是比较看被重的方面。
根本组件或者说是根本的做事能力，这里面包括核心的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天内的任何一个韶光点将数据回滚出来，这也是事后的防护事情。以是利用阿里云的数据防护能够帮助用户免去很多事情，减少在自建数据库中须要面对的痛楚。
