开始本书之前，需要先把《上云前为什么要切换主备机房？》的来龙去脉讲清楚。简单来说，主备机房的切换只是我们“上云五步走”中的初始化环节，最后一步步将我们的应用上云：看到这样的步骤，很多老师会有强烈的吐槽冲动，别着急，我来解释一下“上云五步法”：1.出于成本考虑，除了UCloud（包括阿里和腾讯），没有供应商允许'IOE'搬进了他们的机房，所以我们最终选择在‘UCloud通用模块’中搭建我们的新机房，然后通过内网与UCloud互联。2、出于成本考虑，专线扩容申请被CEO否决，伪双活方案最终无法实现。3、出于成本考虑，同时也考虑到未来迁移到云机房后的折旧因素，新机房的硬件投入仅为老机房的50%。除了以上三点，还有一些细节，因为不是重点，就不一一举例了。如果我说太多，我会哭。题图：来自Zoommy-客观条件下的迁移方案-方案一：整体冷切策略：利用周末停盘、访问量下降的环境切换整体环境。方法：核心业务数据库1：0.5搭建环境，核心业务应用1：0.3搭建环境，非核心业务数据库直接搬迁，非核心业务应用直接搬迁必须考虑域名和CDN切换时间的缺点：整机搬迁存在设备搬迁后故障、无法启动的问题。搬迁设备数量多，容易出现这种情况。搬迁前必须做好数据库导出和独立存储的准备工作；设备一次性搬迁次数多，搬迁过程中装卸时间长。另外，外高桥机房对设备的准入管理严格，报关查验时间长；当发现备节点不能承担业务时，回滚时间长；停机时间更长；方案二：降级冷切策略：利用周末交易停止、访问量下降的环境优势，在降级主机房和升级备机房之间切换。方法：将主节点上所有业务应用+数据库的数量从1:0.5改为0.5，将下架设备集中搬运到备节点，进行环境调试，完成从备机房升级的过程0.5到1。优点：宕机时间短，预计总宕机时间在几小时以内（二次切换需要大规模程序验证，预计需要N小时以上）数据风险小，核心和非核心业务数据在切换前使用双机热备方式同步，提供回退保障。当备份节点业务启动失败时，可以快速将服务切换回原主节点。在切换前，通过提前验证可以提高切换质量。一些关键设备（如数据库）通过将单机转换为大容量虚拟机来控制，可以有效保证平滑切换。切换时间可控性强，包括联合测试和在线测试业务，也可以灵活安排。缺点：需要提前搭建整个环境，前期需要占用一部分人力搭建二次全环境方案三：伪双活渐进切换策略：两端使用负载均衡设备进行访问均衡，逐步将业务从主节点切换到备份节点。方法：利用机房的负载均衡设备，将主机房的部分流量引入备机房，然后备机房的配置数据库可以回写到源端本地读取，逐步切换全部接入备用机房，然后直接切换接入备用机房。优点：更少的访问停机时间。前期有多次闪断，后期有N分钟的DNS切换。缺点：业务接入环境搭建复杂。除了在两个节点上构建前端应用外，还必须快速配置后端接入节点，容易出现人为错误操作失败（在数据库配置错误的情况下也容易出现脏数据，可能导致清算和交易的数据恢复难度更大）前端应用手工配置风险系数高，没有统一的配置管理。伪双活对主备间的带宽要求较高。目前X兆带宽只能保证业务数据库的同步。成本***、线路成本、人工成本、多次搬迁的风险。事实上，我们最终实现方案方案一方案二的组合：切换当天：整体冷切，旧机房所有硬件数量从1容量迁移到新机房0.5容量，并通过降级、限流等手段，顺利度过了***个交易日。切换后三天内：逐步拆除旧机房的硬件运到新机房，完成备份机房从0.5升级到1的过程。公司，IT投资后的即时收益是最重要的。近年来，为满足公司日益增长的效率和质量需求，我们陆续推出了持续集成/中间件/自动化运维等多个自主研发平台，不仅用“适配器思维”帮助应用系统降低了访问成本，它确实帮助一些系统在松散耦合和自动化方面带来了颠覆性的变化。但是，对于机房切换项目来说，不可能指望在项目前期得到更多的投资，收益既不能量化也不能小。因此，在计划制定的前期就需要更加关注成本。去年，圈内流传着这样一句话，“CTO就是要实现CEO曾经吹嘘过的东西，眼里含着泪水，至少不把CEO弄死”。其实在我看来，对于大多数公司（尤其是金融公司）的CTO来说，由于技术团队的本质是成本中心，所以CTO和CEO之间的博弈，多半是在成本和价格之间。我们应该做的是在有限的资源和成本范围内想出可靠可行的解决方案，在不违背商业原则的情况下达到预期。-后续补充-这篇文章的主要目的是全面解释“为什么上云前需要主备机房切换？”事实上，在项目实施过程中，我们接连遇到了很多意想不到的失败。虽然暂时解决了，但是给我们的云化之路带来了很多思考。
