儒猿自研的中间件项目,被风投看上了!

6,906

目录

  • 背景
  • 架构设计
  • 文件传输协议
  • 分块传输设计
  • NameNode联邦架构
  • 线上性能参数回放
  • 生产环境下的问题盘点

背景

事情是这样的,在我主讲的儒猿架构课里,有一个项目是带着学员们从零开始,自研一个生产级中间件【支撑一亿图片的分布式海量小文件系统】

当时我讲完这个项目,技术团队部署到生产环境,并做完一系列压测后,就把项目代码和压测报告开源到了码云上: 儒猿中间件 - 自研分布式小文件存储系统

突然在一段时间后的某一天,某风投机构VC投资人员联系询问【分布式海量小文件系统】否考虑商业化。

image.png

不过笔者最后还是婉拒了,暂时不打算融资和商业化,对这个中间件课程感兴趣,想加入开源社区的同学,可以扫面二维码(Giotto1245),我们一起来迭代这个项目。

可能很多对儒猿还不了解的同学对于这个自研分布式海量数据小文件系统还不熟悉。那接下来我就给大家介绍一下这个小文件系统到底是什么?如何做的架构设计?具体用了哪些技术?生产部署时遇到了哪些问题以及怎么解决的?接下来简单给大家介绍一下。

架构设计

分布式海量数据小文件系统的架构主要包括了:

  • 高并发架构

  • 高可用架构

  • 高性能架构

  • 可伸缩架构

    等几个方面,项目整体架构如下:

image.png

文件传输协议

在集群中会有几种场景需要进行文件传输,比如上传、下载文件是客户端和DataNode之间进行文件传输,BackupNode和NameNode之间也要进行FsImage的文件传输。

所以我们设计了一套文件传输的协议。文件传输的网络包包括 包类型、文件元数据、文件内容二进制数据

image.png

分块传输设计

为了解决消息传输太大,传输效率低问题,我们设计了分块传输协议。假如服务端写回的请求响应较大(超过最大消息长度),此时可以根据请求是否支持分块传输来决定是否需要拆包传输,可以将1个包拆分为n个包,然后传输给NetClient, NetClient收到包的时候,会根据一定的机制判断整个包是否传输完整,当收到了所有的响应包之后,再将所有的响应包合并成一个包,然后返回给用户。

image.png

NameNode联邦架构

为了解决大规模海量小文件带来的内存增长压力,开发了NameNode的联邦架构,简单来说,就是通过多个NameNode节点组成集群,每个NameNode节点保存整个内存目录树的一部分数据

image.png

线上性能参数回放

完成项目开发完成后,我们对文件上传下载的瞬时QPS,JVM,网络、IO、CPU等做了全链路监控。

image.png

image.png

生产环境下的问题盘点

项目部署在生产环境后,我们曾经遇到过以下一些线上问题。这些问题都已修正调试完毕并均做了详细的故障记录、分析,整理成了一套文档。

  • OOMKiller杀死spring boot发压程序

  • 带宽打满导致请求响应超时问题

  • DataNode流量不均匀问题

  • 线程数过多导致的 CPU 100% 问题

  • NameNode上传文件请求在吞吐量和一致性之间的抉择

  • 刷磁盘导致吞吐量大幅下降如何优化

END

惊喜

image.png