采集系统上云(互联网系统图一图一是的迁移到云端，以便获取这种能力 )

　　采集系统上云(互联网系统图一图一是的迁移到云端，以便获取这种能力

)

　　在互联网大行其道的今天，毫不夸张地说，对市场的反应速度甚至将决定一家公司的生死存亡。我们的客户（房地产垂直搜索平台）就是这样一家互联网公司。为了缩短开发周期，减少系统上市时间，我们将现有的基于传统数据中心的基础设施迁移到云端，以获得这种能力。

　　在此之前，我们先来看看他们现有的系统。

　　1、现有系统

　　图1

　　图 1 是现有核心系统的简单抽象。我们维护三个业务线（这里指的是业务为主，有独立的产品经理、销售团队、独立的结算团队，以下简称LoB），每个业务线对应不同类别的房产搜索网站@ >，如商业和住宅。User是一个用户管理模块，可以提供用户管理、书签和搜索管理；Location是一个定位模块，根据用户的搜索条件给出实际地址和相邻地址；搜索引擎用于存储所有信息并提供搜索功能。可以看出，三个LoB虽然不同网站@>，但提供的服务却是相似的。不仅，

　　基于以上原因，它们应该集成在一个系统中，但它们不是。这些业务线虽然有如此高的相似度，但在以下几个方面却大相径庭：

　　由于不同的属性有不同的搜索条件，所以部署时需要对不同的网站@>进行不同的配置。

　　不同的楼盘有不同的目标市场，需求决定了要开发哪些特色，开展哪些营销活动。因此，每个业务线都有自己的销售和开发团队，并根据市场变化开发和发布相应的功能。计划。

　　在图1中，不同的颜色表示不同的流量级别，红色表示最大流量，*敏*感*词*表示中等流量，绿色表示较低流量。对于不同类型的物业，市场需求是不同的。

　　商业地产的目标客户是需要开展商业活动的人，而住宅地产的目标客户是希望为子女生活或提供更好教育机会的普通人。

　　2、商业愿景

　　了解了现有系统之后，再来看看他们的业务愿景，因为没有一家公司的 IT 转型是独立于业务驱动的，了解业务愿景有助于更清楚地了解迁移上云背后的原因。同时，对云策略的适用场景也有了更直观的认识。

　　这意味着每个团队都将是一个完全独立的全功能团队，拥有独立的系统和独立开发、部署、运维、营销和销售的能力。这为每个团队提供了非常大的自主权，以及对业务扩展和收缩的非常好的适应能力。

　　这里所说的效率主要是指IT生产活动的效率。本质上，他们是一家互联网公司。如何提高IT系统的效率来支持业务的发展是他们看重的。比如提高人的效率，开发、上线、测试、运维、在线反馈等等，全方面的效率。

　　中国可能是世界上最活跃的房地产市场之一。与此同时，海外房地产投资在中国持续升温。他们没有理由错过这个机会，不仅在德国、意大利和中国香港。

　　基于以上差异，图1所示的系统架构显然不能满足客户对业务愿景的实现。主要问题如下：

　　由于这是一个集成了所有 LoB 的系统，因此业务线之间存在耦合。试想这个场景，LoB1已经根据市场反馈完成了房产中介品牌的提升，希望在涨价前上线，因为这将是涨价的合理理由。同时，LoB2正在开发新的页面以满足业主品牌的需求，但这个功能只开发了一半。按照目前的模式，我们要等LoB2完成功能开发后才能一起上线，这样就错过了LoB1涨价的机会，下一个涨价窗口将在几个月后。

　　通过流量监控，我们发现网站@>的流量并不是一成不变的。按年计算，网站@> 的流量会在圣诞节前下降到平时水平的 50% 左右，圣诞节后可能会上升到 50%。平均水平在200%左右，这么大的流量会持续一周左右。其实这种情况也不难理解，因为圣诞节期间大家都在放假，放假后还会有一波工作。从图1我们也可以清楚的看到不同组件的不同流量。为了保证整体的响应速度，系统总是以较高的流量部署。但是，由于每个 LoB 都不能独立部署，因此浪费了资源。情况非常明显。

