当今年加州的夏天结束之时 ，云计算圈子里将有一起标志性剪彩：全球视频流媒体头牌Netflix将拉闸下线南硅谷自己最后一个数据中心，百分百拥抱公有云。

　　这是一场历时7年的公有云马拉松。Netflix从招聘网页开始，蚂蚁搬家，把自己数据中心的企业IT，从架构到职能，从片源搜索到大数据分析，一点一点 步步为营迁移到亚马逊AWS。去年已完成包括账单和支付在内大部分系统云迁移，现在只剩最后一个月，Netflix将从自己的数据中心净身出户。

　　2008年8月，正当北京奥运会酣畅淋漓的时候，Netflix主要数据中心数据库重创，停摆整整三天三夜。Netflix抓狂无门，外加每天高达三百四十万美元的惨重损失。多难兴邦，Netflix痛下决心，从此走上AWS云迁移的不归路。

　　2008年的那个时候，微软正忙着买雅虎，Azure八字还没有一撇。或者人们知道Sun已日薄西山，但谁是明日之星?然而，Netflix一帮名不经传的攻城狮程序猿们开始了一场企业公有云造山运动，最后把当时甚至多数企业IT男都弄不明了的云计算弄得家喻户晓。

　　塞翁失马,焉知非福。7年后，Netflix已成为全球云先锋，通过自身摸索与实践，从当时的云计算处女地踏出一条大路，开创出卓越的企业公有云模式，昔日IT灾区已是今天IT先驱，成为人人借鉴的楷模。最重要的是Netflix所执着追求的业务目标全面开花结果。

　　云前云后的确令人赞叹不已，Netflix以2倍增长的IT成本换取了巨大的业务成就：客户增长10倍，访问量攀升20倍，客户互动参与增长爆棚100 倍，年销售收入扩大3倍，达到55亿美元，毛利增长21倍，达到17.5亿美元。Netflix业务从美国延伸到60多个国家和市场，由DVD租赁转型数 字流媒体交付。现在Netflix被分析家认为是下一个市值超1000亿美元的公司。

　　Netflix是大型企业云迁移成功典范，它的公有云裸奔更让人围观。Netflix为什么可以裸奔?有什么借鉴的价值?裸奔哪些地方是个坑?值得企业事 业用户学习，并因人而异，因地制宜地应用到自己的业务实践。此外，Netflix是家非常开放的公司，它把自己的实践经验开源成Netflix OSS与产业分享。重度的开源技术和工具深挖这里：netflix.github.io

　　为什么选择AWS云迁移

　　数据库挂掉只是当年Netflix转向云的一个诱因，它促使Netflix深刻反思并认清自身业务一定需要一个优胜的架构和应用。这类对云架构的需求，在企业用户市场大同小异。

　　高可用性：宕机的人伤不起，宕机不仅不能再发生，而且Netflix决心把可用目标提高，从3个9追求4个9，全年服务率达到99.99%。并考虑不能把鸡蛋放在一个篮子里，堆栈式IT架构对自身所需要的高可用有局限，探索包括分布式数据库在内的横向扩展架构。

　　规模化：Netflix业务面临的一个重大挑战是总需求急剧增长，同时由于收视终端设备类别多，把握不住细分需求趋势。所以，不善预测的Netflix期望能够在每一个软件构件层面随时随需横向扩展，要架构敏捷，没有任何局限。

　　然而，扩大架构规模走什么路线?当时成本代价成为主要关注之一。比如按当时Oracle数据库授权政策，架构规模扩大两倍，授权成本远远不止涨两倍。(去IOE，也许最早从这里开始)

　　性能：超越现有系统性能，更好更快向客户提供满意的服务。这个保障有两方面分工：AWS提供数据中心架构优秀基础性能保障，但难于针对具体的业务特别的Netflix业务改进性能。Netflix则专注在AWS基础之上的业务创新和自身性能优化。

　　迁移经验

　　Netflix在实施云迁移时，选择之一是像货场用叉车一样把当时数据中心的堆栈完整转运到AWS，然后在此基础上做微调。这种迁移方式最简单，但弊端是 同时把原来不好的设计和行为方式一块端了过去。最后Netflix决定完全从零开始，以云计算思路，基于AWS公有云创建全新的企业架构和应用。

