转载

混合机房最佳实践

如今越来越多的互联网产品都喜欢选择云服务来构建自己的基础平台，因为可以将时间跟精力更好的分配到产品本身而不是支持产品的运维设施。也有越来越多拥有传统IDC的公司将迁移至云(租用或者自建)作为公司IT部门的重点方向(或者采用传统IDC跟云服务混合的方式)。无论采用哪种方式，我们的目的都是服务于产品，使其健壮，高效。不管是云或者是传统IDC,成本，稳定，效率都是运维人员永远在思考的问题，如何更有效率，更科学，更有趣的使用云服务提供的便捷也将会是未来各位运维同仁共同面临的问题。

1.传统IDC跟云服务的关系

传统IDC作为互联网的基础平台为其服务了几十年，可是对IDC的使用从来没有像今天这样使用了互联网思维。云时代，服务商卖给企业的不只是场地，机柜，电。。还有一整套采用互联网思维来使用它们的解决方案，所以通常我们会觉得云服务“哪儿哪儿都要花钱“，所以有实力的公司会搞“私有云“。

混合机房最佳实践

2．混合IT架构的尴尬地位

随着云服务的逐渐完善，如果我要做一个产品，必然会去选择云服务提供商，因此也就不会有混合IT架构这个概念了，因为这个概念通常存在于使用传统IDC的公司向云服务过度的一个中间状态。也对运维部门是一个极大的考验，因为要在一个新的环境建立产品运行环境，还要保障产品速度，各种转换率不会因此降低。

混合机房最佳实践

3．数据一致性

混合架构有两种方式，一种是备份机房，机主机房出现比较大的故障，可以将流量切至备用机房，一种则是双活，即两个机房同时为用户提供服务。无论是哪种方案，都需要两个机房之间的网络延迟在可以接受的范围内，一般通过专有光纤来解决，云服务商通常会提供这种专有光纤的接入(比如AWS的Direct Connect服务)来打通实体机房与云服务的网络环境，我们可以利用它来做到数据的同步。

混合机房最佳实践

有了良好的网络环境，如何实现数据同步同样是一件及其困难的事情，比如数据库，就需要用户写数据的时候往两个机房各写一份，比较普遍的做法是采用消息队列，将用户写的数据先排进队列，然后在开启两个队列对不同机房的数据库进行写操作。

另外是缓存，如果用户访问新的机房，由于新的机房没有缓存，则会出现新的机房数据库被打爆的风险，比较简单的做法是通过在请求包设置cookie用以标记是否是老用户然后负载均衡层判断，含有次cookie的转发至老机房，没有此cookie的新用户则转发至新机房，然后再将老用户按照逐渐递增的方式将流量迁移至新机房，直到新机房缓存完全建立。

4．做到敏捷

使用云服务的一大优势便是资源到位速度快，一般情况下，我们可认为云的资源时无限大的(如需求特别的，需要跟云服务商单独谈)，许多的云服务商(比如AWS)都会给用户提供api接口用于开启资源，并配合cloud-int服务实现资源的初始化，比如我们可以通过脚本的方式调用api快速开启一台webserver，一台memcache，一台mysql，并使他们处于不同的集群以及不同的监控组中。

混合机房最佳实践

5．尽可能多的使用服务

云服务商提供的服务不仅仅有虚拟服务器，也会提供诸如负载均衡，分布式存储，cache，消息队列等其他的公共服务，将他们恰当的运用到自己的项目中是很有必要的，因为你将在短期内不用担心他们的扩容问题，比如可以使用AWS的ELB作为负载均衡器对外提供服务，使用S3存储静态资源以及log文件(有个叫s3fuse的项目可以实现将s3作为文件系统挂载到服务器上，可以向访问本地文件一样访问s3上的文件)。

6.监控一切

在企业架构还处于混合架构的状态中，我们要对产品的性能做两套监控系统，另外一个用来专门监控处在云服务上的产品的性能数据，包括性能指标以及业务指标。我们可以通过在前端分流层对流向IDC以及云服务的流量打上cookie或者标记Etag，然后再log分析的时候便可以出两套数据，用于对比，随时对云服务进行优化或者技术决策，可以采用grafana做成类似如下的图标用来实时观测数据。

混合机房最佳实践