应用上云方案设计

产品选型策略

针对传统应用平迁上云场景，常见产品对标选型策略如下图所示。

场景示例1：单体应用迁移

云上重部署应用

针对平迁方式的应用上云场景，对于已有成熟CI/CD工具及流程的企业，我们建议优先使用现有CI/CD工具，在云上重新部署应用。

对于还没有构建CI/CD能力的企业，我们建议先使用云上DevOps产品构建企业的CI/CD自动化平台，通过CI/CD流水线，在云上重新部署应用。基于阿里云云效产品构建CI/CD流水线如下图所示。

镜像迁移

对于普通单体应用，也可以使用阿里云自主研发的迁移平台服务器迁移中心（Server Migration Center，简称SMC），可将单台或多台迁移源迁移至阿里云。迁移源（或源服务器）概指企业待迁移IDC服务器、虚拟机、其他云平台的云主机或其他类型的服务器。在应用服务迁移过程中，使用SMC服务将在IDC部署的业务应用服务自动、快速、一站式迁移到云上ECS，同时提供工具支持将自建Kubernetes的应用迁移到云上。更多详细信息，请参见最佳实践概览。

场景示例2：微服务应用迁移

对于微服务应用上云，可以使用阿里云企业级分布式应用服务EDAS（Enterprise Distributed Application Service），它是一个应用托管和微服务管理的PaaS平台，提供应用开发、部署、监控、运维等全栈式解决方案，支持Spring Cloud、Dubbo等微服务运行环境。

对于Spring Cloud Edgware及以上版本和Dubbo 2.5.3及以上版本的微服务应用，无需修改任何一行代码即可迁移至EDAS。

针对Spring Cloud和Dubbo微服务框架应用迁移上EDAS，有两种方案，切流迁移、双注册和双订阅迁移。这两种方案都可以保证您的应用正常运行且不中断地完成迁移。

切流迁移

使用Dubbo将原有的服务注册中心切换到微服务引擎（Micro Service Engine，简称MSE），在云上部署一套新的应用，最后通过SLB和域名配置来进行切流。

双注册和双订阅迁移

• 在应用迁移时同时接入两个注册中心（原有注册中心和EDAS注册中心），保证已迁移的应用和未迁移的应用之间能够相互调用。通过双注册和双订阅迁移应用的架构图如下。

• 支持在不重启应用的情况下，动态地变更服务注册的策略和服务订阅的策略，只需要重启一次应用就可以完成迁移。

• 已迁移的应用和未迁移的应用可以互相发现，从而实现互相调用，保证了业务的连续性。

• 使用方式简单，只需要添加依赖，并修改一行代码，就可以实现双注册和双订阅。

• 支持查看消费者服务调用列表详情，实时地查看迁移进度。

• 更多详细信息，请参见产品最佳实践平滑迁移微服务应用至EDAS

场景示例：应用容器化上云

以Kubernetes为代表的容器技术正在成为云计算新界面。容器提供了应用分发和交付标准，将应用与底层运行环境进行解耦。Kubernetes 作为资源调度和编排的标准，屏蔽底层架构差异性，帮助应用平滑运行在不同基础设施上。

应用容器化规范化改造

容器化的应用必须要规范化，我们不希望所完成的容器镜像只能在生产环境中运行，也不希望该容器有着外部依赖，我们希望应用在容器化之前，最少满足以下三项要求：

• 与操作系统解耦，能在各种系统中运行并有极大的可移植性

• 适合部署在现代的云平台上，配置与代码分离

• 开发与生产环境对等，能够使用现代的包管理工具实施封装打包

所以，对应用进行容器化前，必须对应用进行检查并实施类似的改造，也就是进行应用规范化，规范化的过程根据已有应用的实际情况有较大的不同，一般来说，越是现代的、面向互联网的应用越容易容器化。对容器化应用的规范化改造有以下内容：

• 准代码：明确一份代码，多份部署的原则，一个应用程序只能有且只有一个代码库或一个主库，确保该代码库中能够支持开发、测试、构建操作。

• 依赖管理：大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，我们期望应用程序能够显式地表示自己的依赖，使用pom.xml或者package.json来描述自己的全部依赖，不要有隐式依赖。这样能够为开发者和流水线简化配置流程，可以完成一句话构建。