　　蚂蚁搬家： 一件事情持之以恒做了7年，从一个侧面说明云迁移不是突击战，不是一挥而就的事。去年公司首席产品官Neil Hunt在AWS re:Invent大会上回忆说，选择一张白纸画新图，Netflix冒有极大风险。当时完全没有云环境经验，也真不知道将遇到什么问题，甚至这条路是否 走的通都是个问题?基于这样的考虑，Netflix谨慎选择小规模搬迁，蚂蚁搬家，一次一小块。做不好，退回去重做。做好了，再搬下一块。一次客户迁移1 %，2%，5%，步步为营，逐步成长，直到最后完成全部迁移。

　　罗马双骑：由于 云迁移存在前景未卜的风险，Netflix采取了一个安全求稳战术：罗马双骑“Roman Riding”。这种骑术是一个人先骑一匹马牵一匹马，然后站在所骑马背上。下一步慢慢把一条腿跨到并行奔跑的另一匹马背上，形成罗马双骑奔跑。最后骑在 后一匹马上，完成双骑骑术。

　　罗马双骑骑术

　　罗马双骑是一次马背上的迁移，惊险之处有两个：站在马背上跨越和横跨两匹马背站立奔跑。如果跨越出错，或并立奔跑不能完美协调一致，都可能葬身马蹄。按照这个骑术，Netflix先在AWS创建原有服务功能，然后进行罗马双骑，而且每次只迁移一个特性或功能。

　　Netflix的云迁移双骑有点像现在说的数据中心双活。新开发的功能实例进行云部署运行，并导入正常流量，同时保留原有功能在老系统运行。云端功能被仔 细地监控并保持运行一定时期。如果所有的事情都运行良好，则注销老系统功能。如果有任何问题发生，那么马上切换回老系统。多次确保云上功能完全正确无误之 后，最后终止原有本地数据中心的该项功能，由云上功能取代原有服务。这个思路实际上已经贯穿在Netflix现在的DevOps一切流程中。

　　最逼格的是防御：NBA有句老话“防守夺魁”。Netflix的经典是“常作不死”(避免失败的最好方法就是不断地失败)。Netflix这句话画龙点睛，阐述出当今软件定义数据中心，由硬件性能保障，转型软件性能和机制保障的架构迭代。

　　在Netflix看来架构事故不可避免，架构的可靠性和性能需经得起任何可能的意外、错误甚至宕机。软件需要天生能够处理硬件故障、网络连接故障、软件集 群故障以及其它类型的错误。软件设计上需要通过在分布式架构中恰当处理独立，分隔，冗余，延迟和备份，力图架构永立不败之地。

　　比如Netflix实施了微服务，让服务碎片化，减少彼此关联，以求事故波及最小链，最小化灾难半径。又如Netflix设计了多实例、多区域和多地域冗余，以确保业务连续可用。

　　不仅如此，Netflix特别“作”，而且非常自“作”。它创建一支“猴军”(Simian Army)人为捣蛋，随机地引入错误，甚至随机地导致服务器崩溃终止服务，这种捣蛋每周演习一次。比如随机关闭生产环境中的实例，人为进行延时使服务不可 用来模拟服务降级。通过这样的不断折腾，即使各种宕机，云服务依然铜墙铁壁，固若金汤。

　　Netflix猴军

　　现在Netflix猴军已成为行业著名的开源工具，广受攻城狮程序猿的欢迎和使用。

　　组织转型DevOps：从本地专用数据中心转向AWS公有云，Netflix最大的组织机构改革是DevOps。IT人员200扩大到1000+，原来做开发的程序猿已经同时身兼负责运维，转型成为DevOps。

　　现在的Netflix组织结构正是云结构本身的写照：去中心化和微服务。面向服务按最大可能最小化组建团队。告诉团队目标和责任，但不说干什么，不控制; 保持团队间既定专注，但不绑定团队，团队要独立担当。总之，一个以微服务为单元组建的团队独立负责开发部署、功能和扩展、可用性设计和安全，凡重要事宜， 不要被代表。

　　中心团队侧重整体最佳操作案例分享和专家指导，提供公共开发工具和资源，保障整体战略大方向一致，提供监测和预警，进行评测和趋势分析。

　　在此组织架构下，Netflix开发速度极大提高，原来2周一次发布，现在一天代码部署上千次。

　　裸奔中的那些坑

　　归纳起来，Netflix云迁移经验教训包括这么几点：

