作为如何构建现代软件的一个很好的参考,我强烈建议阅读twelve factor app.

脚本和代码不是这样复制的,而是“释放”到应用服务器(您也可以通过释放所有服务器并使用其他机制(例如符号链接)从旧代码切换到新代码来填充服务器).

但是,客户端经常具有“状态”,如果应用服务器要正确地提供请求,则可能需要记住这些“状态”.

一般来说,要使应用服务器可以横向扩展,您希望它们尽可能“无状态”.这意味着应用服务器没有任何东西可以记住,它全部存储在外部,并且除了请求中收到的数据之外,任何请求都可以完成.但是,您的客户端(Web浏览器)通常需要状态,例如登录,因此您需要能够以某种方式处理状态数据.

一种解决方法是使用在负载均衡器上实现的“粘性会话”.通常,这是通过注入一个cookie来实现的,负载均衡器使用该cookie来记住应该将请求发送到哪个服务器.这很容易实现,不需要更改代码,但是有一个相当大的缺点,即每当您重新启动应用服务器时状态都会丢失.

另一种方法是通过将所有内容存储在cookie中来使app无状态.我根本不建议这样做,因为状态数据将在每个请求上传.客户端也可以修改这些数据并做出意想不到的事情,如果有人捕获cookie,可能会产生巨大的隐私隐患.

这些都不能解决磁盘上的文件问题,因为它们依赖于用户可能丢失的cookie,或者他们只能从其他地方登录.

最后一种推荐的方法是将客户端状态存储在数据库(或密钥：值存储)中,以便任何应用程序实例在收到请求时都可以查询它.您仍然需要客户端记住“会话ID”,但它更安全,因为客户端存储的数据更少.传统上,具有一致散列的memcached节点集群将执行此角色,但是现在有更强大的解决方案,例如Redis.

关于磁盘上的文件 – 不要在应用服务器磁盘上存储任何内容,除了可以作为部署的一部分“释放”的应用程序代码和静态资产.日志是一个可能的例外,但将它们推送到远程syslog服务器或类似logstash之类的东西总是更好.

如果您的应用程序必须存储文件(例如客户端上传的文件),请将它们存储在某种数据存储中(Cassandra不是一个糟糕的选择),某种存储服务,如Openstack的swift或Amazon S3,如果你不是足够大以证明自己做这件事.

如果应用程序规模较小并且您正确处理文件锁定,则NFS或samba共享也可以正常工作,但我建议您在沿着此路由前再使用Amazon S3.