上云典型场景

更新时间:

存量应用迁移

下面对Re-host、Replatform、Re-architect三种迁移上云策略的迁移方案进行分析和说明。

Re-host(新托管)迁移方案

对于传统稳态IT应用、ERP系统等,在迁移上云后,不应该改变原有的生产关系。一般这类场景,我们建议通过Re-host方式,将应用重新托管到阿里云。

一般Re-host方式,建议使用阿里云自主研发的迁移平台服务器迁移中心(Server

Migration Center,简称SMC),可以将单台或多台服务器镜像迁移源迁移至阿里云。SMC不依赖底层环境,通过agent方式,最终生成阿里云的ECS镜像,适用于本地物理机、本地虚拟机、其他厂商云环境镜像迁移到阿里云,详情参见SMC最佳实践

image.png

Replatform(新平台)迁移方案

在一些迁移的项目中,安全、稳定优先的情况下,我们通常不会去更改原有应用系统的核心架构,但我们又期望针对一些点去做一些云原生改造,以逐步用云原生能力赋能应用。可以尝试使用Re-platform 的策略来将自建的或存在历史包袱的一些组件、框架替换为云原生组件或者更先进的框架等,即使用PaaSSaaS替代IaaS上自建组件、框架。

通常情况下,Replatform 策略相比Re-host 的迁移成本会更高一些,但是,由于核心架构没有改变,相比Re-Architect 策略的迁移成本还是会低很多。

Re-architect(重构/新架构)方案

Re-architect策略成本高、风险也大,但通常也是收益最高的一种策略。在这种策略中,会去重新思考应用程序的架构和开发和交付方式,并且在这个过程中尽可能多的通过云原生的服务来赋能业务。通常是由强大的业务需求驱动的,在现有架构难以满足业务在新增功能、可扩展性、性能等方面需求的情况下。

Re-architect典型场景包括单体应用的微服务架构改造,应用的容器化和 Serverless 化整体开发和交付架构改造。Re-architect的过程,与下述的云原生新应用几乎一致,但是需要更多的测试以保障和原系统的一致。

云原生新应用

除了已有业务迁移到云上之外,越来越多的客户会选择新业务系统直接在云上构建,充分利用云原生的产品体系来设计满足企业信息建设需要的业务架构。并且由于是新业务上云,没有历史的技术负担,能够更好地进行架构设计来满足业务需求。那么在进行新业务云上架构设计时,需要重点考虑的就是如何合理地利用云"原生"的产品来进行整体设计,满足安全、合规、稳定、高效、低成本以及可持续发展的业务需求。

image

想要做好云原生的架构设计,首先要充分理解云原生的设计理念,不能为了云原生而云原生,本质上还是要通过云原生的架构设计帮助企业获取技术红利、取得业务价值。虽然云上有着丰富的原生产品体系,可以按需随意取用,但是也往往面临非常大的挑战:

  • 云原生架构很好,但是不知从何开始;

  • 云上技术栈技术路线繁多,技术选型存在障碍;

  • 企业对云产品接纳度、熟悉度较低,缺乏最佳实践;从这些问题出发,企业可以遵循一定的流程和方法来进行设计云原生的架构,如下图所示。

    image

新业务上云一定要按照既定的方法做好提前的规划和设计,不一定非要有第三方的服务,企业自身也可以按照架构设计思路做好前置规划,避免初期考虑不全,后续返工或者重新治理,尽量确保在架构设计之初考虑到了安全、稳定、成本、效率等各方面的因素。

云原生的架构设计,首先需要考虑技术栈的确认,一般建议采用云已有的各项产品能力,能够对开源进行很好的适配和加强。云原生产品选型策略可以参考下图:

image

如使用微服务开发,阿里云微服务引擎MSE就是很好的选择、包含了微服务注册配置中心、微服务治理、云原生网关、分布式事务服务四大核心功能,集成了一众开源能力,非常适用于微服务架构开发和管理场景,无需进行众多开源能力和组件的选择和配置。如果采用了容器架构,相比自建Kubernetes或者直接Docker运行在虚拟机上,采用云ACK产品就能够极大地提升效率和降低管理维护成本。在最终进行云原生架构落地时,就需要把微服务化、可观测性、DevOps等方面考虑进去。

image

混合云场景

上云并不是一蹴而就的事情,由于对云的技术体系,产品,理念等都不够熟悉,同时受限于自身应用现状以及合规、高可用等方面的要求,企业往往会选择逐步上云,所以混合云的场景就是大部分企业需要重点考虑的。

对于混合云场景,结合以往最佳实践,建议4点原则:

  1. 先边缘再核心

    对上云系统进行业务分类,根据与核心业务的关联,形成从边缘业务到核心业务的分类。

    在混合云建设初期,往往还是试探性使用的阶段,建议先采用边缘应用先上云的策略,来熟悉云产品的使用,以及迁移的方案、流程,割接注意的事项等,将业务的影响降到最低。

  2. 前端应用先上云

    对上云系统进行技术分类,根据与互联网的依赖关系,确定前端和后端的分类。

    本着最高性价比的原则,弹性要求高,易于部署的前端应用是上云的首选,通过云的弹性伸缩优势,解决企业业务高峰时段的大流量、高并发的问题,既能解决业务高峰期性能不足的痛点,还能降低企业成本

  3. 耦合严重不拆分

    对上云系统进行耦合性判断,对于严重耦合的应用,不建议拆分,要么全部迁移到云上、要么维持不变在云下,避免由于跨云调用产生稳定性风险。

  4. 网络安全是核心

    针对上云系统对网络和安全的需求,对上云系统分类建立标准,通过Landing Zone过程落地这些标准在云上的通用实现,满足要求的系统优先上云,并通过迭代云上网络架构和安全架构,满足更多系统在连接组网和企业安全合规的诉求。

