MadBOK

# 云迁移和混合云架构设计

当前，公有云正在成为应用程序的主要宿主之一，它可以帮助我们按需获取计算、存储、网络和数据库等技术资源，而不必购买和维护自己的数据中心。云已经成为了企业战略规划中不可缺少的元素，对于正在迁移上云的企业，在迈向云原生之前，首先要关注云迁移策略和混合云架构。

# 云原生架构的好处

组织在使用云时不需要前期投入，得益于云的按需付费模式，实验的风险会变得更小。有了云，我们也可以不再需要提前规划额外的容量来应对旺季的高峰负载，有了云，企业开源在全球范围内快速的获得基础设施，基于云的数据采集、存储、分析和共享的成本更低。

云计算的其他优势还包括云原生的监控和告警机制，依托于自动化的处理，我们可以更好的利用云监控，并且在数分钟内在全球任何地方进行部署，从而构建更好的高可用性和灾难恢复机制。

# 创建云迁移策略

# Lift and Shift

Lift and Shift是最快的迁移方式，它没有利用原生云的优势，而是对应用程序进行最小的变更，从而开始重新托管（rehost）、更换平台（replat-form）及重新部署（relocate）。

  • Rehost：重新托管是套装软件的一种迁移方式，它将本地环境中的服务器或应用程序直接整体迁移到云上，在迁移过程中只需要对应用程序进行最小的更改。
  • Replatform：当操作系统、服务器或数据库版本的服务商终止服务时，如将操作系统从32位替换至64位，更新数据库引擎等，可能会触发更换平台的云迁移过程。这个过程中可能需要在目标环境中重新安装应用程序，在迁移上云的同时升级应用程序的底层平台。
  • Relocate：重新部署可以以最小的工作量和最简单的方式将基于虚拟化和容器技术的应用程序快速部署到云上，利用VMotion可以将虚拟实例从一台物理主机迁移至另一台主机，而不会中断服务。

# 云原生方法

转向云原生需要较高的成本，但是随着时间的推移，成本会急剧下降，因为在按需付费模式下，我们可以将工作负载优化到合理的价格水平，同时保障原有的性能。常见的有重构（Refactor）和重新采购（Repurchase）两种云原生迁移方法。

  • Refactor：重构是指在应用程序迁移上云之前，对其进行重新架构和重写，使其成为云原生应用程序，然后迁移上云。Refactor的常见示例包括将平台更改为Unix、从传统数据库替换为云数据库、替换中间件产品、重新编码应用程序组件，使其符合微服务架构等。
  • Repruchase：当IT资源和项目都迁移上云后，可能需要为某些服务器或应用程序购买许可证和发行版，也可以删除现有应用程序并在云上替换为其他SaaS版本的应用。

# Retain or Retire

在云迁移时，可能不需要迁移所有应用程序，由于技术限制，我们可能需要保留一些应用程序，因为与本地耦合的遗留应用可能无法移动，另一方面，我们也可能要停用某些服务并使用云原生功能（如第三方应用监控和告警系统）进行替代。

  • Retain：某些看不到迁移上云价值的遗留应用程序或者云不支持的操作系统和应用，我们可以继续让它们运行在本地环境中，我们要确保本地服务和云环境的连通性。
  • Retire：如果应用程序很少使用，或消耗过多的资源导致可能不在被需要，我们就可以停用现有的工作负载，并采用全新的云原生方法。适合停用策略的主机和应用包括灾难恢复的本地服务和存储、可以合并的冗余重复资源等。

# 云迁移的步骤

云迁移包括以下步骤：

# 发现工作负载

在云迁移的发现阶段，要收集关于云迁移投资组合的具体数据，确定哪些服务器和应用程序将被纳入项目投资组合，以及其之间的依赖关系，然后根据收集到的信息来确定应用程序之前的连通性和容量要求，从而设计云环境的架构，明确其成本。

在这个节点我们要确定如下几类问题：

  • 哪些资源已经迁移上云？
  • 应用程序的依赖项有哪些？
  • 云迁移的业务驱动因素是什么？
  • 整个迁移项目的预估时间是多久？
  • 迁移过程要经历多少个阶段？

在发现的过程中，我们要逐步整理出下方完整信息：

  • 服务器的数量清单
  • 服务器的规格
  • 服务器的利用率和性能指标
  • 服务器的依赖关系
  • 前面的网络详情

市面上有些工具可以将发现过程自动化，并提供各种形式的详细信息，发现过程的复杂性取决于组织的工作负载以及是否已经有维护良好的资源清单。

# 分析信息

为了确定服务器和应用程序的依赖关系，需要分析主机的网络连接数据、端口连接、系统和进程信息。可以将所有的外部连接可视化识别其依赖，也可以通过查询列出所有运行的特定进程、使用特定端口或特定主机通信的服务器。