• 配置注入：数据库地址、三方证书、API Key等等这些在不同环境下有区别的配置应该能够独立注入，我们要求在不同环境下，容器一致，但配置不同。可以使用环境变量或 Config Service 方式进行管理，使用Config Service时也需要做到无依赖。

• 服务配置化：后端依赖的服务比如数据库MySQL、PostgreSQL、缓存、队列等都需要做到可配置化，将配置拿出，系统不应该区别对待这些服务。

• 进程整理：应用程序尽量做到一个进程运行，如果使用多个进程比如Nginx + PHP也可以接受，但一定要目的单一，易于管理。同时也需要保证进程的无状态特性，使用内存存储 session 造成粘性是无法接受的，并且状态应该持久化入数据库。单一的、无状态的进程也可以反映到并发上。

• 易处理：表示可以瞬间开启或停止，这有利于快速、弹性地伸缩应用，迅速部署变化的代码或配置，稳健地部署应用。当然也需要支持优雅的终止，即受到SIGTERM后会处理完任务，或者在服务中心注销，再进行关闭。

容器化上云流程

传统应用容器化大致分为五个阶段：

• 应用现状分析：梳理应用使用的资源、系统的逻辑架构拓扑、应用服务的所有数据依赖、应用上下游服务依赖关系、服务所依赖的进程、系统中需要保留的重要日志及数据、数据和文件权限等；

• 方案规划和设计：根据前期对应用系统现状的调研和分析结合容器平台特性，应用系统产出新的系统架构图和迁移的改造计划，比如是直接容器化上云还是改造后再容器化上云，以及容器化后业务系统功能和性能测试方案、系统的割接方案等。

• 编写Dockerfile：若要打包应用程序以供在Docker中运行，需要编写脚本文件Dockerfile，用于自动执行所有应用程序部署时需要执行的步骤。这通常包括一些Shell配置命令，以及用于复制应用程序包、设置所有依赖项的指令，也可以解压缩已压缩的存档或安装包。Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。在Docker镜像使用中，我们最好把经常变化的内容和基本不会变化的内容要分开，把不怎么变化的内容放在下层，创建一个基础镜像供上层使用。

• 生成镜像：使用docker commit命令将某个container的环境提交成为持久化的docker image。使用docker build命令基于dockerfile构建。 这种构建方式的优势在于可以通过docker history命令溯源镜像的生成过程。并且消除了docker commit可能把一些不需要的东西误提交的隐患。镜像构建成功后，只要有docker环境就可以使用，通过利用docker push命令将镜像推送到镜像仓库中去。

• 应用部署：将docker镜像部署到对应Kubernetes集群应用。在Kubernetes集群上需要用到的部署模板，在具体实施过程中，可以根据不同的模板来部署到对应不同的集群。

传统单体应用架构问题

• 单体应用复杂度高，应用迭代发布周期慢，无法支撑业务快速发展的需求。

• 开发者需要关注架构的所有细节（限流、熔断、降级等服务治理，数据访问及消息通信）。

• 运维需要负责底层基础设施（包括数据库、缓存、虚拟机等）的稳定性。

云原生应用架构

云原生应用架构特点

• 应用代码按业务域拆分解耦，降低复杂度。

• 开发者只需关注业务逻辑，与业务不相关功能下沉到云基础设施。

• 技术体系走向开放和标准。

• 运维无需关注基础设施稳定性，更多精力专注于自动化。

云原生应用架构建议

云原生应用架构示例，如下图所示。

• 微服务解决“应用架构复杂度”问题。

• 服务治理解决“业务开发关注与业务无关的限流、熔断、降级能力”。

• 容器解决应用“部署问题”问题。

• Kubernetes解决应用“编排和调度”问题。

• Service Mesh解决“侵入性微服务改造”问题。

场景示例：应用微服务化重构上云

对于复杂应用系统来说，单体应用架构代码复杂度高、可扩展性差、业务开发及部署周期慢，不能满足现业务发展需要。对于业务复杂的单体应用系统上云需求，我们建议以微服务化重构改造上云。

核心问题

• 服务拆分

  如何将单体应用进行服务化改造，是“一步到位，推倒重来”还是“循序渐进的蚕食”，选取哪些功能或业务进行服务化改造，如何减少对原单体应用的修改等，这些都是在服务拆分时首要面对的问题。

