服务器迁移解决方案.docx

服务器迁移解决方案编者按：UCloud 最新发布了名为“Sixshot”的可用区特性，用UCloud VP陈晓建的话说，“可用区就好比云计算的太祖长拳，看似平平淡淡，但要打得好着实不易。”太祖长拳属于南拳流派，共有四套拳路，讲求一胆、二力、三功、四气、五巧、六变、七奸、八狠。有鉴于此，解密「云计算的太祖长拳」系列将在接下来的三篇内容里，详细介绍UCloud可用区项目的“一胆、二力、三功”。本文是解密「云计算的太祖长拳」系列的第三篇我们会和大家一起探讨一下我们对网络业务的后台服务（包括管理面程序management plane和控制面程序control plane）所做的重构工作。这里最重要的是如何对后端各个模块做正确的解耦从而使得我们可以做用户级别的灰度来可控地发布可用区这样一个涉及全局各个业务的特性，并且将亿万条用户数据从老的非可用区架构平滑迁移到新的可用区架构上。云计算十年，架构师的地位越来越重要说明了什么？架构设计和数据迁移方见真功夫，因此本篇选太祖长拳之“三功”为题。这是一个看似平淡沉闷但实则步步惊心的指尖之舞——如何尽最大可能保证用户的现网业务在切换过程中不受影响是我们最高优先级的任务。诚然，在整个可用区灰度上线的过程中，我们还是遭遇了很多事先没有预料到的故障和挑战，这一程也远不是一马平川过来的。因此我们也在不断地总结和打磨我们的支撑系统和方法论，但长期以来，以下的一些基本思想一直是整个研发和运维团队所秉承的底线：持续改进的能力高于一步到位的完美；早于客户探知和快速回滚的能力高于万无一失的程序逻辑；主动重构的团队意识高于一劳永逸的个人英雄主义。千里之任：后台管理程序的分拆UCloud的SDN网络服务的整个后台逻辑事实上是一个由20多个服务组成的大型的分布式系统。这些服务负责了SDN业务逻辑的方方面面，其中包括（只列举了主要的）：我们在可用区项目进行的过程中，遇到的第一个大型的全局性问题就是我们发现由于之前广泛遵循的模式（design pattern），所有的manager的前端（Frontend）和后端（Backend）的逻辑都是在一个模块里实现的（当然部署的时候也是这一个模块同时覆盖了Frontend和Backend的功能），如下图：这个架构的主要问题在于服务的前后端功能是耦合的。在服务程序逻辑相对简单，升级变更还相对轻量级的情况下，这里的矛盾还不是特别突出，我们通过严密的监控、主动的运营（扩容或重启服务等）、及快速的回滚（升级验证失败的时候）等手段基本还是能控制整个系统的运行状态。但其实之前我们已经逐渐发现这个不同关键路径程序逻辑间的耦合带来的问题了：一个十分典型的事例就是曾经发生过的一个现网事故——当时有用户反馈说从某个时间开始，控制台上的一些网络服务的页面经常有间歇性超时从而无法显示数据的情况。如上图所示，我们的官网控制台是通过API Gateway来调用Manager上的接口的，因此我们的研发工程师自然而然地去排查了所有Frontend的运行日志，却发现在出现CPU飙高的时间点，Frontend的日志里没有显示任何异常的行为。然后我们逐个排查了整条控制台到Manager调用路径上所有服务（API Gateway，Access层，包括控制台本身），都没有发现任何的问题。正当我们一筹莫展的时候，一个偶然的机会，另一位负责Manager中Backend功能的同学提到，由于Backend每秒收到的请求（query per second）较高，所产生的日志也通常比较大，容易占用过多的磁盘空间。因此他提交了一个优化的逻辑，会随机地将一些旧的日志打包并送到远端的一个存储空间里保存起来。而进一步分析Backend的运行日志后，我们发现所有控制台发生超时情况的时间点都是和Backend上这个日志打包逻辑的运行时间是吻合的。这个变更对Backend的影响姑且不论，这里最大的问题在于：一个看似旁路的后端逻辑却直接影响了直接有损用户体验的前端服务，这是十分不应该的。笔者之前在Amazon工作的时候，曾经听过一次内训的讲座，是当时Amazon的Global Payments部门的高级研发经理Thomas Vaughan所做的”Greatest Disaster in Amazon’s History”的演讲（这个是Amazon内训讲座中排名前三的一个演讲，可惜由于是内部资料，非Amazon的员工无法听讲）。Thomas在讲座中总结了Amazon历史上最有教育意义的6次重大现网事故并从中总结了一系列大型分布式系统开发的原则和规范，其中第二条就是：Partition your critical use cases.也就是说：要注意解耦关键路径上程序逻辑。很难想象这样一个简单的原则却一直在不断地被违反（我们可以指出很多的原因，客观的，主观