　　真是搬家，不是办家家： 在云迁移之前，用户肯定会进行云供应商选择和平台研究，甚至按实际的应用任务及负荷进行系统模拟测试。这些前期工作对云供应商选择帮助，但决不可认为两者 完全吻合，可以一帆风顺实现迁移。云迁移过程挑战在真枪实弹阶段，只有当在选定云平台进行落地搭建完成后，你放应用和流量时，用户才知道云环境瓶颈在哪 儿?之前的一些聪明设计在实际的海量规模环境下很可能就是纸上谈兵和办家家。

　　上一个新选择，尽可能在大规模全荷载下，以真实的数据存储进行运行，从而逼近真实。记住，坐花轿的不是你的媳妇，接了面纱才是你媳妇。

　　这是云，不是咱机房：Netflix 自己的数据中心装备高大上，服务器容量大，速度快，带宽充足稳定。因此允许程序猿玩得嗨，设计豪华应用，对远程系统提供充足的API接口。然而AWS网络 实际上存在各种延迟，所以必须在结构上接受各种网络的交互环境，以及所带来的延迟。这是哪怕是AWS这样高分布式云架构也存在的状况。

　　实际上在自己数据中心硬件比较可靠，任何单一硬件实例故障是少见的，因此基于时域的内存管理是不错的办法。同样，管理不稳定的内存状态是可行的，因为我们 很少去进行从一个到另一个的实例迁移。事实上，云环境中你对实例的关注和内存管理，将有新的方向。由于可能的更复杂接口冲突或延迟等，实例迁移、丢失、故 障率更高，需要特别提防。

　　合租房的滋味： 如果你合租，你知道同享厨卫，你知道一大早你想入厕，可能要等等因为别人已经占岗。上公有云就是这意思，你对客户提供的服务都是要通过硬件、网络、存储等 共享模式去交付，请随时准备接受延迟。合租模式既存在于云堆栈中任何一个层面，而且在任何层面它的表现又差异迥然，所以绝对讲延迟无处不在。这里潜在许多 陷进，你在自己的专用数据中心难以发现。

　　各种延迟最后都可能是对你服务延迟甚至服务终止设下的坑。不要掉到坑里的办法就是设定你已经掉进坑里的各种后路，随时准备壮士断腕，丢支线服务，保证主干服务，特别是确保主干服务的连续，起码主干服务别挂掉。

　　或者，管理你在公有云上的资源，对你丢不起的业务避免合租。

　　微服务不是万能的：这是一个微服务崛起的云世界。Netflix是微服务的模范践行者，强调把服务切分到最小的粒度，对应独立团队去快速开发和迭代。微服务在反脆弱、容错、独立部署与扩展、架构抽象、技术隔离等方面具有诸多优势，保障了服务整体的可用和可扩展性。

　　微服务是相对于单体应用而言，它对复杂应用是当前极佳的开发和营运模式选择。微服务在架构内省约了中间件，服务间直接通过API衔接，它对资源的开销要求 分布式独立配置。基于这些特性，在上具体应用之前用户必须考虑自身基础设施和组织结构的成熟度，包括服务的集成模式?有无自动化部署和配置能力?监测能否 实现?是否采用DevOps的组织形式等?

　　Netflix微服务成功，但它的应用并不是天生就是微服务，而是后续采取微服务上新功能，最后反过来把老功能转码改造成微服务。是否采用微服务由用户自身服务需求和复杂性决定，不能为微服务而微服务。

　　把一个管理和营运效率都很好的现有单体应用拆分成多个微服务可能并不是当务之急。更好的选择是在新增功能时上手微服务，并以此练兵，在有了足够的 DevOps经验后，再看是否把原有应用切分成更细粒度的服务。如果应用不复杂，以优秀的模块化方式做单体应用仍然是好的选择。

　　旅途与彼岸

　　Netflix已经义无反顾走上公有云之路，不再回头。在云迁移的7年间，Netflix走过漫长的混合IT/混合云旅途。Netflix给企业用户最大的启示不在于公有云成为自己企业IT的终点，而在于提供前车之鉴，展示云迁移的历程。

　　不是每一个企业都需要裸奔公有云，但混合IT/混合云是每个企业的必由之路。

　　AWS牛人Werner Vogels这样描述云世界的未来：百花齐放的各种云服务构成了混合IT，但在我看来，你必须直面现实，混合IT不是终结。长远看，许多企业仍然将有自己的数据中心，但随时间的推移，企业数据中心将越来越少。

　　企业云计算是一个旅途，混合云/混合IT是常态。即便是公有云旗手亚马逊，谷歌甚至Netflix迄今仍然保留有自己的专用IT操作。公有云存量将越来越大，而彼岸绝非一朝一夕。