在不修改源程序的情况下如何增加整个 Web 系统的可用性以及负载能力？

PHP的话可以测试HHVM的兼容性。

不给出当前负载使用量就要求提升性能就是耍流氓啊……

@hjc4869 榨取服务器性能的想法是不错，但并不适合现在这个需求。。。
源码修改风险太高，未来将会重新开发，但现在并不会考虑要修改源码的情况，包括各种优化策略。。
另外其实现在瓶颈也不是在PHP上，主要是是担心服务器宕机而已。。
增加负载能力是为了未来扩展业务准备的

@msg7086 我也是这么说的，但是咱们没有服务器那边的数据（也难以获得），只能提出方案让服务器那边的人决定配置参数。。。
反正各种奇葩。。。

php的高可用的话，nginx做fastcgi的时候可以用多台机器轮询。

关键是不知道你这边数据库负载咋样。如果数据库慢的话很难优化的。

话说与其加机器不如把硬盘都换成ssd，保证给你飞一样的感受。

静态页面/热页面全部在nginx增加静态缓存

@msg7086 现在数据库查询也是飞一样呢。。。

暂时别纠结在性能上面。。
现在重点是可用性。。。
现在两台机子其中一台挂掉网站都得挂。。。
奇葩的架构。。。

@mhycy 常规的思想，一台nginx在最前轮（询）N台PHP服务器，PHP服务器连接后方的一台数据库/文件服务器，由于nginx的占用小，保证它稳定即可，现在需要做的就是尽可能提升数据库服务器的性能，比如换SSD等方法。PHP服务器都是容易scale的，轮询机制可以随时增添、删除，甚至可以使用简单的脚本来实现nginx端监控PHP服务器，可以暂时不轮down掉的服务器。
LZ说是5台，如果按这样的架构，自然就是1+3+1了，剩下的就是预算的问题了。性能方面怎么搭配，我也不太了解。

@hjc4869 同意这个想法
一台nginx+N台前端+单点数据源
这个想法现在不了解的数据源（数据库/数据）如何保证可用性，毕竟这也会存在单点故障的问题。
不太了解服务器热备方面的东西。。。

没有提供读写比例，没有目前负载的情况，没有业务类型的说明，就像提升性能真的是刷流氓啊。

1.读多写少，业务实时性要求不高，数据同步延迟在10秒左右的。
做分布式就足够啦
能读写分离的话，一台后端主数据负责处理写的请求，一台备机专门做数据同步留待容灾切换，其它数据库从机，其它从机同步数据和处理前端请求。这样核心数据都在两台主数据库上面。负载都在前面的从机。
2.读少写多，业务实时性要求不高
还是上面的方案，后端换成数据库集群增加写处理能力。
3.实时性要求高的
没听过用php处理实时性要求高的业务。

如果有钱，可以考虑用虚拟化的方案，其实虚拟机对切分业务和资源调度还是很有优势的，可以根据实际业务情况快速调整。比如数据库确实不够了临时调一整台小机的所有资源都分配给数据库在的虚拟机。
但是如果都直接跑服务器上面，平时业务不忙会造成资源浪费，按日常业务资源分配，又不能应对突发的故障。
虚拟化至少在运维上面是省事的，跑在虚拟机上的业务，不会因为虚拟机系统故障而停机，因为可以做容灾，虚拟机正常操作会自动同步到备份的虚拟机上面，启用的虚拟机故障了，会自动启用其它主机上面的备份虚拟机，网络请求，文件操作都可以配置自动切换过去，接近无缝切换。
要复制生产环境不用重新配置，做好一个模版直接调用模版生成虚拟机，甚至可以直接复制一个生产环境的服务出来。
网络带宽、cpu资源、内存资源、磁盘io全都可以定制自动扩展的方案，以应对未知的业务峰值，同时也切分了业务资源，保证业务之间不会因为突发的高峰把别的业务的资源都抢占了。

这么省运维工作量的事情，负责服务器运维的人竟然不同意做虚拟化，很难理解。

@mhycy 那就只有一种方法了，定期对数据源进行镜像，比如一小时一次。再写另外一个监控脚本，一旦数据源出问题，先自动切换到镜像，这样可以给修复数据源提供时间。
就是不清楚数据量有多大，能不能随时镜像而不影响性能。而且一旦你想到备用机的问题，成本就又上去了。。
这些架构用虚拟机做特别方便，感觉物理机不太容易。。

@lecher
@hjc4869
一个站点群，一家公司开发维护（咱们）、一家公司提供防篡改方案（就是那个前后端拷贝的工具）、一家公司负责服务器维护、还有一家公司维护防火墙、地方机构提供服务器以及场地。。。

