今天因为要升级系统，所以在升级之前的这段时间写写关于云计算的东西。
时下非常流行的一个概念，就是“云计算了”，俨然一副大势所趋的样子。到了只要是做IDC的就一定要做个云产品出来。霎时间，千云万云在空中向我们飘来，真的，看上去很美。
美，肯定是显而易见的。但是，我们真的要做好准备，否则再好看的云也极有可能在瞬间变成乌云一朵，甚至雷电交加。搞不好让你的服务瞬间倾覆。
很不巧，作为全球云计算领导者amazon的用户，我已经经受了两次AWS的事故。只是时间和地点的不同。4月27日，amazon向我们证明了云其实和我们日常的服务器一样，也会出问题，并不是坚不可摧的。那么刚刚这次，甚至还没有彻底解决问题，让我们认识到，云不但不是坚不可摧的，而且一旦发起彪来，造成的恶劣影响范围之大，程度之深是一般物理服务器所不能匹敌的！
“云”到底适合什么样的需求或者应用？真的很难说，估计一百个人就有一百种答案。但是我们可以反过来想一想，有没有不适合的？
通过AWS的使用来看：
如果强化单个服务器有超强的计算或者IO能力，”云“不适合。
其实云还是强调”够用就好“的原则。这样才能够有效的利用物理的计算能力和IO能力。说到底，云到最后体现的是一个服务的存在而不是一台或是几台物理服务器。就像我们要运行一个tomcat服务，不管是那种云，哪家的产品，无论用什么表现形式。反正就让你把代码部署上去，tomcat开始服务，好一点你还可以配置一个IP搞个DNS指向。然后服务上线，别的你就不用管了。而这个tomcat提供的服务最终变成了这个云的一个存在的服务。不用管到底在哪个服务器，那个IDC，那个国家。
”你见，或者不见它，它就在那里，不来不去“
没有多个节点高可用设计和实现的，小心某天从云中直接跌落。
通过AWS出的这几次问题，我们不难发现，一旦底层承载”云“计算平台的各个层面出现问题或者故障，将会影响整个在该平台的所有服务。当然云服务提供商需要尽可能的避免出现这样的问题，但是一旦出现对于运行其上的公司打击还是很大的。毕竟云计算平台要有足够规模之后，才能通过更高的使用率甚至是某些复用达到高使用率、高计算能力和其服务提供商追求的商业目标（说白了就是多挣钱）。所以在软件设计之初就要尽量满足或者拥有云的一些特色。当然，有些大规模的并行计算估计可以不需要，反正某个或者几个节点异常，甚至全部节点失效都没有关系。它要的只是计算出结果而已，大不了重算，没有7×24小时服务在线的要求。而除去这样的需求，对于云上运行的服务软件的设计和最终的部署需要思考的东西还很多。例如：此次amazon在欧洲区出现的这个问题，如果可以将实例分别部署在该区的3个zone中，可以避免服务停止的故障。但是在设计之初没有考虑多节点服务提供，部署之初考虑成本付出（带宽等费用），则会直接造成该问题出现区域部署的服务直接全面停止。
如果有可能，应尽量早的和云服务提供商进行较多的沟通，一般来讲他们都会有专门的架构师来对我们的设计和部署提供技术帮助的。
最后，补充说下关于构建私有云的问题。
现在有的云服务提供商，象买硬件服务器或者做项目一样协助某些用户构建自己的私有云。其好处可以说是成车列举。但是需要注意的一点，云平台构建技术比较复杂（其复杂程度肯定远远大于直接管理硬件服务器），尤其一旦出现问题需要技术过硬的团队进行处理和解决。其成本并不一定小于我们的购买物理服务器和租用IDC的成本。并且，一旦出现故障搞不好全线业务停止，而传统的物理服务器则只是会因为某几台出现问题而造成单一业务的停止，且修复速度会比较快（如果全部服务器都停止工作，基本上只有可能是地震或者你图便宜找了一个不入流的IDC提供商）。真的别让云搞花了自己的眼睛。
云肯定是好东西，但是作为技术而言，它肯定也会有不足，也会有问题。重要的就是我们该如何去适应它，最后到如何善用它。
本文转自Be the miracle!博客51CTO博客，原文链接http://blog.51cto.com/miracle/635581如需转载请自行联系原作者
Larry.Yue
