只需三步，迁移遗留系统到云端-InfoQ



 写点什么

背景

在互联网大行其道唯快不破的今天，毫不夸张的说，对市场的响应速度甚至会决定一家企业的命运。我们的客户（房地产垂直搜索平台）就是这么一家互联网公司，为了缩短开发周期，减少系统投放市场的时间，我们将现有的基于传统数据中心的基础设施迁移到云端，以便获取这种的能力。本文讲从大的方向上，讲述了我们在合作的过程中，一起将老的系统向云上迁移的经验，以及其中的一些实践。在此之前，我们先来看看他们的现有系统。

现有系统

图一

图一是对现有核心系统的一个简单抽象，我们维护了三条业务线（在这里是指以业务为基础的，有独立的产品经理，销售团队，独立结算的团队，下文简称 LoB），每个业务线对应的是不同类别的房产的搜索网站，比如商业和住宅。User 是用户管理模块，该模块能提供用户管理，书签和搜索管理；Location 是位置模块，根据用户的搜索条件给出实际地址和相邻地址；Search Engine 用于存储所有信息，并提供搜索功能。可以看出三条 LoB 虽然是不同的网站，但是它们提供的服务是类似的。不仅如此，它们外观相似度也非常之高，除了主题之外几乎没有差别，同样的用户体验，相同的页面布局，还有非常显眼的标识用来说明他们来自于同一家公司。

从上述原因来看，它们应该集成在一个系统内，但其实不然，尽管这些业务线有如此高的相似度，但是从以下方面它们有着非常大的差别：

部署和配置不同由于不同的房产有不同的搜索条件，因此在部署的时候，需要对不同的网站进行不同的配置。
特性和发布时间不同不同的房产有不同的目标市场，需求决定了要开发哪些特性，做什么样的市场推广活动，因此每个业务线都有自己的销售和开发团队，并且根据市场变化制定相应的特性开发和发布计划。
不同的流量图一中不同颜色表示不同的流量等级，红色表示流量最大，黄色表示流量中等，而绿色则表示流量较小。对于不同类型的房产，市场的需求是不同的。
目标客户不同，市场定位不同商业地产的目标客户是那些需要开展商业活动的商家们，而住宅房产的目标客户则是那些想要生活或者为子女提供更好教育机会的普通老百姓。

业务愿景

在了解了现有系统之后，我们再来了解一下他们的业务愿景，因为没有一家公司的 IT 改革是脱离业务驱动的，理解业务愿景有助于更加清晰地理解向云迁移背后的原因。同时云策略的适用场景有一个更加直观的认识。

3 年后的年营收翻一番
基于 LoB 的运营模式这意味着每个团队将是完全独立的全功能团队，他们拥有独立的系统，具备独立开发，部署，运维，市场，销售的能力。这就为每个团队提供了非常大的自主权利，对业务的扩张和收缩提供非常好的自适应能力。
效率这里所说的效率主要是指 IT 生产活动中的效率问题，本质上讲他们是一个互联网公司，如何能够提高 IT 系统的效率来支撑业务的发展这是他们所看重的。比如，提高人的效率，开发，上线，测试，运维，线上反馈等等，各个方面的效率问题。
全球扩张计划中国恐怕是全球最活跃的房地产市场之一了，同时对海外房产的投资在中国持续升温，他们没有理由放过这个机会的，不仅如此包括在德国，意大利，中国香港都有他们的身影。

基于以上的种种不同，图一所示的系统架构显然无法满足客户对商业愿景的实现，主要的问题有一下几点：

无法独立运营由于这是一个所有 LoB 都整合在一起的系统，因此业务线之间存在着耦合。试想一下这种场景，LoB1 根据市场的反馈已经完成了对房产中介品牌的增强，并且希望在涨价之前上线，因为这将是一个涨价的合理理由。与此同时 LoB2 正在开发新的页面来满足房产拥有者品牌的需求，但是这个特性只是开发了一半。按照当前的模式我们必须等待 LoB2 完成特性的开发之后才能一起上线，这样对于 LoB1 就错失了一次涨价的机会，而下一次涨价窗口将是几个月之后。
资源利用效率低通过流量监控我们发现网站的访问量并不是一成不变的，以年为单位，网站流量在圣诞节之前会降低到平时的 50% 左右，圣诞节之后大概又会回升到平均水平 200% 左右，而这样的大流量会持续约 1 周左右的时间。其实这样的情况不难理解，因为在圣诞节期间大家休假，收假之后会迎来一波工作潮。从图一中我们也可以清晰地看到不同组件的不同流量，为了保证整体的响应速度，这个系统始终是以比较高流量的情况部署的，但是由于每个 LoB 无法独立部署，导致资源浪费的情况非常明显。
扩张成本高前文我们提到了全球扩张计划，他们想进入中国市场，于是需要为中国的用户设计一个独立的网站用于提供房源，同时也要将这一扩张作为模式，为将来的向其他国家的房地产市场扩展做准备，为了实现这一目标，我们需要 IT 基础设施的支撑，能够快速灵活的横向扩张。但是基于现有的数据中心的模式，这将是一个痛苦的过程。

