从公司成立到敲出第一行代码，已经快三年了。平台的技术架构和技术体系也经历了四次重大升级（第四代架构体系正在进行中）。本文将带大家回顾一家小公司从一开始的零交易到现在交易量过百亿的技术变迁。在互联网金融行业，超过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用于二级市场的转账撮合等异步消息通知。项目部署：使用Apache部署PHP，定时服务使用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服务器端启动一个监控代理，实时监控MySQL的binlog日志。同时在mongodb的server端也架设了一个server。代理监视数据变化并将它们发送到服务器。服务器解析后，将它们插入到mongodb集群中，实现实时同步。我们大胆使用golang开发了数据清洗系统。我们当时用的golang版本是1.3，现在是1.8。我们以前没有接触过，也算是锻炼团队。幸运的是，golang语言本身就非常简洁高效。虽然踩了很多坑，但最终还是按时投产了。后来我们用golang开发了一个后台，是基于beego框架的。大数据分析系统后来升级到另一代。在前端业务系统和UI用户层，做了很多埋点，收集用户数据，通过activeMQ收发，最后存入mongodb。然后进行数据清洗，将清洗后的结果存入结果库，供前端业务系统使用。后来使用beego+echart创建了新版的数据分析系统。大数据系统架构图如下：由于后端数据库压力不断增加，后端管理系统与业务系统主分离，后端管理系统增加缓存，启动redis做缓存，使用nginx搭建独立的Imageserver。在二代系统的开发过程中，也是公司成长最快的阶段，先后推出了N多活动。二代系统架构图如下：二代架构上线了各种业务系统，主从分离，搭建大数据平台，为未来更多的数据处理提供技术基础。缺点：各业务系统划分后，各项目间调用复杂，后台系统多，各系统之间有独立的账户系统，需要来回切换操作完成平台运行监控。第三代系统架构第二代系统开发完成后，给我们留下了三个非常痛苦的问题：随着业务系统的不断增加，系统之间的调用关系成倍增长。在三代系统初期，我们开发了很多基础组件，加剧了这个问题。第二个问题和第一个问题相辅相成。系统之间的调用关系太多。如果移动其中一个子系统，则可能需要修改关联系统的配置文件并重新启动服务。通常，因为更新了一个系统，其他系统也需要被动。更新、推出和回退开关很复杂。我们开发了很多后台系统，但是账号不统一。每个子系统都有自己的账户中心。运营和业务人员需要来回登录才能完成日常工作。随着业务量的增加，这个问题也越来越突出。于是我们开始研究、系统选型等，解决了以上三个问题：第一个问题的解决方案是引入SOA服务治理，通过服务注册和发现来解决系统间的解耦。当时我们考察了很多，最后没有其他原因选择了dubbo。有大量的人使用它，所有的水都被涉过了。第二个问题的解决方案是引入配置中心。当时考察了360的Qihoo360/QConf，Spring的spring-cloud-config，淘宝的diamond，百度的disconf，折腾了半天终于选择了。Disconf、perfect和springcloud擦肩而过。但正是从这里我们注意到spring-cloud和Spring-boot为第四代架构选型埋下了伏笔。其实disconf最后也只是在小部分项目中使用，并没有得到全面推广。第三个要解决的问题是账户中心，使用cas实现单点登录，shiro控制权限，dubbo提供登录后的权限列表等服务端接口。修改后的架构图如下：在此基础上，我们提取了很多基础组件。公共组件处理公共基础类，包括字符类、日期类、加密类……，并构建了一个fastDFS集群来处理文件系统。测试redis集群。自主研发了定时调度系统，所有定时任务都集成到调度系统中。系统需要的定时任务可以在页面自动添加调度策略；前端PHP经历了系统改造、主从分离、静态优化等，后来公司启动了众筹平台的建设。本次系统完全采用Java语言开发，APP端采用混合开发模式。其中APP一级页面全部采用原生开发，二级页面全部采用H5+vue，后台全部由dubbo服务。最终的架构如下：上图中只列出了系统的一部分，因为如果服务太多，就用其他服务来代表系统的其余部分。第三代系统启动SOA服务治理，引入统一的账户中心和基础组件。缺点是开发环境比较复杂。第四代系统架构的人总是不满足，技术总是希望用最好的架构系统。在第三代系统架构的开发中，学习了springcloud和springboot。经过不断的学习，越来越感受到springboot的便捷，非常喜欢它开发速度快的优点。springcloud系统也完全满足了一个大型系统需要考虑的方方面面。微服务的概念不断被提出。以上是技术背景。另一方面，国家开始严格要求P2P企业接入银行存管。在分析了银行的相关接口后，我们发现，如果严格按照规则来做，我们的系统需要进行大的改造。同时，公司开发了白条相关产品以满足监管要求。也是个大工程。利用以上两个背景，我们决定在开展银行存管和借条项目的同时全面拥抱微服务。我们之所以放弃dubbo，全面拥抱springcloud，原因有三：Dubbo多年未更新，springcloud不断更新升级；dubbo主要是服务治理和监控，而springcloud几乎考虑了微服务需要的所有方面，比如统一配置中心，路由中心；springcloud非侵入式，与其他spring项目完美结合，让开发更高效。既然选择了使用springboot+springcloud进行改造，微服务技术的选型已经尘埃落定，那么如何开始改造呢？毕竟，在进行新一代系统改造的同时，不能影响原有业务。最重要的是问题在于，虽然最初的系统是基于分布式开发模型。由于旧系统的原因，部分系统仍然共享一个数据库。微服务要求每个独立的子系统都有自己独立的库运行。如果其他系统需要修改或查询子系统的数据，则需要根据服务间接口进行调用。要得到。所以打算从新开发的项目和需要改造的项目开始springcloud项目。其他系统暂时通过路由器方式进行通信。最终的系统架构图如下：结语在架构的道路上，技术没有止境，变化永无止境架构的升级是为了更好的支撑业务，两者相辅相成。微服务、动态化、自动化是未来金融机构架构的发展趋势。
