[Rainy开发笔记]Rainy的来因

原创
2016/04/27 10:23
阅读数 156

在日常的应用开发中一个很常见的场景就是文件的上传,如果我们只有一台服务器,那么往往问题比较小,只要把文件上传到某个应用服务器即可,静态资源的访问也使用类似于下图的方式进行,这是无论是仅仅使用应用服务器作为静态资源的负载,还是使用某些服务器如Nginix作为负载,只要约定好上传文件的路径和系统访问之间的关系即可,无须额外的配置和编码。

但是随着用户量的提升,我们的应用服务器,将会逐步的增加,那么静态资源的上传和部署就会逐渐的成为问题,如果我们继续使用类似于上图的方案,那么因为无法控制用户每次请求是否都能命中自己上传过文件的服务器,所以会有很大的概率用户取不到自己想要的图片,为了解决上传和访问的问题,很多系统采用类似于下面的方案:


应用服务器通过NFS来讲本地的文件汇总到静态服务器,然后由静态服务器提供静态资源的服务。除了NFS,还有rsync等方案都可以作为静态资源的同步解决方案,这时候文件系统的监控和同步就成了需要解决的问题的重点,NFS和rsync刚好能解决这个问题。(当然如果你的系统继续增加,上面的方案可能就再次会不适应,可能会使用NAS进行处理,或者使用CMS来统一进行静态资源的管理)

第二个图片就是产生rainy的原因,因为不论是NFS还是Rsync,都是linux原生的解决方案,也就是说控制在运维人员手中,程序的开发人员无法感知到该类解决方案的存在,这时候往往在进行问题分析和问题处理的时候因为第一个图片的主观带入而造成问题。同时因为这两种方案是linux原生的,对于运行时的参数调整,性能的优化以及资源的分配和控制都无法有很好的切入点,所以。。。

创造Rainy的目的就是为了提供类似于rsync或者NFS的解决方案,但是让这种方案可以给予开发人员更大的发挥空间,比如可以控制单位时间内的最大文件数目,同时并发的上传文件上限,文件名冲突等等等等可能在现实中遇到的问题。

Rainy的部署图跟上面的解决方案几乎完全一样:

只是使用Rainy你可以选择使用embed部署方案或者独立运行的方案,使用embed,rainy将会跟随你的应用服务器一起启停,保证没有任何的文件丢失,而使用独立部署则更加容易控制,如果需要动态的调整rainy的参数,那么你可以选择使用mbean或者配置文件等方案来实时调整,这一切都取决你自己的决定。

Enjoy It。


项目地址:

http://git.oschina.net/grom/rainy

展开阅读全文
打赏
1
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
1
分享
返回顶部
顶部