架构愿景

通过对原有 IT 架构的分析，我们发现它是很难支持业务愿景的实现的，因此针对这样的业务愿景，我们勾勒出了能够很好支撑业务愿景的 IT 架构愿景。

独立业务线必须能够按照业务线来独立运营
扩展性容易扩展或伸缩
关注解决从开发到部署的所有问题，开发人员更加集中的关注如何更快的交付特性，而非各种环境问题，部署问题，发布问题
效率提高资源利用率，根据不同的流量情况自适应分配资源。

基于这样的愿景，我们发现云平台能够很好帮助我们实现这样的一种 IT 愿景，如图二描述了系统迁移到云端之后的架构。

(点击放大图像)

图二

首先，所有的业务线都是独立运营，他们能够自主选择自己何时发布上线，自主选择合适的SLA 以及资源来适应流量的变化；其次，对于所有业务线共同分享的组件，独立于业务线之外，分开部署和运营，并且它们也能够根据流量的变化调整不同的资源进行适应。

迁移三部曲

当我们知道了现有系统的目标状态之后，下一步就是如何实现这个目标了。

(点击放大图像)

图三

如图三所示，在向云端迁移的时，从现有系统到目标系统的迁移，这个过程不是一蹴而就的，不是一次迁移就能完成的，而是周期性地持续进行，每一次的前进都是相关系统集成的结果。如果我们将目光聚焦在其中某一个迁移的周期内，这个过程大概分为三个阶段：

第一阶段：识别

识别就是要弄清楚迁移什么。

对于原有的集成在一起的系统来说，这一过程与聚合更好相反，是把所有聚合在一起的功能特性分析并拆解，这个活动的目的就是深入理解当前系统承担的职责。在弄清楚职责之后，我们就可以更好的识别哪些职责是可以被剥离，拆分，并独立出去的。比如对这个房产搜索网站来说，识别之后发现我们的它的职责主要有：前端展示（桌面，移动），房产搜索，搜索的管理，用户管理，地理位置查询，同时还提供了部分API。在完成了识别之后，就是我们要选择从哪些职责开始入手迁移。这个过程并不是随机的，而是要根据现有的团队能力，业务目标，综合所决定的。

我的建议是从简单的，相对独立的职责入手，如果同时还能对业务发展有所支撑，那就是再好不过了，因为难度低，所以能够在迁移初期给团队带来自信和经验，随着迁移经验和自信的积累，那些耦合度高，依赖多的职责也能够轻松的迁移。以该房产搜索平台为例，在迁移初期，我们选择用户管理职责来迁移，一方面是因为它相对简单，相对独立，另一方面则是因为它对我们进行iOS 开发提供了API 支撑。

第二阶段：提取

在识别出系统职责并确定要迁移的职责之后，则是提取该职责为独立云服务的阶段了。

图四

如上图所示，这一阶段的核心就是将识别出来的职责独立于原系统之外，成为独立的云服务。这个过程有几点需要注意的是：快速创建，它需要快，多快呢？理想状态是创建成功（空服务）后就直接上线（灰度发布），或许这个目标在刚开始迁移的时候比较不容易实现，但是随着迁移自信和经验的积累，它是完全可行的，当然这也是为什么我们要从简单并相对独立的职责做起的另一个原因了；快速部署，我们创建新的服务是从空服务开始的，也就是说除了能在产品环境运行之外，它什么都没有。在这个阶段，我们的目标是将服务提取的两大痛苦阶段：创建和部署，变得简单高效。

第三阶段：集成

集成就是将新的云服务与原系统进行对接。

如果说前面两个阶段都是在做准备的话，那么这个阶段就是实施迁移的过程了，可以说这是最为重要的阶段，因为它是新老系统交割的一个时期。在这个阶段会有这样一些活动，首先，识别新服务需要哪些对外的接口，这需要对现存系统有比较深入的了解（当然如果接口比较简单，这一步也可以放在提取阶段来实现）；其次，将现有系统中对要迁移职责的依赖切换到新服务上，这个过程有可能是一次完成，也有可能需要持续完成，主要取决于职责的独立程度以及现有系统依赖管理的复杂程度。最后，将该职责在原系统中移除。以用户管理职责为例，这一阶段就是将现有系统与用户服务集成，并将其该职责从系统中移除。