• 跨服务查询

  单体应用里实现查询相对简单，因为具有统一的数据库。但在微服务架构下，一个查询可能需要检索分布在不同的服务中数据，而这些服务都会拥有自己的数据库。传统的分布式数据查询机制不适用，因为会打破服务之间的数据隔离性，该隔离性要求以服务的形式提供数据，不能直接暴露数据库。

改造原则

• 渐进式，不要“推倒重来，一步到位”

  • 快速见效、快速收到回报、可挑选出高价值的模块先进行服务化改造，更早的拿到结果来获得业务团队的支持。

• 减少对单体应用的改动

  • 单体应用的修改是不可避免的，重要的是要减少改动同时保持数据一致性。

• 改造主要从业务维度入手，少量的技术维度。

• 拆分时做“垂直切片”

  • 含业务逻辑、库表结构等前后端逻辑。

改造策略

（1）新业务构建为服务

将新的业务或功能以服务的形式进行构建，这不仅会阻止单体扩大和继续发展，快速开发出新业务功能，更体现出微服务架构的价值。常见的办法是对新业务进行领域建模，得到领域模型、服务接口等必要元素。但同时会带来问题，即新旧系统结合，即微服务与单体应用怎么协作。

• 问题识别

  无论是新构建的微服务，还是旧系统提取的新服务，都会面临新旧系统如何结合的问题。新的微服务与单体应用同时存在，许多业务还需要新旧系统彼此协作才能完成。但新旧系统存在各种差异，如：协议不同（微服务以REST为主，而单体式可能基于SOAP或TCP），模型不同（实体、名称及属性等）。我们推荐的方案是使用双向代理层来完成新旧系统的交互与对接。

• 解决方案

  • 双向代理层

  在微服务和单体应用之间构建一个双向代理层，通过代理层完成新旧系统的对接集成，避免相互干扰，保持彼此松耦合状态。代理层还可以对单体式应用进行服务化封装，让其像微服务一样以 REST的方式对外服务。代理层支持双向通讯，重点解决新旧系统对接集成、协议适配和模型转换等问题，按照此功能定位我们可以将代理层划分成三个模块：

  • 旧系统侧的集成对接：采用外观（Facade）模式，屏蔽旧系统内部细节，简化新系统对接的复杂度。

  • 旧系统侧的协议适配：采用Adapter模式，向新系统提供所需的服务实体，负责请求和应答的协议适配。

  • 领域模型转换器：负责请求和应答中新旧系统领域模型的转换，新旧系统都需要。

  • 领域事件

  单体与微服务之间的数据交互，使用API是较为直接的方式。但当一方数据变化后，API方式无法主动进行通知。因此，另一个方式是基于领域事件的数据同步。比如：单体应用发布领域事件，微服务进行订阅。当单体数据产生变化时，可以通过领域事件的方式通知微服务，微服务获取事件，更新本地数据，供本地业务查询使用。

（2）业务功能提取为微服务

• 挑战：对单体应用做拆分时，采取的策略是自上而下的“垂直切分”，要涵盖被拆分的业务的全部逻辑，主要包含业务逻辑及数据库表。为此带来了一些挑战：

  • 领域模型的拆分：跨服务的对象引用、通用类的拆分等

  • 数据库表的拆解分，如：从已有的表中拆出新表

• 提取入口：关于提取哪些部分进行服务化，一个重要判断点是否能给业务快速带来价值，而价值可以从新业务上线效率，或解决棘手的性能及扩展性等方面来考虑。一般来说，具有下面特点的功能模块可以入手来做改造，提取功能为服务后，同时也需要重构数据库。如：改造数据库的库表结构，提取并创建新服务对应的表及数据。

  • 频繁变化（业务维度）

  • 频繁调用

  • 相对独立

  • 共享的基础数据

  • 计算密集型（利于弹性伸缩，技术维度）

• 最小化改造：对单体应用进行改造，势必会带来领域模型、库表结构等的变化。例如：我们拆分订单业务，提取出送货子业务。这些变化会直接影响代码，即要求对变化的部分做出代码调整。由于每一处访问变化部分的代码都需要，这会直接修改单体应用的代码，可能带来较大工作量，这是我们不愿意看到的，因为大量工作花费在要被替代的单体应用上。理想的方式是，在拆分出新服务的同时，不修改或尽量减少修改原有单体应用。

  • 保持单体应用的数据库结构基本不变；

  • 拆分出的新服务使用独立的新库表结构；

  • 新服务获取数据后写入新的库表；

  • 使用触发器之类机制将新库表的数据同步到单体应用库表；

  • 在单体应用里，只需修改代码去调用新服务即可；数据读取可依赖原有单体应用。

