原文选自Wordpress的留言问答,提问者是bsmoo。 问题: 我一般采用的解决方案就是下面这样:
我的问题是:
回复1:Zm3tta: 我们托管了大约2000个WordPress实例,目前正在进行架构升级,以获得可扩展性与安全性的提升。应用服务器的CPU利用率是主要的瓶颈,我们希望能在需要时,快速在资源池中部署新的应用服务器。 我们使用Nginx Web服务器来处理静态内容请求、所有vhost路由、Redis缓存以及php请求的负载均衡。通过Nginx的iphash设置定向到多台应用服务器上,从而可以为Redis缓存设置最小规则,并以相对透明的方式来处理会话。 针对文件复制的问题:利用NFS4将各网站的doc-root安装到应用服务器上,这样无论哪个节点的内容有修改,都能立即发现。我们使用PHP-FPM数据池监听多台应用服务器,从而使得扩展应用服务器层非常简单与快速,可以按需求向多台或几台服务器执行资源请求的分发。并在最后设有独立的数据库服务器,针对未能缓存的内容请求作出回应。 虽然彼此的架构差别很大,不过至少可以做些了解。
回复2:csmicfool 我们有个大型的WPMU网络(3000多个网站),使用NFS挂载上传目录,无需担心用rsync同步的问题,也无需设定“管理”或主/从服务器,所有虚拟器地位相同,从而使得按需扩展更合理。这种方式比我们原本的预期更为有效。 在NFS服务器上,我们使用rsync将上传的内容增量复制到另一个(用s3fs)装有S3 bucket的文件夹中,因此存有离线留存和冗余副本。切记:不要在web服务器上使用s3fs来处理目录。 想要节省开支,可以在管理页面强制使用SSL,并且只开启节点上的SSL,然后通过rsync或类似的方式来执行从管理到其他网页的分发。
回复3:springer70 这里分享一则Joomla网站托管实例,事实上在wordpress上,原理是相同的。 我们使用Elastic Beanstalk托管到亚马逊上,根据需求和流量执行向上/向下的扩展都很简单。一开始网站流量很低,公司进行大规模宣传之后,流量猛增。因此使用弹性架构就非常有用。 我们有一个负载均衡器,将流量引导到可用的前端服务器池中。在这些服务器上设有应用作为zip文件的容器,在需要新服务器时,只要执行部署,zip文件就会解压并部署到新服务器上。这就代表着(你提到的)文件上传很棘手。我们使用独立的云存储来管理媒体和上传(亚马逊s3),并使用插件将用户的上传内容导入s3存储中,而不是存在本地文件系统中。(有趣的是:媒体的这种通用存储对于开发/staging/qa/生产环境来说尤其有用,因为它们全都使用同一个存储文件系统)。 我们还有个中央单一数据库,不保留实时冗余副本;一份故障转移备份,最多5分钟就能恢复生产环境。 这个解决方案不算便宜,我们有:
我们在数据库中管理会话,因此如有用户从一个前端服务器换到另一个,会话就会被保留。还有备选方案,就是使用“粘滞会话(sticky sessions)”——强制用户一直停留在同一台前端服务器上。 我们的复制计划非常简单,因为没有真正复制任何东西。前端服务器将zip文件保存在应用中,因此也不包含“真正的”数据。所有数据都在S3或数据库中。 结果性能很不错,我们的前端服务器速度很快,由于存在一些前端缓存,数据库(mysql)很少使用(相对而言)。我们使用的所有服务器都“很小”或“超级小”,因此无需性能特别强大。抱歉写了一大堆东西。 回复4:applextrent 我们在WPdocker.com是使用SaaS平台和云服务器管理器作为通用的容器管理方案。使用补丁管理来解决更新的问题。关于容器可以查看这里获取更多详情。 |