回想起从公司成立敲出的第一行代码算起到现在也快三年了，平台的技术架构，技术体系也算是经历了四次比较重大的升级转化（目前第四代架构体系正在进行中），临近年底也想抽出时间来回顾一下，一个小公司从最开始的零交易到现在交易量超过百亿背后的技术变迁。 在互联网金融行业一百多亿其实也算不上大平台，也就是二级阵营吧，其实每次的架构升级都是随着业务重大推进而伴随的，在前一代系统架构上遇到的问题，业务开发过程中积累一些优秀的开发案例，在下一代系统开发中就会大力推进架构升级。一方面可以平滑过度，一方面公司资源可以大力支持，同时技术的小伙伴们可以使用到前沿的技术，更有开发的成就感，就这样我们大概也就是9个月就行系统架构一次升级，就到了我们现在的这套架构中。 很多网友经常会问，你们平台的TPS是多少呀，最大并发是多少呀，性能怎么样，说实话我们是一个小公司，最夸张也就上万人同时抢标，但是做为一个中型的互联网金融平台要做的事情也真的不少，远远不只是这些参数可以说的清楚；我们也不是什么高大上的平台，使用的技术也是目前比较主流开源产品，但在公司不断发展的过程中也遇到了很多的问题，也尽量去使用比较主流的、开源的、适合我们的一些解决方案来构建整个系统，在这里分享平台发展背后技术换代的变化，同时希望和大家多做一些交流，多提一些建议。 我们进行了四次大的架构变化，每代架构都用一句话来总结：
下面做详细介绍。 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的集群中，利用MongoDB的MapReduce技术来处理大量的数据，于是我们的数据库层就变成下面的这个架构： MySQL实时同步到MongoDB，我们使用的是tungsten-relicator这个工具，会在MySQL服务器端启动一个监控Agent，实时监控MySQL的binlog日志，同时在MongoDB的服务器端也起了一个服务端，Agent监控到数据变化后传送给服务端，服务端解析后插入到MongoDB集群中以达到实时同步的效果，如上图。 当初写了一篇文章来介绍：《大数据实践-数据同步篇tungsten-relicator（MySQL- |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
