从零到百亿互联网金融架构发展史---架构变迁

回想起从公司成立敲出的第一行代码算起到如今也快三年了，平台的技术架构，技术体系也算是经历了四次比较重大的升级转化（目前第四代架构体系正在进行中），临近年末也想抽出时间来回顾一下，一个小公司从最开始的零交易到如今交易量超过百亿背后的技术变迁。

 

整体介绍

在互联网金融行业一百多亿其实也算不上大平台，也就是二级阵营吧，其实每次的架构升级都是随着业务重大推动而伴随的，在前一代系统架构上遇到的问题，业务开发过程当中积累一些优秀的开发案例，在下一代系统开发中就会大力推动架构升级。一方面能够平滑过分，一方面公司资源能够大力支持，同时技术的小伙伴们可使用到前沿的技术，更有开发的成就感，就这样咱们大概也就是9个月就行系统架构一次升级，就到了咱们如今的这套架构中。

不少网友常常会问，大家平台的TPS是多少呀，最大并发是多少呀，性能怎么样，说实话咱们是一个小公司，最夸张也就上万人同时抢标，可是作为一个中型的互联网金融平台要作的事情也真的很多，远远不仅是这些参数能够说的清楚；咱们也不是什么高大上的平台，使用的技术也是目前比较主流开源产品，但在公司不断发展的过程当中也遇到了不少的问题，也尽可能去使用比较主流的、开源的、适合咱们的一些解决方案来构建整个系统，在这里分享平台发展背后技术换代的变化，同时但愿和你们多作一些交流，多提一些建议。

咱们进行了四次大的架构变化，每代架构都用一句话来总结：

• 第一代架构特色：业务比较集中、功能知足投资理财需求、快速上线
• 第二代架构特色；分布式系统改造，平台化初具规模，各项垂直业务系统搭建上线、产品端极大丰富用户投资、大数据平台研究并使用
• 第三代架构特色；SOA治理，使用zookeeper做为注册中心，dubbo作监控和调度中心；cas实现单点登陆，使用shiro作权限控制
• 第四代架构特色；全面启用微服务开发模式，springboot+springcloud技术桟作为第四代架构技术支撑

下面作详细介绍

 

第一代系统架构

2014年应该算是互联网金融元年，在以前其实已经有不少互联网公司用着各类模式在生存，一直不温不火，可是到2014年忽然火爆了起来，首先是网贷之家，网贷天眼这种第三方网站流量忽然增长，接着是媒体报道不断跟进，再后来就报出各类互联网金融公司得到XXX美圆投资的报道愈来愈多，政策也慢慢明朗，因而不少大型公司（集团）也就趁着这股热潮跟进，其中就包括咱们。

第一代系统最主要就是抢时间，公司但愿用最短的时间内保证系统上线，那时候移动浪潮已经启动，因而决定优先上线移动端，网站能够暂不考虑。公司当时有PHP和Java两种开发语言技术储备，由于PHP在快速开发上面有着很是大的优点，所以决定采用前端PHP+后端Java这种模式。系统分红了三层：用户层：安卓和IOS移动端；接口层：php提供用户和交易接口；后端：后端有两部分，后台和定时系统。后台用PHP开发和接口层公用了一个系统，另外一个是定时系统，负责计息、派息、到期等定时任务等使用了java开发。

基础服务和中间件，mysql作了最基本的主历来支持，第一代系统只是使用了mysql的主库，从库只是同步备份；memcached用来处理用户抢标的并发问题，也只用了这一块；ActiveMQ用来使用二级市场的转让撮合以及其它一些异步消息通知。项目部署：php使用apache部署，定时服务使用tomcat6来作应用服务器，使用lvs来作前端apache的负载，基本上第一代也就这些技术了，下面是第一代系统的架构图。

第一代系统上线以后，网站和H5(手机浏览器或者微信端)系统建设就变的特别突出，做为一个互联网金融公司没有官网不能忍，因而又开始快马加鞭的开始开发网站和H5系统，在这个期间PHP以前作的后台这块摘了出来，用java重新规划了一版，至此PHP就负责了网站、APP接口、H5这三个系统，三个系统共用的一个核心交易，java这边负责后台管理和定时服务，咱们通常给这个架构叫作1.1代架构。

第1.1代系统架构图，绿色部分为变更部分

第一代系统的缺点是业务过于集中，仓促上线，后期问题较多

 

第二代系统架构

