本文内容同样来自InfoQ这篇文档。关于云计算遵循的原则，与我之前博文里描述的Heroku 12条设计原则类似，引用如下。
过去一些年来，云计算逐渐发展起来，有人开始为云计算的设计总结可复用的模式，目前形成了不同的流派。
所有流派基本都遵循六条原则:
1. 无状态，包括无状态的镜像和无状态的实例。云上的实例是虚拟化的，很容易被搞坏，所以把需要持久化的数据和实例分离，无论是故障迁移、应用扩展还是升级都很容易。
2. 松耦合，包括地缘、平台、时间、数据格式方面的解耦。
3. 弹性。层、服务和组件都应该是有弹性的。
4. 自动化。一方面可适应频繁的扩展，另一方面也是避免人工失误导致的问题。
5. 全面的监控/日志。线上做debug很困难，需要全面依赖详细的日志。
6. Design for failure。容忍错误，快速恢复，将failure当做普通事件处理。
你传播了正能量，那我就再来传播点负能量：
1. 无状态的困难别的我不知道，在网络上特别是 l3 及其以上还是很难…… 想做到用户感受不到的 l3-agent 迁移，即使实验环境 OK 了，跑到生产环境还是有错；
2. 松耦合想的确实很好，但是意味着带来大量的接口调用，Token 验证…… 挺麻烦的，像 OpenStack 建立一个虚拟机要走好多调用……
3. 这个与耦合和状态都有关吧，前两条做好了，这个就是水到渠成；
4. 比较希望做到，但是像安全事件、硬件故障还是很难自动化操作；
5. 监控全了日志多，怎么分析，我一直想知道青云号称的机器学习分析日志效果到底怎么样；
先讨论这么多吧，一些东西也只能说是观点，并无定论……
无状态其实是指运行在云上的web业务的无状态，比如session、存储、logging等都独立。松耦合还是有用的，比如我们这用到了消息队列，producer和consumer异步处理任务，后端不至于影响前端。
回复貌似无提醒啊，消息队列挺好的，但是说实话像 RabbitMQ 性能一般，但像 ZMQ 现在 OpenStack 放弃支持了……