从零到百亿互联网金融架构发展史 - 纯洁的微笑(2)_H5之家

因为后端数据库的压力不断增大，后端管理系统、业务系统均作了主从分离；后台管理系统增加缓存，启动了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项目，别的系统暂时先通过路由器模式来通讯，最终的系统架构图如下：