我现在接触的项目是个在线自助建站系统（不提供下载安装的）。我了解到采用的方式是分到两台服务器，服务器A只保存静态页面和数据（网站访问的时候带有“？”号问，不完全是静态，例如：.../index.php?mdl=list），服务器B处理每一个在这建站系统搭建的网站的任何操作。就是说，无论是建个新网站，还是在网站添加数据等任何操作都要在服务器B处理好，点击发布网站，生成新“静态”的网站到服务器A。
我觉得有个超不好的地方，就是无论什么操作，都要发布网站才能看到。我问过开发，能不能不要“发布网站”费时又麻烦，他说这个系统的机制就是这样。而我了解过的系统，都由独立的，不会由一个大的总的控制下面全部，改什么就有什么，不会两个服务器之间交互。就算是博客、QQ空间等，在线自助建的，也不用发布网站。
我十分的疑问：
1、不是每个网站独立系统控制，而是一个主控制下面每网站每操作，要“发布网站”这种方式有什么好的地方？或者是有好处，而我接触的这个系统没完善？
2、所有处理都在服务器B，服务器B会不会容易造成超负荷？如果建10000个网站，这个机制能行吗？
我不是做软件开发的，有点菜，不会讲专业术语，表达不清多多谅解，还请各位相助解疑~~
如还需要具体我再补充补充。
这样的设计思路个人觉得其实很好。
在应用的设计上，采用应用管理应用，而不是人手工管理应用。在Tomcat中，其实设计架构挺相像，我们可以进入Tomcat的管理中心，来发布Web应用，并进行其他的一些参数配置。当进行Web请求时，也是交由tomcat进行编译处理。上面提到的设计就是这样，主要是进行了职责的划分。只有涉及建站的请求、配置、发布时，才会用B做请求处理；而用户访问自己的应用（也就是自行搭建的网站）时，交由A处理。同时，这样也能够保证更高的安全性。
在应用的物理部署上，采用多个服务器，其中一个部署子应用，在问题中即是所谓的A，用户自助建站所产生的网站应用，会有很多个；另外一个用户部署管理子应用的应用，也就是B，负责处理用户建站请求、配置、以及发布。
也没啥不好的,确实是跟机制相关.静态生成网页确实访问性能上会优化很多,但是的确会失去一部分实时性.其实可以两者结合起来做.比如首页上的内容可以做成静态生成,用户进行管理模块不采用静态生成,只是举个例子说明.