一.业务分析
此次案例中,我们面临的业务需求时,有一张mysql表里存储了千万级别的数据,每次业务流程结束,这张表中就会增加至少8万条数据,而我们的系统要做的就是把这些数据按不同的需求统计展示,在代码中有大量的复杂计算和复杂sql语句,,并且该系统的业务会经常发生变化,这让整个系统变得缓慢和难以维护,即使在使用redis作为我们的缓冲层,也无法很好的解决查询效率问题,毕竟第一次加载真的太慢了,在面临大量用户使用的时候,给我们的不管服务端还是数据库都造成了巨大的压力
二.现有技术栈说明
编程语言: JAVA
框架: spring cloud , redis , mybits , mysql ,nacos
以上的语言或者框架是我们在接手这个系统时大致上使用的东西
三.我们的架构方案分析
1.首先我们想到的是迁移数据,从MySql迁移到MongoDB,但是我们很快的否定了这个方案,因为大数据的迁移不仅仅是数据安全难度系数很大,迁移之后还对整个系统的业务接口都产生了巨大的影响,所有的mysql查询都需要更换为MongoDB查询,大部分业务接口的复杂计算需要重新设计或者修改,这让整个我们整个优化周期在第一步时就变得不稳定并且时间更长
2.优化redis,在这一层面我们想过在每次生产数据入库后,调用所有的业务接口生成查询数据存入到redis中,持久化redis能让我们保证这些数据不会被轻易的在mysql中反复查询(缓存穿透),但会让我们的redis承载大量的数据,当然这是被允许的,并且redis拥有许多优秀的集群方案,使用这个方案这让我们此次的优化变得侵入性较低,并且后期只需要维护调用每个接口的程序,于是优化redis成为我们的首选项
3.就在我们准备使用优化redis的方案时,我们又对代码的可维护性和频繁变更的业务需求产生了想法,如果我们仅仅是使用了redis,那我们在面对频繁变更的业务需求时就需要维护两套代码,一套是业务代码,另外一套就是我们的调用接口把数据放入redis的代码,当我们被这个问题困扰时,我们想到了使用搜索引擎,频繁变更的业务需求不就是百变的搜索条件吗,而我们的业务代码不就是为我们的搜索引擎提供搜索数据吗,在详细探讨后,我们觉得逐步替换掉现有的开发模式,让我们的系统变得易维护,查询更快,扩展性更强,下一章中,我会详细介绍拟定的方案。
四.架构方案
图中展示了我们拟定方案的三个阶段
第一阶段就是我们现在整体数据的流向
第二阶段是一个过渡期,也是本篇文章的重点
第三阶段是在经过过度期时,我们理想中的数据流向
方案说明:
我们会在过渡期把所有的查询数据放入到搜索引擎中,这是为了应对频繁更变的业务需求导致的查询参数频繁变化,在过渡期就算新增了业务接口或者业务接口数据结构发生变动,只用维护搜索引擎的数据,虽然在此时我们已经能够体会到搜索引擎带来的查询效率的提升,但是我们的目的不限于此。
在第三阶段我们会建立静态数据仓库,这是非常重要的一点,我们使用ETL工具来保证静态数据仓库的全面性,稳定性,降低代码的开发成本。之后我们会根据业务需求来拆分更多的‘业务表’,这些‘业务表’只针对一个或者几个业务,我们要做的就是把业务数据从静态数据仓库加入到‘业务表中’,每个接口都会有专属的‘业务表’,这让我们的系统业务变得简单,当我们需要改动一个业务接口时,维护者只用关心‘专属表’的情况,每当新增业务时,同样为这个业务新增‘专属表’,这一点不管是新来的开发人员或者维护人员,这让他们能够迅速的接手他们负责的业务,能够‘心无旁骛’地进行业务开发
方案技术选型说明:
搜索引擎:Elasticsearch
是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎,具有HTTP Web接口和无模式JSON文档。
使用它的好处是在我们的第三阶段,当我们的业务数据不再从一个数据源出发时,它能够为我们的多样化的查询条件建立索引,如果使用redis,我们可能在使用组合键的时候会发生重复等不可预先想到的问题,多样的搜索条件让能够匹配频繁变更的业务需求
ETL(数据抽取工具):Kettle
适用于将多个应用系统的大批量的、异构的数据进行整合,有强大的数据转换功能
高效适配多种类型的异构数据库、文件和应用系统
快速构建复杂数据大集中应用、无需编码
使用etl工具是为了让我们的静态数据仓库更加灵活和健壮,不需要更多的代码来维护我们的静态数据仓库
方案技术实操说明:
搜索引擎:Elasticsearch
1.过渡期,我们会把业务接口的结果集(json数据)直接放入到
Elasticsearch中。
Elasticsearch索引:
1.我们只会建立一个索引条件,param中的存储值,就是查询接口参数对象的hashCode加上url地址,而我们储存的对象只需要一个param加上data(data内是业务结构返回的json)
这让我们的搜索引擎在目前阶段的使用变得像redis,但是没关系,这只是一个过渡期,真正的使用需要建立在时间上
2.成熟期,当我们拥有了不同的‘专属表’之后,我们的索引就开始变得复杂,我们的 /{A条件}/{B条件}这样的索引会变得多起来,每个索引都只会服务于自己的业务接口,在变得复杂的同时,也相对比较简单
ETL(工具):Kettle
这个工具的使用,需要一定的时间积累,在这里我们之谈一谈它给我们带来好处,简化了数据来源的操作,维护人员只用专注于静态数据仓库的稳定,在保障其数据源时,业务表,业务接口的崩塌都不会影响到数据源,这让我们的架构更加稳定,从侧面来说,同时也增加了数据的安全性,因为对外暴露的接口都无法直接访问到源数据,数据经过业务的切分变得不在有更多的关系,这让入侵者很难找到漏洞
五.写在最后
我相信,这阅读这篇文章后,您会有更多的疑问,有太多技术和方案的细节,我说得不是很详细,但是由于一次性的汇总说明总是会有遗漏的地方,所以接下来,我们会针对这篇文章把大家的问题汇总,在后续文章中持续为大家解答,这篇文章不是结束,它只是个开始。
如若大家觉得感兴趣,请关注我的公众号,后续文章都会在公众号首发
下期内容预告:elasticsearch实操教程