迁移技巧

理解完这三个阶段之后，不难看出，每两个阶段之间的转换是否高效，流畅，无障碍，对整个的系统向云端迁移都起着至关重要的作用。在长时间的迁移经验的积累下，我们发现以下的一些技巧能够帮助我们在整个迁移阶段中，平滑过渡。如图五所示，当识别出迁移职责后，Stencil＋DevOps 能够帮助我们快速创建和部署云服务，在原系统与云服务对接时，可以由测试来驱动，对接之后，监控能为我们本次迁移周期提供很好的反馈，以便开启下一个迁移周期。下面我们同样以该网站为例，来介绍一下不同阶段之间转换的技巧：

图五

技巧一：快速上线：Stencil + devOps

前文提到，这一过程一定要高效，也就是要迅速地创建并部署新的服务，只有这样做我们才能讲这一过程常态化，如何才能做到呢？我们采用了Stencil+devOps。

Stencil 就是一个服务模版，它能帮助我们快速生成一个空的服务，包括遵循组织规范的目录结构，标准的监控配置和接口，初始化的构建脚本等，使用 Stencil 的好处就是能够快速创建符合组织标准化的服务；devOps 则用于服务的部署上线，维护，持续集成和发布环境的搭建，当然它同样遵循着组织的标准规范。如下所示，该模版主要包括 3 个部分：应用本身，部署脚本（AWS Cloudformation），docker 配置（用于构建）。

技巧二：测试：消费者驱动测试

当我们快速上线一个空服务之后，下一步就是如何快速做两个系统之间的集成，在进行系统间集成时，基本可以分为两个小步骤：定义新服务的接口＋与现有系统的对接。定义服务接口可以是很简单的过程，也可以是很复杂，主要取决于原有系统中该职责的复杂程度。但不管复杂与否，定义服务接口的过程都是一致的——消费驱动。不同于将新服务的所有接口预定义出来，它是按照消费者的需求，驱动新服务提供应有接口的，当然这里的消费者指的是现有系统。

图六

从图六中我们可以看出来，现有系统（即消费者）和新服务（即服务）集成过程是由两组失败＋成功的测试组成，或者说是由两组 BDD 组成。首先是消费者侧的 BDD，中间人扮演了服务的角色，并且我们假定新服务的接口已经按照消费者的要求实现完成，此时由于消费者并没有完成相应代码的编写，所以我们会得到一个失败的测试，接着便是真正的编码，到我们得到一个成功的测试时，意味着消费者端的集成工作就完成了；接着就是服务侧的 BDD，此时的中间人扮演的是消费者的角色，由于服务并没有定义期望的接口，所以我们会得到一个失败的测试，经过编码，我们得到了成功的测试，此时就意味着两个系统之间完成了互联互通，并且有了测试来保证。

技巧三：监控

在我们拆分原有系统之前，所有的模块都被整合在同一个系统之中，对系统的监控是统一的。但是当我们将现有系统拆分之后，就转变为多个独立系统，如何保证新服务良好运行，或者说如何实时监控新服务的运行状态对整个系统的稳定至关重要。在实施监控的时候，我们应该考虑这些方面：

资源利用度以某个虚拟机节点为整体做的关于系统资源的监控

(点击放大图像)

比如说 CPU 利用率，硬盘读写，内存利用率等，主要的目的是检查当前的节点是否出现过载或空闲的状态，得到这些状态信息之后，就能做出相应的处理。过载就说明资源无法满足当前的流量，应该增加节点，部署更多的服务来适应大流量情况；空闲就意味着资源是有富余的，应该减少节点，以便降低成本。
健康检查以服务为整体做的粗粒度的监控

(点击放大图像)

主要的目的是为了检查当前服务是否处于运行状态。如果检测出服务属于不可用状态的话，云端的负载均衡会根据预先的配置，删除该服务，并新增加一个全新的服务用于填补空缺。也就是说，基于当前的架构我们更倾向于重建服务而非修复不可用的服务。
日志所有服务内部状态的监控

(点击放大图像)

上面两种监控都无法得到服务内部运行状态，因此日志监控在这里就显示出了极大的重要性，尤其是两个系统之间集成的日志，通过对系统日志的监控，使我们具有了监控系统内部逻辑的能力，有了这种能力我们就能够追踪事故的发生并得到关键信息，进而优化服务。