四次大的架构变化，每代架构都用一句话来总结：
第一代架构特点：业务比较集中、功能满足投资理财需求、快速上线
第二代架构特点；分布式系统改造，平台化初具规模，各项垂直业务系统搭建上线、产品端极大丰富用户投资、大数据平台研究并使用
第三代架构特点；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原因有三：
1、dubbo多年都没有更新了，spring cloud不断的在更新升级；
2、dubbo主要做服务治理和监控，spring cloud几乎考虑了微服务所需要方方面面，比如统一配置中心、路由中心；
3、spring cloud更是无侵并且完美和spring其它项目整合，开发效率更高。
既然选定了使用spring boot+spring cloud来改造，微服务技术选型这边就定了下来，那么如何开启改造呢？
毕竟在进行新一代系统改造的同时也不能影响原有业务，其中最主要的问题就是最初的系统虽然都是按照分布式的开发模式来进行，由于老系统的原因有的系统还是共用了一个数据库，微服务要求每个独立的子系统有自己独立的库操作，别的系统如果需要修改或者查询子系统的数据，需要根据服务间接口调用来获取。
因此计划先从新开发的项目和需要改造的项目中启用springcloud项目，别的系统暂时先通过路由器模式来通讯，最终的系统架构图如下：
在架构的这条路上面没有终点，变化就是永远的不变，架构的升级更是为了更好的支撑业务，二者相辅相成。