云计算 - 以阿里云为例，企业上云策略全览与最佳实践
一、什么是云采用框架 CAF
云采用框架（Cloud Adoption Framework，简称 CAF）为企业上云提供策略和技术的指导原则和最佳实践，帮助企业上好云、用好云、管好云，并成功实现业务目标。
本云采用框架是基于服务大量企业客户的经验总结，将企业云采用分为四个阶段：上云战略、上云准备、应用上云和运营治理，并详细探讨企业应在每个阶段采取的业务和技术策略；同时，还提供了一系列最佳实践、文档和辅助工具，帮助云架构师、云管理团队等干系人能够实现组织协同达成目标。
ITIL（Information Technology Infrastructure Library） 是 IT 服务管理的经典方法论，被企业广泛采用。ITIL 中核心的概念是 IT 服务，IT 服务是用来支持企业业务发展的技术服务，它的全生命周期包含服务战略、服务设计、服务转换、服务运营以及服务的持续改进五个阶段，其中
服务战略阶段：定义服务、明确服务的价值以及服务管理与业务之间的关系。
服务设计阶段：定义服务的目标和要素、模型和风险，定义管理服务的流程。
服务转换阶段：提供发展和改进能力将服务交付到运营阶段。
服务运营阶段：在服务交付和支持中保证效率和效果，为客户提供价值。
云服务是当下最流行的 IT 服务之一，云服务的采用应遵循上述生命周期。我们的云采用框架就是以这样的理论体系为指导，定义了企业引入云服务的四个阶段：
在上云战略阶段，领导层需要思考上云能为业务带来什么价值，并在公司层面确定相应的战略。
在上云准备阶段，IT 团队需要制定云采用的顶层设计，确保组织协同和可管可控。
在应用上云阶段，开始迁移原有的系统上云或者在云上开展新的业务。
在运营治理阶段，企业不断发现和解决运营过程中的问题和风险，提升服务质量。
二、企业上云的主要动机
我们可以根据上云的业务对上云动机进行分类。如果上云的业务是一个在云下已经存在的业务，那么上云主要是把云下的应用迁移到云上，这称为业务迁移上云。如果上云的业务是一个新构建的业务，首次部署运行就在云上，这称为业务创新上云。
业务迁移上云
业务迁移上云是最为常见的一类上云动机，也是云计算技术商业化后最早期的企业普遍采用的上云方式。业务迁移上云的主要目的是：
加速资源的交付效率，提高对业务需求的反应速度。
传统 IDC 采购周期从一个月到几个月不等。如果涉及到出海，对于企业来说 IDC 的规划甚至长达数年。而云上资源的交付效率近乎实时。
降低成本。
云计算将 IT 资产的成本由传统的 Capex 资产折旧模型转变为 Opex 的按量付费模型。这样做一方面减少企业的一次性 IT 投入，另一方面也可以让企业按时按量购买需要的资源，以节省成本。
使用云提供的最新技术。
云厂商通常在产品技术的投入非常大。因此，云厂商提供的云服务通常在行业中比较领先，例如我们常说的云原生服务，如容器、中间件。
提高服务的安全性。
云厂商提供的是规模化在线服务。在安全性方面，云厂商有大量的数据能够帮助客户更好的应对互联网上的攻击。
业务创新上云
随着数字化转型的浪潮，当前许多企业开始业务创新。云上提供了较为丰富的 PaaS 和 SaaS 服务，因此云也是这部分转型的最佳选择。业务创新上云的主要目的是：
云上提供丰富的创新能力，例如 IoT、大数据、业务中台，能够大幅降低企业业务创新的门槛。
需要将业务快速推向新的市场。
三、上云所需的企业组织模型
企业上云和用云的整个生命周期，需要专业团队进行合理的规划、实施以及持续优化云采用方案，推进企业更好的利用上云的优势促进业务发展。企业通常至少有一个云管理团队，或由相关负责人组建一个云卓越中心（Cloud Center of Excellence，简称 CCoE）负责规划和对接上云的整体方案，包括在公司层面确认上云的整体计划、步骤，以及收集业务团队的具体需求。
上云所需的企业组织模型
首先，我们看一下一个典型的企业组织架构。为了便于理解，我们对这个组织结构进行了适当的简化。在这个架构中，不同的团队对公司的整体目标进行拆解，例如业务团队主要贡献公司的营收、流入目标，财务、法务等团队对公司的整体运营风险进行控制，产品技术团队则为业务团队提供技术支撑。
核心职责
企业采用云服务的过程中有以下核心工作项：
上云策略：从公司战略层面确定企业上云的动机和期望的业务结果。在充分论证企业上云的收益和风险后，最重要的是在公司上下充分传达和教育，确保公司高层、业务、研发、运维、财务、人力资源等各个相关团队统一认识，明确上云战略，各团队能够配合做出相应的计划和调整。制定企业上云计划，包括业务范围、上云的计划节奏、各阶段目标以及最终结果。协调各部门准备相应的预算、调配人员和组建必要的团队。
上云准备：准备上云的基础环境，对云服务进行学习和测试，选择小规模的业务进行迁移验证。设计业务上云的整体架构，其中包括迁移方案和基于云技术的创新。规划业务上云的流程，协调业务部门配合实施业务上云。分阶段逐步实施业务迁移上云，并在过程中调整方案，确保业务连续性和稳定性。
应用上云：梳理企业应用系统清单，调研应用上云兼容性等相关特征，筛选需要上云的应用，制定应用的上云策略。
持续治理：充分预见和评估企业安全合规等风险，规划企业 IT 治理的整体方案、策略和基本规则，包括资源结构、身份权限、费用账单、合规审计、网络架构、安全策略以及监控规则等。在企业上云和用云过程中，通过治理规则预防、发现和及时治理风险。
为了适应云采用框架，组织需要进行以下准备：
企业管理层：企业管理层需要明确云在公司的战略地位以及各个团队应该如何使用云。
云卓越中心：该团队可以是虚拟的组织，设计提供云服务的模式和管理体系，并提供相应的技术准备。其中的成员包括
架构师和专业技术人员，负责上云架构设计和业务上云迁移工作；
安全、合规等领域专家，负责设计企业 IT 治理方案、预估风险和制定治理规则；
财务专家，负责制定财务的管理流程，成本分摊原则。
云管理团队：在企业业务全面上云之后，持续优化上云架构，为新业务提供云上环境。建立企业云上运维体系，搭建运维平台，以及通过自动化运维的方式，对云上环境进行持续治理和管理。根据新业务需求，分配所需云资源和所需权限，并对资源进行初始化配置后交付。应用运维团队只需用云，无需关注基础设施搭建。综上，平台运维工作也可细分为架构优化、云平台建设、资产管理、权限管理、云自动化等多种职责。
四、云上管理和治理框架
定义
如果把上云框架的搭建比作建设社区，那么企业的中心 IT 团队就是社区的总设计师。一个好的社区通常具备较为完善的顶层设计，最终才能提供优质服务给社区租户。社区规划首先要考虑的是基础设施的布局和建设，包括道路的规划、门禁的管理、停车场的布局、楼房规格的规划等。其次，社区一般也会提供通用服务，例如垃圾分类、水电维修等，以及制定相应的社区规约来管理租户，例如装修时间规定、噪音规定。作为增值服务，高档社区还会提供统一的不同类型的样板间，比如统一水电、装修等。
在阿里云，我们建议企业在第一个应用上云前，需要有一整套顶层设计和一系列基础框架，为后续的业务上云扫清障碍。否则，可能会导致后续业务上云面临成本、网络、安全、效率等多方面的问题。业界通常把这些基础框架叫做 Landing Zone，我们也遵循这一命名方法。
如上所述，在成熟的运维模型中，通常由企业的中心 IT 团队负责集中管理和管控，然后将云环境交付到业务团队。为了高效地提供安全、稳定的云环境，中心 IT 团队需要搭建一套企业级的管理和治理框架作为云环境的基础设施，为企业上云打好基础。
例如，某跨国企业使用阿里云支撑公司多个业务系统，其中包含公司的互联网业务和 ERP，以及内部的 OA 等系统，这些系统由不同的团队负责。为了更高效地使用云，公司成立新的“云平台”部门负责和云的对接。“云平台”的内部定位是公司负责提供云能力的部门，以此加速 IT 和业务升级。具体而言，“云平台”部门负责云上资源的快速交付、成本控制、质量保证，同时赋能业务部门在安全的前提下进行创新。“云平台”在阿里云提供的 Landing Zone 的基础上，构建了整个云服务体系。
架构
那么，一个完整的 Landing Zone，究竟包括哪些方面？在参考了众多企业客户的实践之后，我们定义了 Landing Zone，其包含如下几个功能模块。
下表简要描述了上述功能模块。
五、企业应用上云规划
随着企业信息系统的持续建设，IT 与业务不断的融合，企业应用类型及模板不断发展，如何从大量企业应用系统中筛选需要上云的应用，确定应用上云的策略及优先级，是上云实施前需要做的事情。所以，建议企业在上云迁移实施前，对企业总体应用进行上云规划。以企业上云战略及规划为指导方向，梳理企业应用系统清单，调研应用上云兼容性等相关特征，制定应用的上云策略，以及应用上云迁移优先级。阿里云上云评估模型如下图所示。
上云兼容相关特征
上云兼容特性主要包含基础设施相关兼容性以及应用架构兼容性特征；
基础设施兼容性特征
硬件依赖性
是否有特殊硬件要求，比如 USB 加密狗等；
性能要求
是否有特殊性能要求，比如运行环境 CPU、内存规格，IO 或网络要求等，云上是否能满足；
操作系统要求
是否有特殊版本操作系统要求，云上是否能提供；
应用架构兼容性特征
集中式/分布式架构
应用是否分布式架构，以及使用的分布式架构框架，是否有对应的 PAAS 产品支持兼容
源代码可控性
源代码是否可操作及维护，是否有能力支持上云迁移或改造；
技术组件上云兼容性
包含数据库、存储、中间件等技术组件，是否有对应兼容的云产品；
其他特征
业务/技术痛点或诉求
是否有业务或技术上的痛点或诉求，比如当前集中式架构迭代速度无法支持业务快速发展，需要做微服务改造；
资源/数据增长需求
当前基础设施环境，是否满足业务预期的资源或数据增长需求，以及数据增长要求对架构提供优化需求，比如数据库容量无法满足业务未来数据增量，在上云同时，需要做水平拆分；
安全合规要求
是否有行业特征的安全合规要求，云的安全合规等级是否满足行业要求；
容灾要求
是否容灾或数据灾备要求，云产品能力是否支持；
上云策略
上云规划阶段，需要确认应用的上云策略，是否平迁或改造上云，根据阿里云的以往项目实践，我们建议的上云策略包含以下几点。
保持现状
保留应用程序在当前的 IT 环境，作为非云基础设施的一部分；
平迁上云
应用比较容易移植到云环境上，使用云产品可替兼容替换技术组件，少量修改应用配置后重新部署到新的云平台。
优化上云
通过使用云上 PaaS 产品及服务，对应用进行局部优化，提升性能或稳定性。
重构上云
应用组件不适配云的架构，或者不符合成本效益，因此需要对应用进行重构，基于新的云平台构建云原生架构的应用。
决策流程
根据业务调研阶段输出的应用系统清单及应用特征数据，每个应用最终对应上云评估策略的中一个类别。其决策流程可以参考下图。
考虑到企业应用系统规模较大，各方面资源无法保障所有应用系统并行上云。所以，我们建议制定应用上云优先级，并明确迁移批次及计划，使得所有资源能够有效被利用，并降低上云风险。
我们建议应用上云优先级的制定，以“速赢”为原则，即优先迁移上云难度低且上云收益高的应用。根据应用的上云难度及上云价值收益，可以将应用上云优先级，划分低中高三个象限，应用上云优化级制定方法如下图所示。
应用上云批次确认后，根据企业上云战略及规划，制定企业应用上云总体实施计划，示例如下图所示。
六、企业应用上云实施流程
阿里云基于业界最佳实践和大量上云项目的经验累积，总结出以下迁云流程，这一过程建立在完成了企业应用上云规划后，以应用为单位进行进一步的迁移计划和实施。
在上云实施阶段，应用调研的目标，是为了解应用的应用架构以及使用的技术组件，以制定云上目标详细方案，包含云上应用架构设计，产品选型及容量评估、迁移方案以及割接方案，所以这一阶段调研的信息比较详细。
应用架构及依赖
应用架构
应用模块及模块间关系，节点配置及数量；应用开发语言及框架。
应用依赖
其他应用间的依赖关系，以及外部依赖，主要用于割接方案参考；
技术组件
数据库
数据库类型，版本，数据量，性能要求等；
中间件
中间件类型，版本，集群规模及容量【可选】，如消息队列、缓存等；
存储
使用存储设备的接口协议，及数据量；
应用性能基线
应用的性能指标要求，用于测试验证阶段性能测试目标参考；
调研工具
如果企业系统非常庞大，应用之间耦合多，各系统的负责部门不同，人工收集的方式难免会有疏漏，难以完整厘清所有应用系统以及系统间的复杂依赖关系。我们建议使用阿里云提供针对企业应用上云场景提供应用发现服务（Application Discovery Service），满足企业在迁云阶段的评估、规划、建设、迁移的需求评估。采用无侵入式采集技术，不影响在线业务的性能前提下从主机和进程两个维度构建架构拓扑，自动分析识别主机和进程信息、资源使用水位以及各应用和组件之间的依赖关系。更多详情，请参见应用发现服务。
平迁上云方案
产品选型策略
针对传统应用平迁上云场景，常见产品对标选型策略如下图所示。
场景示例 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 平台，提供应用开发、部署、监控、运维等全栈式解决方案，支持 SpringCloud、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）业务功能提取为微服务
挑战：对单体应用做拆分时，采取的策略是自上而下的“垂直切分”，要涵盖被拆分的业务的全部逻辑，主要包含业务逻辑及数据库表。为此带来了一些挑战：
领域模型的拆分：跨服务的对象引用、通用类的拆分等
数据库表的拆解分，如：从已有的表中拆出新表
提取入口：关于提取哪些部分进行服务化，一个重要判断点是否能给业务快速带来价值，而价值可以从新业务上线效率，或解决棘手的性能及扩展性等方面来考虑。一般来说，具有下面特点的功能模块可以入手来做改造，提取功能为服务后，同时也需要重构数据库。如：改造数据库的库表结构，提取并创建新服务对应的表及数据。
频繁变化（业务维度）
频繁调用
相对独立
共享的基础数据
计算密集型（利于弹性伸缩，技术维度）
最小化改造：对单体应用进行改造，势必会带来领域模型、库表结构等的变化。例如：我们拆分订单业务，提取出送货子业务。这些变化会直接影响代码，即要求对变化的部分做出代码调整。由于每一处访问变化部分的代码都需要，这会直接修改单体应用的代码，可能带来较大工作量，这是我们不愿意看到的，因为大量工作花费在要被替代的单体应用上。理想的方式是，在拆分出新服务的同时，不修改或尽量减少修改原有单体应用。
保持单体应用的数据库结构基本不变；
拆分出的新服务使用独立的新库表结构；
新服务获取数据后写入新的库表；
使用触发器之类机制将新库表的数据同步到单体应用库表；
在单体应用里，只需修改代码去调用新服务即可；数据读取可依赖原有单体应用。
专项上云方案
数据上云方案
数据上云架构设计
数据在同一业务库中采用多租户隔离机制；为数据服务层建立一套统一的管理规范，所有业务用户账号在完成相关审批流程后对相应的数据字段进行授权安全访问，对数据只有读的权限，不能对原始数据进行直接修改或删除，做到数据不搬家，可用不可见；建立统一的数据资源视图和数据血缘跟踪能力，能够对所有的数据的生命周期进行溯源查询，用以甄别数据变更过程中的真实性和准确性；根据不同业务场景结合流程节点和风险管控要求，对相关数据进行分析、建模、挖掘，提高数据服务支持。
数据上云安全防护
在企业数据迁移上云的过程中,实施数据分层保护功能已成为一个关键优先事项。同时，数据保护控制必须辅之以强大的监控工具和访问管理控制,以构建数据的整体视图，对数据的全生命周期进行监控。重点考虑以下关键数据保护领域。
数据分类：围绕数据识别、清单、标签和分类的功能和流程；
静态数据保护：有关加密/令牌化的解决方案和注意事项,包括密钥管理；
传输中数据保护：功能包括 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 特性，适用于多种数据库迁移上云场景。
存储数据上云
主要指非结构化数据，常见于内容管理类型的应用系统，涉及大量文件对象的存储和管理，传统的解决方案包括：
本地磁盘存储，数据定期备份。但这种方案存储容量和性能的扩展性、存储自身的高可用性等问题。
采用 IP-SAN、NAS 等对数据做集中存储，这种方案成本较高；
在数据库中存储文件。这种方案成本高，对数据库的存储资源消耗和性能影响都比较大。
针对文件对象存储，阿里云提供开放存储服务（OSS），具备高可用、高扩展、高效性、低成本等特点，能有效解决内容管理类型应用的文件对象的存储问题。 应用系统需要基于 OSS 进行相关改造，主要包括：
根据应用系统文件的存储结构在 OSS 中规划 Bucket，以及文件目录结构；
设置 Bucket 访问权限（public-read-write/public-read/private），对于安全级别要求高的应用，可设置文件在 OSS 上以密文形式存储；
对程序代码进行扫描，查找出涉及文件向存储读写的代码，将这些代码改造为以 OSS SDK 接口的实现。
阿里云存储数据上云迁移工具
阿里云在线迁移服务是阿里云提供的存储产品数据通道。使用在线迁移服务，可以将第三方数据轻松迁移至阿里云对象存储 OSS，详情请参见在线迁移服务。
建立上云迁移组织及保障机制
在上云迁移实施前，需要建立迁移组织及保障机制，明确各小组职责及成员，确定保障机制把握项目工作进度和工作质量。
迁移组织架构
根据阿里云以往项目经验，建议组织分为以下小组，如下图所示，各小组职责如下。
项目管理办公室
负责项目进度、风险及问题管理，以及内部宣贯。
实施架构组
负责总组上云方案、割接方案设计，以及项目实施过程中技术风险把控。
应用开发组
负责应用开发、部署及应用迁移实施工作；
运维组
负责云上资源管理、数据组、中间件迁移实施及数据校验工作；
测试组
负责功能测试、联调测试及性能测试工作。
项目实施保障机制
建立项目管控机制，把握工作进度和工作质量，包含以下内容：
内部定期沟通计划
项目周报制度
问题和风险分析计划
制定迁移实施计划
由于上云迁移实施存在风险，所以，在应用上云实施执行前，我们建议制定详细的实施计划。这个计划表里面包含了上云迁移及割接过程的全部任务、时间段、各方人员等。项目实施过程按照这个计划表跟踪执行即可。下图给出一个示例模板，在具体的项目中可以根据项目需求来设计定制。
功能测试及联调测试
在应用上云割接前，需要进行充分的功能测试与联调测试，验证云上环境应用运行情况。功能测试及联调测试依赖企业自己的测试团队及流程工作，不作过多描述，仅在此建议，对应用功能点进行分级，优先测试验证核心功能点，对不同级别功能点测试问题，制定不同紧急程度的问题跟踪。
性能测试
性能测试流程
业务测试模型构建
业务测试模型构建主要是根据搜集到的性能测试需求和生产系统的相关信息完成性能模型的构建工作，并指导性能测试过程以及测试结果的生成。
监控性能指标
监控指标包含业务监控指标、操作系统监控指标、中间件监控指标、数据库监控指标，旨在监控从各个维度描述压测时性能表现。
构建性能测试数据
测试数据主要包含两类：
基础测试数据
基础测试数据一般取自生产环境真实请求日志。基础测试数据非常适合真实业务模型，当然，也可以对基础测试数据进行过滤处理，获取单一业务场景测试数据。
采用参数化测试数据
参数化测试数据主要根据业务请求参数，按测试模型场景构建。参数化测试涉及的范围很多，比如需要准备大量用户名及相应密码参数数据；模拟纳税人纳税申报，需要准备大量的纳税人识别号、纳税人内码或纳税人系统内部识别号等参数数据，这类数据准备要求符合实际运行要求并且保证数据表之间的关联关系。
测试场景
常见性能测试场景，主要包含以下几种：
基准测试
基准测试的目的是检查业务本身是否存在性能缺陷。同时为将来的混合场景的性能测试性能分析提供参考依据。
稳定性测试
稳定性测试主要侧重系统在持续的压力情况下，长期运行时的业务处理能力及系统可能存在的缺陷。
业务突变测试
业务突变测试主要考察当业务进行突变以后，系统是否出现异常情况，资源在突变前后变化情况。
可靠性测试
可靠性测试主要是模拟各种故障（网络中断，服务异常、HA 切换）下，系统是否能正确切换，处理能力是否有明显变化。
测试实施及报告
基于测试工具，构建对应测试场景的脚本，执行后，通过测试结果，并根据观测的性能指标，撰写测试报告；
测试工具
阿里云性能测试 PTS（PerformanceTesting Service）产品是面向所有技术背景人员的云化测试工具。PTS 是具备强大的分布式压测能力的 SaaS 压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。
PTS 目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在 PTS 平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量最佳配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。详情参见什么是性能测试PTS
割接上线前的准备
应用的割接上线是整个应用上云迁移实施的最关键环节，这一环节出问题，可能会造成重大故障。针对割接上线的重要性，我们建议在实施应用割接前，制定详细的割接前检查清单,这个清单的严谨程度也许很大程度上决定了割接成功率。根据我们以往的经验，对割接上线前的准备工作，以下给出几点经验：
割接前需要严格确认是否所有需要预先准备的工具、迁移环境（客户本地数据中心端、网络、云端）等已经就绪。
检查和确认云环境 Landing Zone 已经就绪，并且确认云环境中的规模，安全，控制，网络以及身份验证与设计保持一致。
割接上线时需多方人员参与，软件厂商、集成商、用户方、云厂商等,确认这些相关人员是否已经就绪。支持的方式是现场、远程还是电话。
回滚预案是否就绪。割接过程好像在打一场大的战役，很多的任务或子任务会分配半小时内计划执行结束，整个过程可能会非常紧张。为降低压力，即使因为某个主客观原因导致迁移无法成功进行，如果有补救措施会让整个迁移团队降低很多压力。这个补救措施之一就是回滚预案，也即是失败后回滚到客户的原数据中心恢复业务应用，需要在割接时预留回滚执行的时间。回滚执行后，然后拥有充足的时间排查问题，以备下一个割接窗口期内再次割接。
根据项目实际场景，设计一个检查清单，这个清单包含了迁移割接任务的全部前置条件。下图给出一个检查清单的示例模板，在具体的项目中可以根据项目需求来设计定制。
制定详细的割接实施方案
迁移项目是复杂的，大部分迁移割接的时候都会或多或少的遇到一些无法预料的问题。造成割接失败，可能有主观原因和客观因素。主观原因可能因为迁移调研问题、迁移方案设计缺陷、迁移验证过程不够全面等。客观因素通常是客户 IDC、运营商网络、云数据中心故障等。无论哪种问题导致，都可能会对迁移割接造成失败。根据以往的项目经验，我们建议在割接前制定详细的割接实施方案，以下是关于割接实施方案的一些建议。
数据验证，确认割接时与割接前数据保持一致。通常客户的大部分服务器镜像及数据会在割接前预先在云端复制完成。在割接窗口期开启后需要确保云端复制的数据与客户数据中心下线前保持严格一致。
并非所有问题都会导致迁移失败。遇到问题的时候，首先评估问题的严重程度，如果不是关键业务应用的重要的问题，可以将割接流程继续进行，同时该问题继续解决。与客户协商，该问题是否会对业务有很大影响，如果客户可以接受的话，可以先上线，然后尽快解决该问题。
迁移时间拖延问题处理。如果割接时不够顺利，因为种种主客观原因导致迁移割接时间长于计划时间，可以与客户协调，一起决定是否可以延迟一些时间上线。通常设计割接计划时都会留出一些缓冲时间，如果需要延迟的时间过长是客户无法接受的，那就只能执行回滚预案了。
网络切换问题处理。比如 IP,端口，网络配置,DNS 等问题，在之前的调研和检查中出现遗漏。这种问题在割接时经常会遇到，出现这种问题紧急联系相关负责方尽快解决，但并不一定会影响割接整体进行。
迁移的不仅是服务器或数据。而是整个企业的 IT 应用及环境，客户应用需要的身份管理、安全配置、数据及系统备份、高可用性架构配置，容灾方案等都需要完成。
严格按照迁移设计方案中指定的云服务型号匹配云上资源。拿 VM 举例，通常云上会提供十几个系列，数百种 VM 型号，使用错误的 VM 即使能够将服务启动起来，但会带来性能、功能以及成本的问题。
迁移过程确保安全合规。数据迁移严格使用加密数据传输，加密数据存储。证书、密码、权限按照合规的方式申请和使用，杜绝泄露隐患。避免因安全合规性问题带给客户严重损失。
制定详细的割接及回滚步骤，明确每个步骤执行时间点，前置条件，相关责任人等。以下是割接及回滚步骤的示例模板，在具体的项目中可以根据项目需求来设计定制。
割接实施步骤模板示例：
回滚实施步骤模板示例：
割接后持续观察验证
割接后对迁移的应用云上运行情况持续观察验证，做好业务和数据做好监控，持续观察业务的运行状态，直到确认完全没有问题，割接执行工作才算基本结束。
文章转载自：techlead_krischang
还未添加个人签名 2023-06-19 加入
还未添加个人简介
评论