从公司成立敲出第一行代码到现在也快三年了，平台的技术架构，技术体系也经历了四次比较重大的升级(目前第四代架构体系正在进行中)，本文将带大家回顾一家小公司从最开始的零交易到现在交易量超过百亿背后的技术变迁。
在互联网金融行业一百多亿算不上大平台，也就是个二级阵营，它每次的架构升级都是伴随着业务的重大变化而推进的，在前一代系统架构上遇到的问题，业务开发过程中就会积累一些优秀的开发案例，在下一代系统开发中就会大力推进架构升级。
一方面可以平滑过度，另一方面公司资源可以大力支持，同时技术团队可以使用到前沿的技术，更有开发的成就感，我们大概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 集群中以达到实时同步的效果。
数据清洗系统，我们大胆使用了 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 来提供登录后权限列表等服务端接口。
改造后的架构图如下：
在这个基础上面，我们又抽离出来很多基础组件，common 组件处理共用的基础类，包含字符类、日期类、加密类….，搭建了 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 项目，别的系统暂时先通过路由器模式来通讯，最终的系统架构图如下：
结语
在架构的这条路上，技术没有终点，变化就是永远的不变，架构的升级更是为了更好的支撑业务，二者相辅相成。微服务化，动态化、自动化是未来金融机构架构的发展趋势。
