关于go:云计算-以阿里云为例企业上云策略全览与最佳实践

云采纳框架（Cloud Adoption Framework，简称 CAF）为企业上云提供策略和技术的领导准则和最佳实际，帮忙企业上好云、用好云、管好云，并胜利实现业务指标。本云采纳框架是基于服务大量企业客户的经验总结，将企业云采纳分为四个阶段，并具体探讨企业应在每个阶段采取的业务和技术策略；同时，还提供了一系列最佳实际、文档和辅助工具，帮忙云架构师、云治理团队等干系人可能实现组织协同达成指标。

关注【TechLeadCloud】，分享互联网架构、云服务技术的全维度常识。作者领有 10+ 年互联网服务架构、AI 产品研发教训、团队治理教训，同济本复旦硕，复旦机器人智能实验室成员，阿里云认证的资深架构师，项目管理专业人士，上亿营收 AI 产品研发负责人。

一、什么是云采纳框架 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 即便可能将服务启动起来，但会带来性能、性能以及老本的问题。
• 迁徙过程确保安全合规。数据迁徙严格应用加密数据传输，加密数据存储。证书、明码、权限依照合规的形式申请和应用，杜绝泄露隐患。防止因平安合规性问题带给客户严重损失。
• 制订具体的割接及回滚步骤，明确每个步骤执行工夫点，前置条件，相干责任人等。以下是割接及回滚步骤的示例模板，在具体的我的项目中能够依据我的项目需要来设计定制。

割接施行步骤模板示例：

回滚施行步骤模板示例：

割接后继续察看验证

割接后对迁徙的利用云上运行状况继续察看验证，做好业务和数据做好监控，继续察看业务的运行状态，直到确认齐全没有问题，割接执行工作才算根本完结。

关注【TechLeadCloud】，分享互联网架构、云服务技术的全维度常识。作者领有 10+ 年互联网服务架构、AI 产品研发教训、团队治理教训，同济本复旦硕，复旦机器人智能实验室成员，阿里云认证的资深架构师，项目管理专业人士，上亿营收 AI 产品研发负责人。
如有帮忙，请多关注
TeahLead KrisChang，10+ 年的互联网和人工智能从业教训，10 年 + 技术和业务团队治理教训，同济软件工程本科，复旦工程治理硕士，阿里云认证云服务资深架构师，上亿营收 AI 产品业务负责人。