在云迁移项目中，发现、分析和计划环环相扣，我们应对云迁移投资组合中的每一个服务器或应用程序进行如下操作：

  • 根据组织的采购策略，选择服务器和应用程序的迁移策略。
  • 确定其资源迁移上云的优先级。
  • 将资源迁移上云的约为驱动因素记录下来。

# 制定迁移计划

在迁移计划中，我们应该创建有序的应用程序迁移待办，其主要的目标如下：

  • 选择迁移策略
  • 定义迁移的成功标准
  • 确定云资源的合理规格
  • 确定应用程序的迁移优先级
  • 确定迁移模式
  • 制定详细的迁移计划、检查清单和时间表
  • 创建迁移Sprint团队
  • 识别迁移工具

为了准备迁移计划，必须对云迁移投资组合中所有IT资产进行详细的探索，云上的目标环境应该架构完毕，应用的迁移顺序可以通过以下三个步骤来确定：

  1. 从多个业务和技术维度评估每一个与迁移潜在相关的应用程序，以准确量化环境。
  2. 使用量化评级来标识每个应用程序的依赖程度，以识别所有基于依赖关系的排序约束。
  3. 确定组织所需的优先级策略，以决定各个维度合理的相对权重。

迁移过程中需要关注如下几个方面：

  • 迁移前，收集应用程序的基准性能指标。性能指标有助于量化设计或优化云上的应用程序架构。
  • 为应用程序创建测试计划和用户验收计划。
  • 准备切换策略和回滚计划，根据迁移的结果来确定应用程序应该如何以及在何处运行。
  • 利用运维和管理计划，确定迁移中和迁移后的各个角色职责。
  • 确定应用程序团队的对接人，以便在出现紧急状况时可以互相提供支持。

# 设计应用程序

设计阶段的重点应放在迁移应用程序上，需要确保应用程序迁移上云后，满足最新的验收标准。此阶段需要全面了解如账户、网络配置、连通性、安全、监控等的本地基础设施和云基础设施。

在进行应用程序网络设计时，需要考虑以下因素：

  • 流入应用程序边界的网络数据包
  • 外部和内部流量路由
  • 用于网络防护的防火墙规则
  • 应用程序与互联网和其他内部应用程序的隔离
  • 网络合规性和治理
  • 网络日志和网络流的审计
  • 应用程序的风险水平
  • 生产和非生产环境的网络要求
  • 组织业务单元层面的网络边界
  • 网络安全保护与预防措施

# 执行应用程序上云

执行应用程序上云策略，通常会迁移整个服务器。或者只是迁移应用程序中的数据：

  • 数据迁移：是指将现有数据移动到新的云存储位置的过程，其过程包括从源数据库中提取信息后迁移数据。
  • 服务器迁移：可以通过在源系统上创建快照，然后将其发送到目标系统这种方法实现一次性迁移，或者使用虚拟机拷贝方法，复制虚拟机的景象后导入云端，也可以将应用程序容器化，然后将其重新部署到云上。

# 集成、验证和切换

在这一阶段，需要首先使用制定的流量进行必要的云功能检查，以确保应用程序在正确的网络配置下运行，基本的云功能检查完毕后，才可以根据需要启动或停止实例，此外，还需要验证服务器配置是否与预期一致。

在集成阶段，将集成应用程序迁移上云，并通过外部依赖验证其功能后，需要通过单元测试、冒烟测试和用户验收测试来验证集成。

集成完毕后的阶段是切换，在这个过程中，需要采取必要的措施将应用程序流量从原来本地环境重定向到目标云环境中。确定切换策略时需要考虑以下因素：

  • 应用程序可接受的停机时间
  • 数据更新的频率
  • 数据访问模式，如只读或静态数据
  • 应用程序的特定要求，如数据库同步、备份和DNS域名解析
  • 业务约束，如进行切换的特定日期或时间

下图阐述了一种实时零停机迁移的切换策略：

# 运维云应用程序

云环境的运维和数据中心有很大的不同，在数据中心，为项目搭建物理基础设施是由IT部门负责，这意味着需要确保服务器具有适当的物理环境保护措施，云环境中不需要管理这类物理资源，需要配置新服务器时，计算资源可以成为按需置配合取消的服务。

以下是需要在云上进行的IT运维工作：

  • 为服务器打补丁
  • 监控服务和应用程序日志
  • 事件管理
  • 云安全运维
  • 配置管理
  • 云资产管理
  • 变更管理
  • 通过灾难恢复和高可用性实现业务连贯性

