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-relicatormysql-mongo其实这个工具在使用中也不是特别的稳定但是当初的选择方案并不多幸好后期慢慢的熟悉后算是稳定了下来。数据清洗系统我们大胆的使用了golang来开发当时使用的golang版本是1.3吧现在都1.8了以前也是没有接触过也是锻炼了队伍好在golang语言本身非常简洁和高效虽然踩了N多坑但是最终我们还是按时投产了后来又使用了golang开发了一个后台是在beego框架的基础上来做的。大数据分析系统后来又升级了一代在前端的各业务系统UI用户层做了很多埋点来收集用户数据通过activeMQ传输接收最后存储到mongodb在进行数据清洗将清洗后的结果存入到结果库中供前端业务系统使用后来利用beegoechart重新做了一版数据分析系统。大数据系统的架构图因为后端数据库的压力不断增大后端管理系统、业务系统均作了主从分离后台管理系统增加缓存启动了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的所有一级页面全部采用原生开发所有的二级页面都是H5vue这种模式后端全部采用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 bootspring cloud来改造微服务技术选型这边就定了下来那么如何开启改造呢毕竟在进行新一代系统改造的同时也不能影响原有业务其中最主要的问题就是最初的系统虽然都是按照分布式的开发模式来进行由于老系统的原因有的系统还是共用了一个数据库微服务要求每个独立的子系统有自己独立的库操作别的系统如果需要修改或者查询子系统的数据需要根据服务间接口调用来获取。因此计划先从新开发的项目和需要改造的项目中启用springcloud项目别的系统暂时先通过路由器模式来通讯最终的系统架构图如下在架构的这条路上面没有终点变化就是永远的不变架构的升级更是为了更好的支撑业务二者相辅相成。开源软件在这几年中我们也想对开源世界做一点点贡献总共开源了两个软件generator-web
