泪说新公司使用云服务器后构架的不堪历史

第一阶段（3台）：1测试，1web 1数据库

这个是云服务器，配置高的惊人，测试的机子居然和正式的机子如出一辙，只实现了web和数据库分离的构架
维持了3个月，因为物理机故障，3台服务器同时挂掉，网站暂停服务至少一天

第二阶段（4台）：1测试，1web 1数据库 另外一机房1数据库＋web

master-slave:
仍是云服务器，配置仍是高的惊人, 除了另外一个机房实现了web备份和数据库主从外，跟第一阶段没什么差异
由于一次数据库服务器数据页面错误，主库崩溃，web和数据库跨机房了

第三阶段（6台）：1测试，1web 1数据库，另外一项目1web，1数据库 另外一机房1数据库＋web

master-master
上一次的教训是数据库修复的时候，发现master的数据必须从slave导出来...数据一致性的要求.
痛定思痛，决定上双master-master，这个时候出现了一个应用层的悲剧，就是多个项目要公用一部分表了，而web却在另在两个服务器上 期间为了解决冲突，把自增id给岔开了

这个阶段最大的悲剧在同一个机房内，web＋数据库没有备份的，在某次攻击后，悲剧的发现，web＋数据必须切换到那个备份的机房去了

第三阶段...

还在进行中...

推动太困难了，通过2次事故..我有点不想继续既作开发又作运维的了...出现问题的时候你们说，我不知道啊，服务器不归我管理，我怎么操做呢？要讲解运维思路的时候你们又不积极

总结

得出的最大教训就是：云服务器太不稳定了，要以数量取胜，不能同一机柜。有一次别人的云服务器被攻击，提供商居然重启了物理机..而后又诸多悲剧出现

最大的感恩就是：学到了不少知识。每次事故服务器我都要被迫亲自参与修复，原本不那么熟悉的，一会儿被强迫作了不少事情

最近这段时间开始测试的东西有：

1. Fabric 用于多项目多服务器的代码发布...
2. Atlas 数据库读写分离中间件，从另外一方面说也是屏蔽数据库服务器差别的中间件，这点认识很重要，若是有3台web，当一台出现问题是，3台的数据库链接都要修改，但有了这个中间件，只要把有问题的offline便可...1分钟就能搞定

Fabric 已经上线使用，Atlas 上线遥遥无期..不少坑等待被发现

2014年2月8日补充：

今天由于到期，来不及续费，还剩下10个小时的时间，服务器居然自动关机了...还好，是关机而已，不是删除服务器....坑啊

2014年2月12日补充:

今天新增长2台服务器，准备内网使用，中国的带宽真TMD的贵.并非每台都能10M出口带宽的..
由于没有统一的上传文件和图片，每一个服务器都把图片上传到本身那台，最近要考虑怎么把这些图片整合起来了，由于图片量比较少，因此准备了一下方案：

1. rsync + crontab
2. rsync + inotify
3. sersync + inotify
4. inotify + svn

不知道你们还有其它方案么？难点在于多台服务器之间相互rsync...

再次重申云服务器的好处：新开服务器几乎是1小时之内，而后，必定要以数量取胜...

2014年2月13日补充：

今天同一个物理盘所在的云盘上可能有人大量写入数据...致使同一个机柜上的N个机子云盘io 100%... 之前对云主机都没怎么认识，今天真是大开眼界了...

云盘和云主机，另外一个大坑就是：天佑同机柜和同物理机的的人都正正当当，否则，通常的人都不知道问题出在哪里