第二代系统的背景是随着公司业务量的快速发展，不少初期所欠的技术债务通通爆发，线上出现了不少问题，最严重的一次是给个别用户重复派息，各类被骂，如今记忆犹新。另外一方各业务部门需求不断，公司产品需求不断，因此这个阶段就是忙着修复各类生产问题，一边还须要开发垂直业务系统。那段时间差点被逼疯了，第一代系统是封闭开发，回来还没缓过劲，这边又赶立刻架，真是疼并快乐着。

第一个垂直子系统上线的是：合同系统，当时用户投标后没有一个合同，不少用户很不放心，就把优先级提到了前面。后来就单合同系统就改了三个版本，第一个版本只是生成pdf,第二阶段上线电子签章，第三个阶段加水印，自定义动态生成pdf;紧接着开发积分系统：用户邀请，投资等生产积分，用来兑换抵现卷等；抽离出消息系统：站内消息、短信、邮件等；上线监控系统、业务监控和服务监控，业务失败预警；各业务部门继续不断提需求，上线财务系统：财务人员统计核算金额；风控系统：监控异经常使用户，异常交易；给销售开发了销售系统；由于和不少第三方系统对接，又开发了对外接入系统。

一代系统作的很赶，产品界面又很烂，随即启动规划了网站2.0、APP2.0、H52.0，针对前端系统的需求，在后端开发了CMS系统来发布项目、公司的公告新闻等；第二代产品端广泛规划了不少大数据分析的一些需求，会在官网展现全量数据分析后投资偏好、投资的金额都跑到哪里去，前端用地图来展现，对于我的也会有还款日历，代收数据分析等，由于须要跑全量数据，在规划的时候都是设计离线来处理，将数据从mysql从库同步到mongodb的集群中，利用mongdo的mapreduce技术来处理大量的数据，因而咱们的数据库层就变成下面的这个架构

mysql实时同步到mongodb，咱们使用的是tungsten-relicator这个工具，会在mysql服务器端启动一个监控agent，实时监控mysql的binlog日志，同时在mongodb的服务器端也起了一个服务端，agent监控到数据变化后传送给服务端，服务端解析后插入到mongodb集群中以达到实时同步的效果，如上图，当初写了一篇文章来介绍：大数据实践-数据同步篇tungsten-relicator（mysql->mongo），其实这个工具在使用中，也不是特别的稳定，可是当初的选择方案并很少，幸亏后期慢慢的熟悉后算是稳定了下来。

数据清洗系统咱们大胆的使用了golang来开发，当时使用的golang版本是1.3吧，如今都1.8了，之前也是没有接触过也是锻炼了队伍，好在golang语言自己很是简洁和高效，虽然踩了N多坑，可是最终咱们仍是按时投产了；后来又使用了golang开发了一个后台，是在beego框架的基础上来作的。大数据分析系统后来又升级了一代，在前端的各业务系统，UI用户层作了不少埋点来收集用户数据，经过activeMQ传输接收最后存储到mongodb，在进行数据清洗，将清洗后的结果存入到结果库中，供前端业务系统使用；后来利用beego+echart从新作了一版数据分析系统。

大数据系统的架构图

由于后端数据库的压力不断增大，后端管理系统、业务系统均做了主从分离；后台管理系统增长缓存，启动了redis作缓存；使用nginx搭建了独立的图片服务器；第二代系统开发过程当中，也是公司发展最快的阶段，上线了N多的活动。

第二代系统架构图：

稍等总结一下：
第二代架构上线了各业务系统，作了主从分离，搭建了大数据平台为之后更多的数据处理提供了技术基础
缺点：各业务系统切分以后，各项目之间调用复杂；后台系统繁多、各系统之间有单独的帐户系统，运营须要来回切换完成平台运营监控

 

第三代系统架构

第二代系统开发完成以后，留给咱们了三个问题很痛苦，第一个是随着业务系统不断增多，系统之间的调用关系成指数级别上涨，在第三代系统初期，咱们又开发了不少基础组件，更是加重了这个问题；第二个问题和第一个问题相辅相成，系统之间调用关系太多，若是移动其中一个子系统，可能须要修改关联系统的配置文件，从新启动服务，常常由于更新一个系统，其它系统也须要被动更新，投产和出问题切换很复杂；第三个问题是咱们开发了不少的后台系统，可是帐户没有统一，每一个子系统有各自的帐户中心，运营和业务人员须要来回登陆才能完成平常工做，随着业务量增大这个问题也日益突出。