　　我们之前提到了全球扩张计划。他们想进入中国市场，所以需要设计一个独立的网站@>给中国用户提供住房。为国家房地产市场的扩张做准备，为了实现这个目标，我们需要IT基础设施的支持，可以快速灵活地横向扩张。但基于现有的数据中心模式，这将是一个痛苦的过程。

　　3、架构愿景

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

　　必须能够根据业务线独立运作

　　易于扩展或可扩展

　　解决从开发到部署的所有问题，开发者更关注如何更快地交付功能，而不是各种环境问题、部署问题、发布问题

　　提高资源利用率，根据不同流量情况自适应分配资源。

　　基于这个愿景，我们发现云平台可以帮助我们实现这样的IT愿景。图 2 描述了系统上云后的架构。

　　图二

　　一是所有业务线独立运营，可以自主选择何时发布上线，选择合适的SLA和资源以适应流量变化；其次，所有业务线共享的组件独立于业务线。此外，它们分别部署和运行，还可以调整不同的资源以适应流量的变化。

　　4、迁移三部曲

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

　　图 3

　　如图3所示，在迁移上云时，从现有系统迁移到目标系统的过程不是一次性的过程，也不是一次性的迁移，而是一个周期性的、持续的过程。是相关系统整合的结果。如果我们关注其中一个迁移周期，则该过程大致可以分为三个阶段：

　　阶段 1：识别

　　识别就是弄清楚要迁移的内容。

　　对于原来的集成系统来说，这个过程与聚合相反，就是对聚合的所有功能特征进行分析和分解。本次活动的目的是深入了解当前系统的职责。明确职责后，我们可以更好地确定哪些职责可以剥离、拆分、独立。比如这个房产搜索网站@>，经过识别发现我们的主要职责是：前端展示（桌面、手机）、房产搜索、搜索管理、用户管理、地理位置查询、并且还提供了部分API。识别完成后，我们要选择从哪个职责开始迁移。这个过程不是随机的，而是基于现有的团队能力，

　　我的建议是从简单且相对独立的职责开始。如果能同时支持业务发展，那就更好了。因为难度低，可以在迁移初期给团队带来信心和经验。随着迁移经验和信心的积累，那些高耦合、多依赖的职责可以轻松迁移。以这个房产搜索平台为例，在迁移初期，我们选择用户管理职责进行迁移，一方面是因为它比较简单，相对独立，另一方面是因为它为我们提供了API支持。 iOS开发。

　　第 2 阶段：提取

　　在确定了系统职责并确定了要迁移的职责之后，是时候将该职责提取为独立的云服务了。

　　图 4

　　如上图所示，这个阶段的核心是将识别出的职责从原有系统中分离出来，成为独立的云服务。这个过程有几点需要注意：创建快，需要多快？理想状态是创建成功（空服）后上线（灰度发布）。或许这个目标在迁移之初并不容易实现，但随着迁移信心和经验的积累，是完全可行的，当然这也是我们从简单且相对独立的职责入手的另一个原因；为了快速部署，我们从一个空服务创建一个新服务，这意味着它可以做任何事情，除了在生产环境中运行。不。在这个阶段，我们的目标是抽象出服务的两个痛苦阶段：创建和部署，

　　第三阶段：整合

　　集成是将新的云服务与原有系统连接起来。

　　如果说前两个阶段都是准备，那么这个阶段就是实施迁移的过程。可以说这是最重要的阶段，因为这是新旧系统交付的时期。这个阶段会有一些活动。首先，确定新服务需要哪些外部接口，这需要对现有系统有更深入的了解（当然，如果接口比较简单，这一步也可以在提取阶段实现）；其次，将现有系统中待迁移职责的依赖切换到新服务。这个过程可以一次完成，也可以连续完成，这取决于职责的独立程度和现有系统依赖管理的复杂程度。最后，从原创系统中删除责任。以用户管理职责为例，这个阶段是将现有系统与用户服务进行整合，并将该职责从系统中移除。

　　5、迁移提示

