传统IDC跟云服务的关系
传统IDC作为互联网的基础平台为其服务了几十年，可是对IDC的使用从来没有像今天这样使用了互联网思维。云时代，服务商卖给企业的不只是场地，机柜，电。。还有一整套采用互联网思维来使用它们的解决方案，所以通常我们会觉得云服务“哪儿哪儿都要花钱“，所以有实力的公司会搞“私有云“。
混合IT架构的尴尬地位
随着云服务的逐渐完善，如果我要做一个产品，必然会去选择云服务提供商，因此也就不会有混合IT架构这个概念了，因为这个概念通常存在于使用传统 IDC的公司向云服务过度的一个中间状态。也对运维部门是一个极大的考验，因为要在一个新的环境建立产品运行环境，还要保障产品速度，各种转换率不会因此降低。
数据一致性
混合架构有两种方式，一种是备份机房，机主机房出现比较大的故障，可以将流量切至备用机房，一种则是双活，即两个机房同时为用户提供服务。无论是哪种方案，都需要两个机房之间的网络延迟在可以接受的范围内，一般通过专有光纤来解决，云服务商通常会提供这种专有光纤的接入(比如AWS的Direct Connect服务)来打通实体机房与云服务的网络环境，我们可以利用它来做到数据的同步。
有了良好的网络环境，如何实现数据同步同样是一件及其困难的事情，比如数据库，就需要用户写数据的时候往两个机房各写一份，比较普遍的做法是采用消息队列，将用户写的数据先排进队列，然后在开启两个队列对不同机房的数据库进行写操作。 另外是缓存，如果用户访问新的机房，由于新的机房没有缓存，则会出现新的机房数据库被打爆的风险，比较简单的做法是通过在请求包设置cookie用以标记是否是老用户然后负载均衡层判断，含有次cookie的转发至老机房，没有此cookie的新用户则转发至新机房，然后再将老用户按照逐渐递增的方式将流量迁移至新机房，直到新机房缓存完全建立。
做到敏捷
使用云服务的一大优势便是资源到位速度快，一般情况下，我们可认为云的资源时***大的(如需求特别的，需要跟云服务商单独谈)，许多的云服务商(比如AWS)都会给用户提供api接口用于开启资源，并配合cloud-int服务实现资源的初始化，比如我们可以通过脚本的方式调用api快速开启一台 webserver，一台memcache，一台mysql，并使他们处于不同的集群以及不同的监控组中。
尽可能多的使用服务
云服务商提供的服务不仅仅有虚拟服务器，也会提供诸如负载均衡，分布式存储，cache，消息队列等其他的公共服务，将他们恰当的运用到自己的项目中是很有必要的，因为你将在短期内不用担心他们的扩容问题，比如可以使用AWS的ELB作为负载均衡器对外提供服务，使用S3存储静态资源以及log文件 (有个叫s3fuse的项目可以实现将s3作为文件系统挂载到服务器上，可以向访问本地文件一样访问s3上的文件)。
监控一切
在企业架构还处于混合架构的状态中，我们要对产品的性能做两套监控系统，另外一个用来专门监控处在云服务上的产品的性能数据，包括性能指标以及业务指标。我们可以通过在前端分流层对流向IDC以及云服务的流量打上cookie或者标记Etag，然后再log分析的时候便可以出两套数据，用于对比，随时对云服务进行优化或者技术决策，可以采用grafana做成类似如下的图标用来实时观测数据。
