一、什么是云采用框架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
原文链接：https://www.cnblogs.com/xfuture/p/18034302
体验地点：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