　　了解了这三个阶段之后，不难看出两个阶段之间的过渡是否高效、顺畅、无障碍，对整个系统上云的迁移起到至关重要的作用。随着长期迁移经验的积累，我们发现以下技巧可以帮助我们在整个迁移阶段顺利过渡。如图 5 所示，在明确迁移职责后，Stencil+DevOps 可以帮助我们快速创建和部署云服务。原系统对接云服务后，可通过测试驱动。对接后，监控可以为我们提供这个迁移周期。伟大的反馈开始下一个迁移周期。让我们也拿这个 网站@>

　　图 5

　　提示 1：快速启动：Stencil + devOps

　　如上所述，这个过程必须高效，即快速创建和部署新服务。只有这样，我们才能使这个过程正常化。我们该怎么做？我们采用了 Stencil+devOps。

　　Stencil 是一个服务模板，它可以帮助我们快速生成一个空服务，包括一个遵循组织规范的目录结构、标准的监控配置和接口、初始化的构建脚本等。使用 Stencil 的好处是可以快速创建一个组织标准化服务。服务; devOps 用于服务部署、维护、持续集成和发布环境的建立。当然，它也遵循组织的标准规范。如下图，模板主要由3部分组成：应用程序本身、部署脚本（AWS Cloudformation）、docker配置（用于构建）。

　　提示 2：测试：消费者驱动的测试

　　当我们快速启动一个空服务时，下一步是如何在两个系统之间快速集成。系统间集成时，基本上可以分为两个小步骤：​​定义新服务的接口+与现有系统对接的接口。定义一个服务接口可以是一个简单的过程，也可以是一个复杂的过程，这取决于原创系统中职责的复杂性。不管复杂与否，定义服务接口的过程都是一样的——消费驱动。不同于预先定义新服务的所有接口，它驱动新服务根据消费者的需求提供合适的接口。当然，这里的消费者指的是现有的系统。

　　图 6

　　从图6可以看出，现有系统（即消费者）与新服务（即服务）的集成过程是由两组失败+成功的测试，或两组BDD组成的。首先是消费者端的 BDD。中间人扮演着服务的角色，我们假设新服务的接口已经按照消费者的要求实现了。这时候，由于消费者还没有写完相应的代码，我们会得到一个失败，然后才是真正的编码。当我们得到一个成功的测试，就意味着消费者端的集成工作已经完成；然后是服务端的 BDD。这时，中间人就扮演了消费者的角色。该服务没有定义预期的接口，所以我们会得到一个失败的测试。编码后，

　　提示 3：监控

　　在我们拆分原系统之前，所有模块都集成到同一个系统中，对系统的监控是统一的。但是当我们将现有系统拆分成多个独立的系统时，如何保证新服务的良好运行，或者如何实时监控新服务的运行状态，对整个系统的稳定性非常重要。在实施监控时，我们应该考虑以下几个方面：

　　基于虚拟机节点整体监控系统资源

　　比如CPU利用率、硬盘读写、内存利用率等，主要目的是检查当前节点是否过载或空闲。过载意味着资源不能满足当前的流量。应增加节点并部署更多服务以适应大流量情况。空闲意味着资源过剩，应减少节点以降低成本。

　　对服务整体进行粗粒度监控

　　主要目的是检查当前服务是否正在运行。如果检测到该服务不可用，云负载均衡会根据预先配置删除该服务，并添加一个新的服务来填补空缺。也就是说，基于当前的架构，我们更愿意重建服务而不是修复不可用的服务。

　　监控所有服务的内部状态

　　以上两种监控都无法获取到服务内部的运行状态，所以日志监控在这里显得尤为重要，尤其是两个系统之间集成的日志。通过监控系统日志，我们就有了监控系统内部逻辑的能力，有了这个能力，我们就可以跟踪事故的发生，获取关键信息来优化服务。

　　总结

　　从传统数据中心基础设施迁移到云端是一个长期的过程，可能还有很多未知的问题在等着我们，但我们发现同时也是一个重新认识现有系统的过程。在此期间，我们发现了一些规律。每个功能的迁移都有自己的特点，同时又是相似的。这种相似性的提取是：识别、提取和整合。