云采用框架（CloudAdoptionFramework，简称CAF）为企业上云提供策略和技术的指导原则和最佳实践，帮助企业上好云、用好云、管好云，并成功实现业务目标。
本云采用框架是基于服务大量企业客户的经验总结，将企业云采用分为四个阶段：上云战略、上云准备、应用上云和运营治理，并详细探讨企业应在每个阶段采取的业务和技术策略；同时，还提供了一系列最佳实践、文档和辅助工具，帮助云架构师、云管理团队等干系人能够实现组织协同达成目标。
ITIL（InformationTechnologyInfrastructureLibrary）是IT服务管理的经典方法论，被企业广泛采用。ITIL中核心的概念是IT服务，IT服务是用来支持企业业务发展的技术服务，它的全生命周期包含服务战略、服务设计、服务转换、服务运营以及服务的持续改进五个阶段，其中
云服务是当下最流行的IT服务之一，云服务的采用应遵循上述生命周期。我们的云采用框架就是以这样的理论体系为指导，定义了企业引入云服务的四个阶段：
我们可以根据上云的业务对上云动机进行分类。如果上云的业务是一个在云下已经存在的业务，那么上云主要是把云下的应用迁移到云上，这称为业务迁移上云。如果上云的业务是一个新构建的业务，首次部署运行就在云上，这称为业务创新上云。
业务迁移上云
业务迁移上云是最为常见的一类上云动机，也是云计算技术商业化后最早期的企业普遍采用的上云方式。业务迁移上云的主要目的是：
业务创新上云
随着数字化转型的浪潮，当前许多企业开始业务创新。云上提供了较为丰富的PaaS和SaaS服务，因此云也是这部分转型的最佳选择。业务创新上云的主要目的是：
首先，我们看一下一个典型的企业组织架构。为了便于理解，我们对这个组织结构进行了适当的简化。在这个架构中，不同的团队对公司的整体目标进行拆解，例如业务团队主要贡献公司的营收、流入目标，财务、法务等团队对公司的整体运营风险进行控制，产品技术团队则为业务团队提供技术支撑。
企业采用云服务的过程中有以下核心工作项：
为了适应云采用框架，组织需要进行以下准备：
在阿里云，我们建议企业在第一个应用上云前，需要有一整套顶层设计和一系列基础框架，为后续的业务上云扫清障碍。否则，可能会导致后续业务上云面临成本、网络、安全、效率等多方面的问题。业界通常把这些基础框架叫做LandingZone，我们也遵循这一命名方法。
如上所述，在成熟的运维模型中，通常由企业的中心IT团队负责集中管理和管控，然后将云环境交付到业务团队。为了高效地提供安全、稳定的云环境，中心IT团队需要搭建一套企业级的管理和治理框架作为云环境的基础设施，为企业上云打好基础。
例如，某跨国企业使用阿里云支撑公司多个业务系统，其中包含公司的互联网业务和ERP，以及内部的OA等系统，这些系统由不同的团队负责。为了更高效地使用云，公司成立新的“云平台”部门负责和云的对接。“云平台”的内部定位是公司负责提供云能力的部门，以此加速IT和业务升级。具体而言，“云平台”部门负责云上资源的快速交付、成本控制、质量保证，同时赋能业务部门在安全的前提下进行创新。“云平台”在阿里云提供的LandingZone的基础上，构建了整个云服务体系。
那么，一个完整的LandingZone，究竟包括哪些方面？在参考了众多企业客户的实践之后，我们定义了LandingZone，其包含如下几个功能模块。
下表简要描述了上述功能模块。
上云规划阶段，需要确认应用的上云策略，是否平迁或改造上云，根据阿里云的以往项目实践，我们建议的上云策略包含以下几点。
保持现状
保留应用程序在当前的IT环境，作为非云基础设施的一部分；
平迁上云
应用比较容易移植到云环境上，使用云产品可替兼容替换技术组件，少量修改应用配置后重新部署到新的云平台。
优化上云
通过使用云上PaaS产品及服务，对应用进行局部优化，提升性能或稳定性。
重构上云
应用组件不适配云的架构，或者不符合成本效益，因此需要对应用进行重构，基于新的云平台构建云原生架构的应用。
根据业务调研阶段输出的应用系统清单及应用特征数据，每个应用最终对应上云评估策略的中一个类别。其决策流程可以参考下图。
考虑到企业应用系统规模较大，各方面资源无法保障所有应用系统并行上云。所以，我们建议制定应用上云优先级，并明确迁移批次及计划，使得所有资源能够有效被利用，并降低上云风险。
我们建议应用上云优先级的制定，以“速赢”为原则，即优先迁移上云难度低且上云收益高的应用。根据应用的上云难度及上云价值收益，可以将应用上云优先级，划分低中高三个象限，应用上云优化级制定方法如下图所示。
应用上云批次确认后，根据企业上云战略及规划，制定企业应用上云总体实施计划，示例如下图所示。
在上云实施阶段，应用调研的目标，是为了解应用的应用架构以及使用的技术组件，以制定云上目标详细方案，包含云上应用架构设计，产品选型及容量评估、迁移方案以及割接方案，所以这一阶段调研的信息比较详细。
应用架构及依赖
技术组件
应用性能基线
调研工具
云上重部署应用
针对平迁方式的应用上云场景，对于已有成熟CI/CD工具及流程的企业，我们建议优先使用现有CI/CD工具，在云上重新部署应用。
镜像迁移
对于微服务应用上云，可以使用阿里云企业级分布式应用服务EDAS（EnterpriseDistributedApplicationService），它是一个应用托管和微服务管理的PaaS平台，提供应用开发、部署、监控、运维等全栈式解决方案，支持SpringCloud、Dubbo等微服务运行环境。
对于SpringCloudEdgware及以上版本和Dubbo2.5.3及以上版本的微服务应用，无需修改任何一行代码即可迁移至EDAS。
针对SpringCloud和Dubbo微服务框架应用迁移上EDAS，有两种方案，切流迁移、双注册和双订阅迁移。这两种方案都可以保证您的应用正常运行且不中断地完成迁移。
切流迁移
使用Dubbo将原有的服务注册中心切换到微服务引擎（MicroServiceEngine，简称MSE），在云上部署一套新的应用，最后通过SLB和域名配置来进行切流。
双注册和双订阅迁移
以Kubernetes为代表的容器技术正成为云计算新界面。容器提供了应用分发和交付标准，将应用与底层运行环境进行解耦。Kubernetes作为资源调度和编排的标准，屏蔽底层架构差异性，帮助应用平滑运行在不同基础设施上。
应用容器化规范化改造
容器化的应用必须要规范化，我们不希望所完成的容器镜像只能在生产环境中运行，也不希望该容器有着外部依赖，我们希望应用在容器化之前，最少满足这三项要求：
所以，对应用进行容器化前，必须对应用进行检查并实施类似的改造，也就是进行应用规范化，规范化的过程根据已有应用的实际情况有较大的不同，一般来说，越是现代的、面向互联网的应用越容易容器化。对容器化应用的规范化改造有以下内容：
容器化上云流程
传统应用容器化大致分为五个阶段：
云原生应用架构特点
云原生应用架构建议
对于复杂应用系统来说，单体应用架构代码复杂度高、可扩展性差、业务开发及部署周期慢，不能满足现业务发展需要。对于业务复杂的单体应用系统上云需求，我们建议以微服务化重构改造上云。
核心问题
改造原则
改造策略
（1）新业务构建为服务
将新的业务或功能以服务的形式进行构建，这不仅会阻止单体扩大和继续发展，快速开发出新业务功能，更体现出微服务架构的价值。常见的办法是对新业务进行领域建模，得到领域模型、服务接口等必要元素。但同时会带来问题，即新旧系统结合，即微服务与单体应用怎么协作。
在微服务和单体应用之间构建一个双向代理层，通过代理层完成新旧系统的对接集成，避免相互干扰，保持彼此松耦合状态。代理层还可以对单体式应用进行服务化封装，让其像微服务一样以REST的方式对外服务。代理层支持双向通讯，重点解决新旧系统对接集成、协议适配和模型转换等问题，按照此功能定位我们可以将代理层划分成三个模块：
单体与微服务之间的数据交互，使用API是较为直接的方式。但当一方数据变化后，API方式无法主动进行通知。因此，另一个方式是基于领域事件的数据同步。比如：单体应用发布领域事件，微服务进行订阅。当单体数据产生变化时，可以通过领域事件的方式通知微服务，微服务获取事件，更新本地数据，供本地业务查询使用。
（2）业务功能提取为微服务
在企业数据迁移上云的过程中,实施数据分层保护功能已成为一个关键优先事项。同时，数据保护控制必须辅之以强大的监控工具和访问管理控制,以构建数据的整体视图，对数据的全生命周期进行监控。重点考虑以下关键数据保护领域。
数据库上云
包含关系数据库及NoSQL数据库上云等场景，以Mysql为例，主要考虑以下几点：
阿里云数据库上云迁移工具及最佳实践
数据传输（DataTransmission，简称DTS）是阿里云提供的一种支持关系型数据库、NoSQL、OLAP等多种数据源之间数据交互的数据服务。DTS的数据迁移功能支持同构或异构数据源之间的数据迁移，同时提供了库表列三级映射、数据过滤等多种ETL特性，适用于多种数据库迁移上云场景。
存储数据上云
主要指非结构化数据，常见于内容管理类型的应用系统，涉及大量文件对象的存储和管理，传统的解决方案包括：
阿里云存储数据上云迁移工具
建立上云迁移组织及保障机制
在上云迁移实施前，需要建立迁移组织及保障机制，明确各小组职责及成员，确定保障机制把握项目工作进度和工作质量。
迁移组织架构
项目实施保障机制
建立项目管控机制，把握工作进度和工作质量，包含以下内容：
制定迁移实施计划
功能测试及联调测试
在应用上云割接前，需要进行充分的功能测试与联调测试，验证云上环境应用运行情况。功能测试及联调测试依赖企业自己的测试团队及流程工作，不作过多描述，仅在此建议，对应用功能点进行分级，优先测试验证核心功能点，对不同级别功能点测试问题，制定不同紧急程度的问题跟踪。
业务测试模型构建
监控性能指标
监控指标包含业务监控指标、操作系统监控指标、中间件监控指标、数据库监控指标，旨在监控从各个维度描述压测时性能表现。
构建性能测试数据
测试数据主要包含两类：
测试场景
常见性能测试场景，主要包含以下几种：
测试实施及报告
基于测试工具，构建对应测试场景的脚本，执行后，通过测试结果，并根据观测的性能指标，撰写测试报告；
阿里云性能测试PTS（PerformanceTestingService）产品是面向所有技术背景人员的云化测试工具。PTS是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。
割接上线前的准备
应用的割接上线是整个应用上云迁移实施的最关键环节，这一环节出问题，可能会造成重大故障。针对割接上线的重要性，我们建议在实施应用割接前，制定详细的割接前检查清单,这个清单的严谨程度也许很大程度上决定了割接成功率。根据我们以往的经验，对割接上线前的准备工作，以下给出几点经验：
制定详细的割接实施方案
迁移项目是复杂的，大部分迁移割接的时候都会或多或少的遇到一些无法预料的问题。造成割接失败，可能有主观原因和客观因素。主观原因可能因为迁移调研问题、迁移方案设计缺陷、迁移验证过程不够全面等。客观因素通常是客户IDC、运营商网络、云数据中心故障等。无论哪种问题导致，都可能会对迁移割接造成失败。根据以往的项目经验，我们建议在割接前制定详细的割接实施方案，以下是关于割接实施方案的一些建议。
割接实施步骤模板示例：
回滚实施步骤模板示例：
割接后持续观察验证
割接后对迁移的应用云上运行情况持续观察验证，做好业务和数据做好监控，持续观察业务的运行状态，直到确认完全没有问题，割接执行工作才算基本结束。