这还不是问题，问题是这几个部门之间难以进行信息交流。。。
（咱们申请详细的访问数据、防火墙规则、程序运行环境的配置一个月过去了至今没得到有效回复）

@lecher 的方案很好，但无法使用的原因估计大家都能猜到。
现在的前后端同步的时间已经因为性能关系从1分钟一同步变成最离谱的时候5分钟一同步。。

另，在我理解中虚拟机最大能占用一个实体机的所有资源，那么对于一个高负载的应用（例如数据库）在耗光一个服务器的资源以后如何动态的进行资源的调配？在我理解中如果不进行应用上的修改只能换机扩容了。

关于容灾，我所了解的虚拟机的容灾是同时运行两台服务器，一台负责应对流量、一台备份，如果主机挂掉的话自动把流量切换到备份机，但是会损失宕机时的未保存的所有信息。

补充：我们的主要数据都是以txt形式存在（文章正文之类的），数据库大多是索引

1.同步问题不至于那么夸张吧，既然系统瓶颈在文件同步，那主数据库在的服务器就上ssd，对于文件同步的成熟方案太多了。现在的方案估计是因为同步的时候要扫描主服务器上的磁盘文件太多了，磁盘io不足导致的。先上ssd加快读的速度。如果还不行考虑在从机用用btsync这类的分发工具，让已经保存了主服务器资源的从机也做资源上传的操作，分担主服务器的带宽和磁盘负载。
2.虚拟机的上限是主机的基础资源，如果一个高负载应用连主机的内存、cpu、磁盘都跑满了，那就只能切割业务了，即使切割业务，也是虚拟化的方案方便，复制几个环境出来，再去手动调整业务分配。要不然就切换主机，比如你说的换机扩容，直接跑真机的时候，那你必须先配好环境，然后做数据同步再切换系统。但是虚拟化的则可以直接配好容量更高的主机，然后就可以点击迁移数据了，虚拟化的管理系统会在当前主机处理业务，同时将数据逐步迁移到新的主机上，包括内存中的所有数据，完全可以做到无缝迁移，当迁移完成之后，你再配置一下虚拟机的资源分配策略扩容所有资源，时间上不会比你配置一套真机系统再测试环境可用性迁移数据慢，而且更有保障，毕竟配置手册未必能把所有改动都列清楚。
3.你所理解的不是虚拟机的容灾，那是旧的方案了，现在新的虚拟化方案，可以做到一个请求过来自动分发到两台服务器，所有的操作，包括网络请求，内存处理，磁盘io都会同步执行，现在的虚拟化方案赚的就是无缝切换这个高可用的钱。
这种方案就是贵。

@lecher 感谢回复~
其实我觉得现在的防篡改拷贝动作没必要存在呢
做一个公共的盘柜，一端允许写入，一端允许读取权限配好的情况下就没防篡改拷贝什么事了~

如果说重构，我有话说：请我吧 上框架重构，我帮你操刀设计程序架构，数据库结构，web/db服务器架构，如果重构架构设计的合理的话，性能最少能提高10-40% 甚至更多。而且你的程序员也不受罪，框架统一了编程模式和借口犯错了大大降低。

@lygmqkl 咱们也想重构，但是客户不想出钱。。。

防篡改拷贝这个动作明显已经影响了系统性能了。
06年的时候可能需要这样的操作让领导觉得系统够安全，但是现在那么多文件同步工具， 已经不需要这个拷贝的操作了。想办法让这家公司出局吧。

@lecher 能不能让那家公司出局就不好说了。。。
感觉真要满足这么一个东西存在架构没法做就是了。。。

PS.那家公司很神奇的说不能同时满足两台以上服务器的防篡改拷贝操作。。。
好吧，其实我根本没理解这个防篡改是做啥用的。。。
只有读权限的系统还能篡改啥？

那是因为这家公司这么多年，都没有升级过他们的防篡改系统吧。
他们非说不能满足也可以。就以目前的架构中的前端服务器做为静态文件服务器，搭一个文件分发节点，做一下rsync也可以很简单地将文件分到其它服务器上面的，至于数据库，还是用后端的数据库做为主数据库。这就绕开他们的防篡改系统了。
方案上面就说，这些分发文件已经经过防篡改系统的认证，分发的节点没有任何修改权限。文件同样是安全的。
至于踢出局的事情，还是给你们的商务去解决吧，说不定这公司股东还是领导亲属什么的，不一定是善茬。

@lecher 非常感谢！方案交上去了，具体如何实施就看上层如何决定了。

@mhycy 求直播进度 感觉一场轰轰烈烈的 供应商内斗要开始了