因而又开启调研、系统选型等，解决第一个问题就是引入SOA服务治理，经过服务的注册和发现解决系统之间的解耦，当时考察了不少，最后选型dubbo，缘由无它，有大量群众使用基础该趟的水的趟过了。解决第二个问题就是引入配置中心，当时调研了360的Qihoo360/QConf、Spring的spring-cloud-config、淘宝 的diamond、还有百度的disconf，最后纠结半天选定了disconf，完美和spring cloud擦肩而过，可是正是从这里开始让咱们注意到了spring-cloud、Spring-boot为第四代的架构选型作了基础，其实最后disconf也只是在少部分项目使用，也没彻底推广开；解决第三个问题就是帐户中心，使用了cas实现单点登陆，shiro作权限控制，dubbo来提供登陆后权限列表等服务端接口。

改造后的架构图

在这个基础上面，咱们又抽离出来不少基础组件，comomn组件处理共用的基础类，包含字符类、日期类、加密类....，搭建了fastDFS集群来处理文件系统，作了redis集群的测试；单独开发了定时调度系统，将全部的定时任务统一集成到调度系统，那个系统须要定时任务均可以在页面自动添加调度策略；前端PHP作了系统改造，主从分离、静态优化等

在后来，公司又启动众筹平台的建设，此次系统彻底采用java语言开发，app端采用混合开发模式，其中APP的全部一级页面所有采用原生开发，全部的二级页面都是H5+vue这种模式，后端所有采用dubbo作服务化，最终的架构以下：

图里面系统只罗列一部分，使用其它服务来代替

第三代系统启动了SOA服务治理，引入统一帐户中心、基础组件；缺点是开发环境较复杂

 

第四代系统架构

人老是不知足，技术呢也老是但愿可使用最好架构体系，在三代系统架构的开发中，了解到了spring cloud和spring boot，在不断的学习以后，愈加的感受到springboot的便利性，快速开发的优势甚是喜好，spring cloud体系也彻底知足一个大型系统须要考虑的方方面面，微服务的概念不断的被提出来，以上为技术背景；另外一方面国家开始严格要求P2P公司必须与银行存管，分析了银行的相关接口后发现若是严格按照规则走，咱们的系统须要大改造，同时公司为了知足监管要求，又开发出白条相关产品也是一个大项目，趁着以上的两个背景，咱们决定在进行银行存管和白条项目的同时全面拥抱微服务。

至于为何咱们要抛弃dubbo转而全面拥抱spring cloud缘由有三，一、dubbo多年都没有更新了，spring cloud不断的在更新升级；二、dubbo主要作服务治理和监控，spring cloud几乎考虑了微服务所须要方方面面，好比统一配置中心、路由中心；三、spring cloud更是无侵而且完美和spring其它项目整合，开发效率更高。

既然选定了使用spring boot+spring cloud来改造，微服务技术选型这边就定了下来，那么如何开启改造呢，毕竟在进行新一代系统改造的同时也不能影响原有业务，其中最主要的问题就是最初的系统虽然都是按照分布式的开发模式来进行，因为老系统的缘由有的系统仍是共用了一个数据库，微服务要求每一个独立的子系统有本身独立的库操做，别的系统若是须要修改或者查询子系统的数据，须要根据服务间接口调用来获取。所以计划先重新开发的项目和须要改造的项目中启用springcloud项目，别的系统暂时先经过路由器模式来通信，最终的系统架构图以下：

在架构的这条路上面没有终点，变化就是永远的不变，架构的升级更是为了更好的支撑业务，两者相辅相成。

 

开源软件

在这几年中咱们也想对开源世界作一点点贡献，总共开源了两个软件：

generator-web

在项目中大量使用了mybaits，咱们对mybaits的generator作了改造，而且作了一个系统界面，方便根据相关参数自动生产相关代码（只须要设计好表结构，系统会自动生成mappper、Entity、dao层的代码），最后也开源了出来

generator-web

界面以下：

云收藏

为了锻炼技术学习springboot咱们开发了一个云收藏的开源软件，使用的技术主要是springboot/Spring data jpa/redis/thymeleaf/gradle，功能主要是能够帮助用户在云端收藏、分享和整理本身的收藏夹。

favorites-web

---

http://www.cnblogs.com/ityouknow/p/6276686.html