传统环境下，开发团队和运维团队各自为政，开发从业务负责人处收集需求并开发构建系统，系统管理员独立负责运维，满足系统正常运行的要求，在开发生命周期周，这些团队很少进行沟通，所以会导致工作冗余甚至产生冲突。

DevOps方法中，推荐开发团队和运维团队在软件开发生命周期的构建和部署阶段协同工作，共同分担责任并提供持续的反馈，在整个构建阶段，将在类生产环境中对软件版本进行频繁测试，从而尽快验证问题。

# 云上应用程序优化

优化云上应用程序是非常重要的工作，这是一个持续改进的工作，主要的优化领域如下：

  • 成本：考虑当资源需求波动时，如何优化应用程序的成本效率。
  • 安全：持续检测和改进组织的安全策略和流程，以保护云上的数据和资产。
  • 可靠性：优化应用程序的可靠性以实现高可用性，并为应用程序设定故障恢复、流量增长等需求的补偿措施。
  • 运维：优化运维效率以及运行和监控系统的能力，以便交付业务价值并不断改善支持流程和程序。
  • 性能：针对性能进行优化，以确保系统架构能为一组资源提供高效的性能。

在公有云上，只需要为使用的资源付费，可以通过关闭不需要的实例来降低成本，通过自动化实例部署，根据需要拆除或重构实例。卸载的资源越多，需要维护和扩展的基础设施就越少。

优化成本的另一种方法是设计弹性架构，确定资源的合理规模，使用自动伸缩策略并根据价格和需求调整利用率，应用程序架构的调整也可以提高应用程序性能，例如通过缓存卸载web页面流量，从而提供更好的用户体验。

# 创建混合云架构

云的价值不断提升，很多大型企业正在将工作负载迁移到云上。尽管如此，要在一天之内完全迁移上云通常是不可能的，对于大多数客户而言，这将是一个长期过程。客户通常会寻求一种混合云模型，将应用程序的一部分维护在本地环境中，并与云上的其他模块进行通信。

在混合部署方案中，需要为本地环境中运行的资源建立 与云环境的连接。最常见的混合部署方法是在云和现有的本地基础设施之间，逐步将组织的基础设施扩展并迁移到云上，在此期间保持本地系统与云资源连接。创建混合云架构的常见原因可能包括：

  • 当重构应用程序并通过蓝绿部署模型将其部署上云时，希望在本地运维遗留应用程序
  • 遗留的应用程序没有兼容的云方案，必须继续在本地运行
  • 处于合规性要求，部分应用程序必须保留在本地
  • 为了加速迁移，要将数据库保留在本地，而应用服务器先被迁移上云
  • 云上的数据流水线需要从本地数据库提取数据

云供应商提供了一种机制，可以将客户现有的基础设施与云集成，这样客户就可以轻松地将云作为其基础设施的无缝扩展来使用。这些混合架构使客户可以完成网络集成、安全和访问控制功能，支持工作负载的自动化迁移，并可以通过其本地基础设施管理工具控制云。

以AWS云为例，我们可以通过VPN建立与AWS云的安全连接。由于VPN连接是基于互联网建立的，因此可能会存在延迟问题（这是因为第三方互联网服务商有多个路由器跃点）。我们可以使用AWS Direct Connect (直连服务）将光纤专线直连到AWS云，以获得更好的延迟表现。

# 设计云原生架构

云原生并不意味着应用程序托管在云平台上，它主要是指充分利用云提供的服务和功能，其包括：

  • 在微服务中将单体架构容器化，并创建用于部署的CI/CD流水线
  • 使用函数即服务、云上托管的数据库之类的技术，构建无服务器应用程序
  • 使用云原生的托管的对象存储服务、集群、日志监控等服务

下图是一个云原生的无服务器架构：

架构利用了AWS云的云原生无服务器服务。其中，Amazon Route53用来管理DNS服务，并路由用户请求。Lambda将函数作为服务来管理，用于处理用户验证、用户资料和博客页面的代码。所有博客资产都存储在Amazon S3 (用于管理对象存储服务）中，所有的用户资料存储在Amazon DynamoDB (NOSQL存储）中，用户发送请求后，AWS Lambda将对用户进行验证并查看其个人资料，确保Amazon DynamoDB中存在他们的订阅。之后，它将从Amazon S3中找到博客的资产 （例如图片、视频和静态HTML文字），并将其展示给用户。

该架构可以无限伸缩，因为所有的服务都是云原生托管服务，你不需要处理任何基础设施。这些云原生服务会处理诸如高可用性、灾难恢复和可伸缩性等关键因素，因此你可以专注于功能开发。在成本方面，只有当请求到达博客应用程序时，才需要付费。如果晚上没有人浏览博客，就不需要为托管代码支付任何费用，只需要支付名义上的存储费用。

← 解决方案架构的设计模式 →