很多网友经常会问你们平台的TPS是多少呀最大并发是多少呀性能怎么样说实话我们是一个小公司最夸张也就上万人同时抢标但是做为一个中型的互联网金融平台要做的事情也真的不少远远不只是这些参数可以说的清楚我们也不是什么高大上的平台使用的技术也是目前比较主流开源产品但在公司不断发展的过程中也遇到了很多的问题也尽量去使用比较主流的、开源的、适合我们的一些解决方案来构建整个系统在这里分享平台发展背后技术换代的变化同时希望和大家多做一些交流多提一些建议。我们进行了四次大的架构变化每代架构都用一句话来总结第一代架构特点业务比较集中、功能满足投资理财需求、快速上线第二代架构特点分布式系统改造平台化初具规模各项垂直业务系统搭建上线、产品端极大丰富用户投资、大数据平台研究并使用第三代架构特点SOA治理使用zookeeper作为注册中心dubbo做监控和调度中心cas实现单点登录使用shiro做权限控制第四代架构特点全面启用微服务开发模式springbootspringcloud技术桟做为第四代架构技术支撑下面做详细介绍## 第一代系统架构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做服务化最终的架构如下