场景示例：阿里云SAP上云方案

SAP HANA是一个软硬件结合体，提供高性能的数据查询功能，结合了大量交易与实时分析能力，显著提升商业效率，助力企业数字化转型。阿里云多个ECS企业级云服务器产品规格通过SAP HANA认证，企业用户可以在阿里云上放心部署和运行基于SAP HANA数据库的关键业务系统。SAP在企业管理软件领域有着丰富经验，结合阿里云弹性和可扩展性、快速部署、高度稳定性、全球基础设施等优势，可以帮助企业轻松应对业务变化，加速业务系统的部署。

阿里云SAP上云及云上运维最佳实践

针对企业用户SAP上云的需求，阿里云提供了场景丰富的SAP云上部署及运维最佳实践，详情参见以下。

• SAP S/4HANA 同可用区高可用部署指南

• SAP HANA 同可用区高可用部署指南

• SAP HANA Scale-Out 部署指南

• ECS Metrics Collector for SAP部署指南

• SAP系统云盘扩容指南

• SAP系统高可用环境维护指南

数据上云架构设计

数据在同一业务库中采用多租户隔离机制；为数据服务层建立一套统一的管理规范，所有业务用户账号在完成相关审批流程后对相应的数据字段进行授权安全访问，对数据只有读的权限，不能对原始数据进行直接修改或删除，做到数据不搬家，可用不可见；建立统一的数据资源视图和数据血缘跟踪能力，能够对所有的数据的生命周期进行溯源查询，用以甄别数据变更过程中的真实性和准确性；根据不同业务场景结合流程节点和风险管控要求，对相关数据进行分析、建模、挖掘，提高数据服务支持。

数据上云安全防护

在企业数据迁移上云的过程中,实施数据分层保护功能已成为一个关键优先事项。同时，数据保护控制必须辅之以强大的监控工具和访问管理控制,以构建数据的整体视图，对数据的全生命周期进行监控。重点考虑以下关键数据保护领域。

• 数据分类：围绕数据识别、清单、标签和分类的功能和流程；

• 静态数据保护：有关加密/令牌化的解决方案和注意事项,包括密钥管理；

• 传输中数据保护：功能包括 TLS/SSL 层保护、数据丢失防护解决方案和安全数据传输；

• 数据监控：通过操作中心 (SOC) 进行日志记录和监视功能；

• 在云环境中,以数据为中心的保护需要在整个数据生命周期中进行。

阿里云数据上云迁移最佳实践

数据库上云

包含关系数据库及NoSQL数据库上云等场景，以Mysql为例，主要考虑以下几点：

• 根据性能场景需求，选择匹配的产品及实例规格，以最低成本达到业务需求

  比如RDS和PolarDB，RDS主要是主备模式，读写IO在单机上执行，走主机总线，RT相对较低，而PolarDB是云原生的读写分离架构，读写IO会走网络，RT相对较高。从产品架构上分析，对于RT要求比较高的场景，建议使用RDS，其他情况，相同规格PolarDB实例一般比RDS QPS性能要高。

• 未来数据增长

  未来三年内数据增长，如果超过单实例最高规格性能，建议使用PolarDB-X，通过水平切分的方式，将数据分布在多个底层mysql库，通过并行的分布式数据库操作来实现性能的提升。

• 迁移过程数据膨胀

  全量数据迁移过程并发INSERT导致目标实例的表存在碎片，全量迁移完成后目标实例的表空间会比源实例大（迁移完成后可通过optimize table合并碎片，优化存储空间），所以建议选择实例规格时，预留一定的存储空间以防存储打满；

• 识别无主键表

  无主键表不支持增量迁移，需要提前识别，对于无主键表单独做全量迁移。

阿里云数据库上云迁移工具及最佳实践

数据传输（Data Transmission，简称DTS）是阿里云提供的一种支持关系型数据库、NoSQL、OLAP等多种数据源之间数据交互的数据服务。DTS的数据迁移功能支持同构或异构数据源之间的数据迁移，同时提供了库表列三级映射、数据过滤等多种ETL特性，适用于多种数据库迁移上云场景。