百度BAE的NFS功能有点蛋疼

2013-07-26

百度云LOGO

为帮助开发者提高应用兼容性、降低迁移成本,百度BAE于近期提供了NFS分布式读写功能,BAE执行环境会截获所有开启分布式读写功能的应用,将写至应用目录下的数据实时发布至集群其他所有机器上,下次请求时不管请求落到哪台机器,都可读取。尽管NFS功能一定程度上解决了本地I/O的写问题,但是我认为,这个功能太鸡肋了,不足如下:

第一、支持不完善。开启NFS功能后,一些程序依旧无法运行。我曾尝试在BAE环境下安装轻量级论坛程序Xiuno,但是安装时会报500错误;另外,在上传原版WordPress程序后,安装过程中会出现错误而导致安装终止,即便通过其他方法安装成功,附件依然不能上传。此外,有网友称,开启NFS功能后,BAE中的文件既可以上传也可以删除,但文件夹只能创建而不能删除,也算是一个BUG吧。

第二、性能不高。根据NFS的原理,所有上传的文件会被同步到集群中的其他服务器,一份数据也就会被复制成若干份存储。且不论数据是否有必要保存多份,一旦服务器负载过高,该功能是否会影响I/O读写性能,实在难说。

第三、不适合规模应用。正因为性能不高,耗费资源巨大,所以官方为NFS系统设计了近乎苛刻的读写限制。官方的配额限制规定,每分钟写操作次数不超过50,数据量不超过10MB;每天写操作次数不超过500,数据量不超过100MB。如此一来,用BAE跑个博客还行,要是跑个论坛,人家都不用攻击你,只上传几个附件就让论坛玩完了。另外,对于上规模的应用,不断上传的文件势必会导致代码空间空间的不断膨胀,BAE的可扩展性难以保障。

第四、不容易管理。大家知道,BAE是通过SVN或者Git来管理代码空间的。而通过HTTP方式上传的文件不属于SVN/Git的一部分,所以就不能通过SVN/Git将文件导出。一旦将来需要将应用从BAE转移出去,或者对上传数据进行备份,都将是一件很麻烦的事情。

第五、安全问题。新浪SAE不支持本地I/O写的原因之一就是安全问题,支持本地I/O写操作后,一旦程序出现漏洞,攻击者可以将可执行代码上传到代码空间从而获取更高权限,这比禁止写操作危害要大得多。

第六、不利于和BAE其他服务配合使用,不能充分发挥Paas云计算的优越性。支持NFS功能的百度BAE无异于一台虚拟主机,人们完全没必要去修改现成的程序来支持百度云缓存、云存储等其他云服务。如此一来,不仅不利于程序性能的提升,也不能充分发挥BAE相较于虚拟主机的优点,还会给BAE执行环境带来不必要的负载。

与其花大力气支持NFS,倒不如学习下新浪SAE,巧妙利用wrappers来使用BAE的其他服务。如此一来,不仅大大减少了程序移植所带来的麻烦,而且很大程度上提高了系统性能。当然,新浪SAE的wrappers设计并非完美无缺,其采用的是加协议头的方式(如加上”saemc://”表示访问MemCache),这样就导致了我们必须手工修改程序中所有涉及地址的变量。

我更建议BAE采用文件夹映射的方式来使用wrappers服务。例如,我们可以指定/BaiduMemCahce/文件夹下的内容访问MemCache缓存,/BaiduStorage/文件夹对应某个设定好的云存储Bucket。如果这样的话,好多程序基本上就不用移植了,只要把临时文件夹对应于MemCache,公开持久化存储对应于BCS,私有持久化存储对应于NoSQL数据库,既完美解决了移植问题,也可以顺便提高程序性能,Paas云计算的优势就显露无疑了。当然,可以自定义文件夹映射就更好了!


除非特殊说明,本博客文章均为原创,转载请以链接形式标明博文地址。

本文链接地址: 百度BAE的NFS功能有点蛋疼

分类:互联网 | 标签: |