混合云场景下的关键技术架构是网络架构和安全架构,以下对这两部分进行概述:

混合云网络架构

针对混合云组网的复杂场景,阿里云提供了云企业网(Cloud Enterprise Network,简称CEN),能够快速构建混合云和分布式业务系统的全球网络服务,为用户提供优质、高效、稳定的网络传输环境,帮助用户打造一张具有企业级规模和通信能力的云上网络。能够帮助企业充分利用云上丰富的多地域的资源,也可以帮助企业以最快的速度把业务弹性要求高、更新迭代速度快的前端业务优先上云。混合云网络架构如下图所示。

image.png

混合云安全架构

混合云的安全架构设计面临的挑战主要有以下几点:

  • 如何统一管理云上和云下的安全系统

  • 每隔3-5年又要更新换代,是否有节省安全投资的办法

  • 传统安全防护措施对于新型安全威胁检测和防御能力不足

基于这些挑战的应对策略为:

  • 互联网出口应用全部署在阿里云,所有互联网的访问都必须经过阿里云,设置DMZ区。

  • 在阿里云开启DDoS高防、WAF、云安全中心等安全防护能力。

  • 所有的服务器动作统一通过堡垒机,不开放任何外部链接入口。

  • IDC托管机房,只需要配置硬件防火墙用于安全域的隔离。

  • IDC的服务器上部署云安全中心客户端,实现混合云安全的统一管理。

通过统一管理混合云安全策略,减少运维成本和对线下安全硬件的投入。混合云安全架构如下图所示。

image.png

大数据上云

数据是企业数字化转型过程中的核心资产,数据架构选型的参考依据包括数据的使用场景、数据的类型、时效性需求等:

  • 使用场景包括BI的场景,运营的场景,或者是搜索、推广的场景

  • 数据类型如结构化的数据、多媒体数据、文档类数据等

  • 时效性包括实时的数据、T+1的数据或者准实时的数据(允许小时级的延迟)

根据数据需求,企业可能选择离线数仓、实时数仓、数据湖中的一种或者几种的组合。在核心架构确立之后,需要建立采集、存储、计算、应用、归档的数据全生命周期处理流程。在选择数据技术组件时,需要同时考虑技术的先进性、架构的优雅性、成本的经济性。成本包含资源的使用成本、团队的学习成本、系统的改造成本。

数据仓库、数据湖是目前主流的两类核心架构组件,下表是数据湖和数据仓库之间的一些核心差异,供企业在技术选型时参考。

比较维度

数据仓库

数据湖

数据建模

事前建模

Schema-on-Write

事后建模

Schema-on-Read

存储类型

结构化、半结构化

结构化、半结构化、非结构化

性能

专属引擎优化和高性能存储

一般

通用化引擎和低成本存储

数据质量

质量高

质量低

计算场景

Batch、交互式查询、BI和可视化

AI、探查分析、数据挖掘

单位存储成本

数据从生产到使用,形成了标准的生命周期,包含数据采集、存储、计算、分析、归档等阶段。在数据生命周期的每个阶段,根据使用场景的不同,会选择不同的技术栈。阿里云产品对不同阶段的支持如下:

image.png

数据源

image.png

数据采集

image.png

数据存储

image.png

数据计算

image.png

分析、可视化

image.png

数据归档

Databases

Logs

ClickStream

IoT Devices

Photo

Video

DataWorks

SLS-Logtail

DMS-DTS

闪电立方

OSS

MaxCompute

Datahub

Kafka

Tablestore

MaxCompute

EMR

Flink

PAI

Hologres

MaxCompute

ADB

ClickHouse

QuickBI

Datav

OSS低频型

OSS归档型

OSS冷归档

数据质量可以从完整性、准确性、一致性和及时性共四个角度进行评估。CCoE同样需要从这四个角度评估基于云计算的数据项目的数据质量管理,并考察云服务商是否提供了相应的产品和解决方案。

  • 完整性是指数据的记录和信息是否完整,是否存在数据缺失情况。

  • 准确性是指数据中记录的信息和数据是否准确、是否存在异常或者错误的信息。

  • 一致性通常体现在跨度很大的数据仓库中,不同系统中描述的相同实体的数据关联需要依赖一致的特征ID或者机器学习算法。

  • 及时性是数据时效性价值的体现,若等待时间过长,数据失去了及时性的价值,数据分析工作将失去意义。

数据安全带来的国家和社会安全问题、个人隐私问题日益凸显,大数据平台的安全性参照数据全生命周期管理,每个阶段存在的安全事务如下图:

image.png

数据采集

image.png

数据传输

image.png

数据存储

image.png

数据计算

image.png

数据分析

image.png

数据销毁

数据分类分级

采集安全管理

数据源鉴别记录

数据质量

数据传输加密

网络可用性管理

存储媒体安全

逻辑存储安全

备份和恢复

数据脱敏

数据分析安全

数据正当使用

处理环境安全

导入导出安全

数据共享安全

数据发布安全

数据接口安全

数据销毁处置

存储媒体销毁

数据管理工作从组织、资产、流程三要素出发,解决数据的生产和使用问题:

  • 组织包含参与者的角色与关系、权限的管理和鉴权

  • 资产的管理包含数据资产目录的建立和更新,数据建模,数据的全生命周期管理,数据的分层分级和访问授权策略

  • 流程保证数据管理体系中各项事务的正常运转