架构师训练营总结 -20200712

发布于: 2020 年 07 月 12 日

本周的课程我们了解了包括数据库的高可用方案,包括复制、分片等方案,同时由于对数据进行分片后在数据访问层面的逻辑会变得较为复杂,可考虑引入例如Mycat这样的分布式数据库中间件辅助进行开发。之后我们了解了CAP理论,并结合了几个主流的NoSQL框架了解了他们各自在面对扩容、故障转移、数据一致性等问题时是如何解决的。

对于数据分片,我们之前也有所尝试,不过因为由于业务量没有大到一定地步的缘故,因此对数据分片的要求并不高。我们面对的是类似互联网产品中“个人中心”部分的功能,用户量约1000万至1500万左右,但是同时每天每个用户会产生大量类似于订单之类的记录,平均每个人每天产生3-4条订单。因此如果不进行数据拆分,由于订单表容量过大,会使查询的响应时间变得无法忍受。由于需求上只要求保存用户近15天的订单数据即可,因此首先我们在数据库层面采用了表分区的方式(PARTITION TABLE),让每个自然日的数据落在同一个分区内,通过数据抽取等方式定时将数据转移至备份数据库进行备份并压缩后进行归档,同时超过15天的数据通过删除分区的方式直接进行删除,执行效率上会比直接删除数据操作时间要更短。但是这样每个分区中的数据量仍然过大,查询速度仍无法令用户满意,因此我们又额外采用了根据用户ID区间进行拆分的方式,将200万用户及其相关的所有数据拆分为一个数据库,由于用户访问自己的订单数据之前首先需要登录,因此应用程序可以明确知道用户的ID,并根据用户的ID将请求定位都不同的数据库分片进行读、写操作即可。

这个方案主要还是考虑到系统的潜在用户量并不是全国的所有用户,理论上用户量的上限只有1.5到2亿,因此采用了这种方式,主要还是考虑客户端程序在访问数据库分片的时候仍然可以通过数据库事务避免不完整交易,从而保证数据层面的相对一致性。客户端实现层面我们选择使用Spring提供的AbstractRouteDataSource抽象类实现对数据分片的切换,主要原因是开发成本较低。由于开发框架较为陈旧因此采用的仍然是war包部署在WEB容器中运行的方式,通过统一的部署脚本规范发布时将war文件保存在服务器统一的路径,之后由脚本实现war文件拷贝、解压缩,并通过SCP从远程的配置服务器获取统一的配置文件覆盖war中的开发用配置文件,最后启动容器,这样保证了各应用服务器的配置文件统一,在增减数据库分片的时候主要改动配置文件服务器上保存的副本,并重启各应用服务器即可。

但是此方案的隐患也很明显:首先从发布上仍然需要重启服务,虽然可以提前上传新版本的war文件并通过脚本相对自动化的执行部署,但是由于需求所限仍然需要在深夜才可进行重启容器的操作,因此操作人员在发布当天的睡眠情况无法保证;其次,虽然用户的各种数据被分摊到了相应的数据分片中,但是作为入口用户数据,包括登录时需要的用户名、密码、手机号等信息仍然保存在一个独立的数据库实例内,所以如果用户量继续上涨,虽然可以通过索引、缓存等方式尽力提高访问性能,但是仍存在数据量过大且不便于拆分的问题,这一点还需要后续继续思考解决方法。本周课程中提到的分布式数据库中间件是我之前一直没有了解过的,不知道是否有助于解决此类问题,可以抓紧了解一下。

本周六提到的CAP理论及各种NoSQL框架如何应对各种挑战,由于知识和经验所限目前个人仅停留在记住框架名称、大致了解特典的层面。我们目前进行开发的时候关系型数据库仍然是绝对的数据存储方式,截至目前只粗浅的接触了elasticsearch,没有接触过NoSQL产品,所以感觉此部分知识也需要补充,不过感觉最迫切的问题还是先解决“为什么要用NoSQL”这个问题。我在数年前了解到的信息是NoSQL只是做为关系型数据库的补充,因此个人理解在使用NoSQL的时候仍然要在关系型数据库中保存一份数据做为基准,只是对于复杂性的对象(如完整的订单数据,包含商品、价格、优惠等关联信息)由于访问时需要访问多个数据库实例,因此可以通过K-V形式保存在NoSQL中,访问的时候直接通过NoSql进行读取减轻对数据库层面的压力。但是近几年也听说到有些应用放弃了关系型数据库,直接使用NoSql做为数据存储。因此个人感觉到有些混乱,在无法确定具体的设计方案之前不敢轻易使用新的中间件,毕竟对中间件的运维工作也是相当大的课题,首先就会在运维部门层面遇到阻力,需要一个较充分的理由说服业务部门和兄弟部门接受新的技术以及新的工作。

本周的课程中老师也简要询问过参加本次架构师训练营的目的,个人参加本次训练营最根本的目的就是想参考下其它企业如何进行架构选型,如何使用各个中间件,希望能为后续在自己公司内部引入新技术的时候找到充分的依据。此外也希望能够了解其它企业日常开放工作的方式,如何开发、如何部署、如何维护,怎么解决应用服务器重启这个痛点,能够让自己少熬一点夜,毕竟年纪大了身体情况也越来越差,已经越来越承受不了深夜发布对身体的负担,希望找到能让自己解放出来,符合目前自己公司情况的解决方式。也希望老师能在后续讲解大厂架构案例的时候能够多描述一些“为什么选择/为什么不选择某个中间件”、“大厂日常开发-发布-维护的流程”这样的内容。

用户头像

caibird1984

关注

还未添加个人签名 2018.04.28 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营总结-20200712