百度BAE的NFS功能有点蛋疼
2013-07-26
为帮助开发者提高应用兼容性、降低迁移成本，百度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的，起码WP程序可以安装插件，安装主题什么的，新浪的wp程序插件都不能安装，而且新浪绑定域名那个访问速度真的很慢且不稳定。