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

第一阶段（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%... 以前对云主机都没怎么认识，今天真是大开眼界了...

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