一次架构失误的反思

我们公司的系统要做改造，以前是1台服务器，现在要换成4台服务器，我去的时候，运维已经把架构方案那些，都弄好了，都已经在测试了，大概架构如下:

请注意，这个和我们传统的架构是有区别的，nginx 和php-fpm分别是单独的二台服务器，php-fpm只做php解析工作，所有到nginx 的php请求,都会发给php-fpm,说实话我还是第一次，看到这种架构，节约资源，必竟少一个nginx嘛，一般都是nginx+php-fpm是在一台服务器上面的

运维当时的想法是所有的静态资源请求都到nginx服务器上面，实现分布式，图片上传又要用阿里云nfs,前期没有那么大的量，就暂时用这个，结果数据转移过去，下 午的时候,io读写频繁，根本没有那么大的访问量，服务器负载超高，用户无法访问，后面经过反复的思考，确定是nfs 的问题，然后，就改了架构，换成传统的nginx+fpm,先去掉nfs ，当然 也不是nfs的问题，当时为了解决前端的nginx访问时出了问题，才把php和用户上传的图片一起挂在了一起，先解决问题，去掉了nfs

转移图片过程出又遇到了图片资源太大，目录不够的问题，我以为运维挂的是/data目录，结果居然挂的是/data/public 目录,最近访问量太大，日志文件一下爆涨，当时设置的不是一人很大的目录，监控工具又没有上到,结果突然用户访问时报了一个错，去服务器看了看，发现磁盘满了，清了服务器的日志，然后又好了.

总结：

　　1.用户磁盘，io,cpu,内存那些，还是要上专门的监控工具

　　2.项目架构一定要用传统的,

　　3.对于要增长的数据，比如用户的访问日志一定要放到大磁上去，当然现在elk工具还是很流行，主要是还没有来得及上