分离数据服务器、内容服务器、客户端服务器和后端服务器。

Question

最近几年，我公司的实践是在客户端的服务器/主机上安装我们自己的cms，并开发前端。但现在是改变我们工作方式的时候了。现在我是这样想的。内容服务器很少，客户端服务器(前端)一台，后端服务器一台，数据库/数据服务器一台。

后端应用程序和服务器

每个客户都可以访问一个后端应用程序。只有一个后端，它将在数据服务器上存储数据.后端/前端将请求数据，数据服务器从mysql数据库中准备json数据，然后将其发送回客户端。内容将临时上载到后端服务器，然后内容服务器将临时内容复制到多个内容服务器。

前端

前端服务器上不会有数据库/数据。前端网站、应用程序、移动应用程序将通过json从数据服务器/api获取所有数据，或者从内容服务器获取任何内容。因此，在前端服务器上只有前端脚本。

内容服务器

它不像CDN，所有的内容服务器都放在一个地方。连接和同步。

数据服务器

将所有数据存储在mysql数据库中。还有从mysql数据库中准备json数据的api。

现在的问题是：

1. 这种结构是愚蠢或正确的方式管理数百个网站和应用？
2. api从mysql数据库中准备json数据并将其发送回请求的应用程序是缓慢的吗？还是正常？
3. 分离的内容服务器(不是CDN，但它将创建内容缓存)可以比在一个请求中从一个服务器加载内容和脚本更好、更快。
4. 客户端访问前端服务器->前端服务器请求到数据服务器->数据服务器将准备json数据从mysql db ->发送回前端->浏览器获取内容服务器->呈现网站的内容，app。这种方式比一台服务器更慢还是更快？
5. 我们的后端必须非常快和非常酷。任务是实时应用，返回历史，url没有散列标签，当url改变时，浏览器不会刷新，不会损害后端应用程序媒体播放器(许多小工具)、实时通知和消息。我们应该为这个应用程序使用什么技术？请根据你的经验回答。

Answer 1

您的设置绝对正确，多个面向前端的客户端服务器，指向一个或多个集中化数据服务器，通过JSON在线路上传递少量数据。

拥有集中化后端应用程序也是有实际意义的，从维护的角度来看，您只处理一个应用程序。如果计划将所有数据存储在一个全局数据库中，或者为每个应用程序创建一个单独的数据库实例，则需要考虑。

问题是，您的应用程序/网站是否维护会话信息，如果是这样的话，您需要考虑如何处理会话。此外，如果您计划将负载均衡器以及适当地分配负载。

根据我个人的经验，我对会话的对话不能说太多(我的想法是将会话存储在数据库中)，但也许其他人可以对此有所了解。

在技术方面，我肯定会研究一些技术，如AngularJS或淘汰赛 --这些框架对于构建客户机/服务器应用程序非常有用，类似于您的需求。

希望至少能帮助你朝着正确的方向前进。

Answer 2

我在用这个堆做些类似的东西

后端服务器- mongo、mariadb、nodejs前端服务器- nginx，代理后端请求

我认为你走的路是对的。

因此，我们可以有很少的后端nodejs进程(在很少的vps上)，使用redis作为统一的会话存储和状态保存中间件，并且所有的前端- css、javascripts、映像、html都由多种nginx服务器提供。

在前面有一个nginx服务器作为负载均衡，我们也使用nginx作为负载均衡器，因为磅负载均衡器(http://www.apsis.ch/pound)在websockets上有问题，但速度要快一些。