回想从公司成立到敲出第一行代码，已经快三年了。平台的技术架构和技术体系也经历了比较大的四次（目前第四代架构体系正在进行中）。临近年底，我也想抽空回顾一下一家小公司背后的技术变迁，从一开始的零交易到现在的百亿交易量。总体介绍在互联网金融行业，100亿以上其实不算大平台，也就是二线阵营。事实上，每次架构升级都伴随着重大的业务进步。是上一代系统架构中遇到的。问题是在业务开发过程中已经积累了一些优秀的开发案例，在下一代系统开发中将大力推进架构升级。一方面可以一帆风顺，另一方面公司的资源可以提供强有力的支持，同时技术伙伴可以使用最前沿的技术，在发展中有成就感。这样，我们大概9个月左右升级一次系统架构，就到了我们现在的架构。经常有很多网友问，你们平台的TPS是多少，最大并发是多少，性能如何？说实话，我们是一家小公司，最夸张的是几万人同时竞标，但是作为一个中等规模的互联网金融平台要做的事情真的很多，这些参数远未明确；我们不是高端平台，使用的技术都是目前比较主流的开源产品，但是在公司不断发展的过程中我也遇到了很多问题，尝试使用更主流的、开源的、合适的解决方案来构建整个系统。在这里我将分享平台发展背后的技术变化。同时也希望能和大家多交流，多提建议。我们进行了四大架构变革，每一代架构都可以用一句话来概括：第一代架构的特点：业务相对集中，功能满足投资理财需求，第二代快速上线-生成架构；分布式系统改造、平台改造初具规模，各类垂直业务系统建成上线，产品端极大丰富了用户投入，大数据平台研究采用了第三代架构的特点；SOA治理以zookeeper为注册中心，dubbo为监控调度中心；cas实现单点登录，使用shiro控制四代架构的特性；全面启用微服务开发模式，springboot+springcloud技术作为第四代架构的技术支撑。下面详细介绍第一代系统架构。2014年应该算是互联网金融元年，之前很多互联网公司都是用各种模式生存，一直不温不火，但是2014年突然火了起来，首先是网贷家网贷等第三方网站天眼突然流量暴涨，紧接着就是媒体报道的不断跟进，然后各种互联网金融公司获得XXX元投资的报道越来越多，政策也逐渐明朗起来，很多大公司（组）也利用了这只股票。热潮随之而来，其中包括我们。第一代系统的主要目的是节省时间。该公司希望确保在最短的时间内推出该系统。当时移动端的浪潮已经开始，所以决定优先推出移动端，网站暂时可以不考虑。当时公司有PHP和Java两种开发语言技术，因为PHP在快速开发方面有很大的优势，所以决定采用前端PHP+后端Java的模式。系统分为三层：用户层：Android和IOS移动端；接口层：php提供用户和事务接口；backend：后台有两个部分，后台和计时系统。后台使用PHP开发和接口层共用一个系统，另一个是计时系统，负责计息、分红、到期等计时任务，使用java开发。对于基本的服务和中间件，mysql提供了最基本的主从支持。第一代系统只使用mysql的主库，从库只做同步备份；memcached用于处理用户抢标的并发问题，只用到这部分；ActiveMQ用于二级市场的转账撮合等异步消息通知。项目部署：php用apache部署，定时服务使用tomcat6作为应用服务器，lvs作为前端apache负载。基本上，第一代就有这些技术。下面是第一代系统的架构图。第一代系统上线后，网站和H5（手机浏览器或微信端）系统的建设尤为突出。作为一家互联网金融公司，实在无法忍受没有官网，于是马不停蹄的开始了网站和H5系统的开发。期间将PHP之前做的后台部分抽取出来，打算用java做一个新的版本。至此，PHP负责了网站、APP界面、H5这三个系统。三个系统共享一个核心事务，java负责后台管理和Timing服务，我们一般称这种架构为1.1代架构。第一代系统架构图，绿色部分为改动部分。第一代系统的缺点是业务过于集中，上线仓促，后期问题多。二代系统架构二代系统的背景是，随着公司业务量的快速发展，一开始欠下的大量技术债爆发，线上出现了很多问题。最严重的是重复给个人用户分红，各种骂还历历在目。另一方面，来自各个业务部门和公司产品的需求不断。因此，现阶段我们忙于解决各种生产问题，还需要开发垂直业务系统。那段时间，我几乎被逼疯了。第一代系统是以封闭方式开发的。回来后一直没缓过神来，反而又冲上去发动了。真是痛并快乐着。第一个垂直子系统上线：合约系统。当时，用户投标后没有合同。许多用户非常担心，因此将优先级提高到最前面。后来光是契约系统就改了三个版本。第一版只生成pdf，第二阶段在线电子签名，第三阶段加水印，自定义动态生成pdf；其次是积分系统的开发：用户邀请、投资等生产积分用于兑换现金券等；拉出消息系统：站内消息、短信、邮件等；在线监控系统，业务监控和服务监控，业务故障预警；各业务部门持续提需求上线财务系统：财务人员清点、核算金额；风控系统：监控异常用户、异常交易；开发销售系统进行销售；因为和很多第三方系统对接，所以开发了一个外部接入系统。第一代系统匆忙，产品界面简陋，然后开始规划网站2.0，APP2.0，H52.0。根据前端系统的需求，在后端开发了一个CMS系统，用于发布项目、公司公告等；二代产品端一般规划了很多大数据分析需求。全量数据分析后，官网会展示投资偏好和投资金额去向。前端用地图展示，会有个人日历，采集数据分析等的回馈，因为全量数据需要跑，计划的时候设计成离线处理，数据是从mysql数据库同步到mongodb集群，使用mongdo的mapreduce技术处理大量数据，所以我们的数据库层变成了如下架构mysql实时同步到mongodb。我们使用工具tungsten-relicator，它会在mysql服务器端启动一个监控代理，实时监控mysqlbinlog日志，同时在mongodb服务器端也架设了一个服务器。代理监视数据变化并将它们发送到服务器。服务器解析后插入到mongodb集群中，实现实时同步。如上图，我写了一篇文章来介绍：大数据实践-数据同步文章tungsten-relicator(mysql->mongo)，其实这个工具用起来不是特别稳定，当时的选择不多开始。好在后面熟悉了之后就稳定了。我们大胆使用golang开发了数据清洗系统。当时使用的golang版本是1.3，现在是1.8。坑了很多，但最后还是按时投产了；后来我们用golang开发了一个后台，是基于beego框架的。大数据分析系统后来升级到新一代。在前端业务系统中，UI用户层做了很多埋点来收集用户数据，通过activeMQ收发，最后存储到mongodb中。数据清洗后，将清洗后的结果存入结果库，供前端业务系统使用；后来又用beego+echart重建了新版的数据分析系统。大数据系统架构图由于后台数据库压力越来越大，后台管理系统和业务系统已经脱离master；后台管理系统添加了缓存，redis作为缓存启动；使用nginx搭建了独立的图片服务器；二代系统开发期间，也是公司成长最快的阶段，开展了N多活动。二代系统架构图：二代架构上线了各种业务系统，主从分离，搭建大数据平台，为未来更多的数据处理提供技术基础。缺点：各个业务系统划分后，各个项目之间的调用复杂；后台系统很多，各个系统之间有独立的账户系统。操作需要来回切换，完成平台运行监控。第三代系统架构。二代系统开发出来后，给我们留下了三个非常痛苦的问题。第一个是随着业务系统越来越多，系统之间的调用关系呈指数增长。在三代系统初期，我们开发了很多基础组件，加剧了这个问题；第二个问题和第一个问题相辅相成。系统之间调用过多。如果移动其中一个子系统，则可能需要修改关联系统的配置文件并重新启动服务。往往因为更新了一个系统，其他系统也需要被动更新、上线、回滚。切换非常复杂；第三个问题是我们开发了很多后台系统，但是账户不统一，每个子系统都有自己的账户中心。运营和业务人员需要来回登录才能完成日常工作。随着业务量的增加，这个问题也越来越突出。于是我们开始研究，系统选型等，首先要解决的问题是引入SOA服务治理，通过服务注册和发现来解决系统间的解耦。当时我们考察了很多，最后选择了dubbo。本应基本使用的水，大量人员涉水而过。解决第二个问题就是引入配置中心。当时调查了360的Qihoo360/QConf，Spring的spring-cloud-config，淘宝的diamond，百度的disconf。最终我们选择了很久的disconf。perfect和springcloud擦肩而过，但是正是从这里我们注意到spring-cloud和Spring-boot为第四代架构选型埋下了伏笔。其实disconf最终也只是在小部分项目中使用。尚未得到充分推广；第三个要解决的问题是账户中心，使用cas实现单点登录，shiro做权限控制，dubbo提供登录后的权限列表等服务端接口。修改后的架构图就是基于这个基础，我们提取了很多基础组件。comomn组件处理常用的基础类，包括字符类、日期类、加密类...，并构建了一个fastDFS集群来处理文件系统。Redis集群测试；单独开发了定时调度系统，将所有定时任务集成到调度系统中，系统可以在需要定时任务时自动在页面添加调度策略；前端PHP做了系统改造，主从分离，静态优化后，公司又开始了众筹平台的建设。本次系统完全采用java语言开发，app端采用混合开发模式，APP一级页面全部原生开发，二级页面全部采用H5+的模式Vue，后端使用dubbo作为服务。最终架构如下：图中系统只列出一部分，使用其他服务代替第三代系统启动SOA服务治理，引入统一的账户中心和基础组件；缺点开发环境比较复杂。第四代系统架构人总是不满意，技术总是希望用最好的架构系统。在第三代系统架构的开发中，学习了springcloud和springboot，也在不断的努力着。学了之后越来越感受到springboot的方便，喜欢快速开发的优点。springcloud系统也完全满足了一个大系统需要考虑的方方面面。微服务的概念不断被提出。以上是技术背景；一方面，国家开始严格要求P2P企业接入银行存管。在分析了银行的相关接口后，我们发现，如果严格按照规则来做，我们的系统需要进行大的改造。同时，公司开发了符合监管要求的白条相关产品。一个大项目，利用以上两个背景，我们决定在开展银行存管和欠条项目的同时全面拥抱微服务。至于为什么要抛弃dubbo，全面拥抱springcloud，原因有以下三点。1、dubbo多年未更新，springcloud不断更新升级；2、dubbo主要是服务管理和监控，springcloud几乎都考虑微服务。各方面都需要，比如统一配置中心、路由中心；3.springcloud更无侵入性，与其他spring项目完美集成，开发效率更高。既然选择了使用springboot+springcloud进行改造，那么微服务技术的选择就到这里了，那么如何开始改造呢，毕竟在进行新一代系统改造的同时不能影响原有业务，其中最重要的问题是，虽然原有系统是按照分布式开发模式开发的，但由于老系统，部分系统仍然共享一个数据库。微服务要求每个独立的子系统都有自己独立的库运行。其他如果系统需要修改或查询子系统的数据，需要根据服务间接口调用获取。所以打算从新开发的项目和需要改造的项目开始springcloud项目。其他系统暂时通过路由器方式进行通信。最终的系统架构图如下：架构这条路没有尽头，变化永无止境。架构升级是为了更好地支撑业务，两者相辅相成。开源软件这几年，我们也想为开源世界做点贡献。我们一共开源了两个软件：generator-web在项目中大量使用了mybaits，我们对mybaits的生成器进行了改造，搭建了一个系统接口，方便根据相关参数自动生成相关代码（只需要设计表结构，系统会自动生成mapper、Entity、dao层的代码），最后开源generator-web界面如下：，主要使用springboot/Springdatajpa/redis/thymeleaf/gradle等技术。主要功能是帮助用户在云端收集、分享和整理自己的收藏。favorites-web【本文为专栏作家《纯洁的微笑》原创稿件，转载请微信公众号联系作者获取授权】点此查看作者更多好文
