检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
以确保系统的可用性和性能。 容器化和微服务架构:采用容器化技术(例如Docker)和微服务架构可以实现应用程序的解耦和扩展。这样可以使开发团队更加灵活地部署、更新和维护应用程序,同时提高可伸缩性和弹性。 持续学习和改进:DevOps是一个持续演进的过程,团队应该不断学习和改进工
数据层迁移方案 数据层主要负责业务数据的持久化,为上层业务逻辑的实现提供数据支持,数据层包括两类数据,结构化数据和非结构化数据。结构化数据包含各类数据库,例如MySQL数据库、MongoDB数据库等,非结构化数据包含对象存储、各类文件存储等。 结构化数据迁移方案 结构化数据,主要
写服务或对应接口shutdown,读服务或对应接口保持alive 应用层服务已做读写分离场景,每个服务只进行单独的读操作或写操作,没有同时进行读写的服务 简单 无需改造 应用层先做读写分离改造,然后停止写服务,读不停 应用层修改代码,拆分读写服务 应用层服务没有读写分离的场景 复杂 大 中间件层/数据层直接回收写权限
云相较于传统IDC非常大的一个优势具备丰富的资源和强大的扩展能力;根据业务场景的不同需求,可以将扩展能力分成如下3类: 纵向(垂直)扩展:适用于单体应用、独立应用、有状态应用等场景下,随着业务不断发展和变化,需要快速升级硬件以应对业务变化。如在进行一些促销活动时,对资源的需求往往比正常要高出多倍,这时企业在云上就可以通过可视化界面或者
云上高可用方案 公有云上业务的可用性,由应用层的可用性,架构设计的可用性、云服务的可用性共同决定。业务可用性目标的达成是一项系统工程,公有云模式下,业务的可靠性取决于客户对整体业务架构的可用性设计、运维规范管理(如:备份机制、日常演练、人员操作规范等)。 图1 业务可用性方案 华
企业没有太多人力投入上云工作,建议选择改造量少、人力投入少的停服切换方案。 根据投入产出选择 不停服切换方案通常需要研发额外投入进行大量的应用改造才可以实现,停服切换方案则通常无需大量改造,研发投入工作量小。因此,投入产出也是切换方案选择的决策依据之一,企业可以在业务影响所造成的
他AZ正常提供服务。 应用层-容器集群高可用 Master高可用:容器集群Master 节点3AZ分布, 3节点(1+1+1)。 Ingress网关高可用:ELB实例开启多可用区,ELB Ingress即支持跨可用区高可用。 应用高可用:K8S本身就支持应用高可用,可通过配置To
可用性定义 可用性(Availability)是产品/服务在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力,是产品可靠性和可维护性的综合反映。服务可用性一般会用SLA(Service-Level Agreement)来衡量,各类云服务都有承诺的SLA标准。不同SLA级别对应的停机时间如下表所示:
中间件层迁移方案 当前企业业务中使用比较多的中间件类型为缓存中间件和消息中间件。中间件作为数据存储的临时场所,数据一般不用迁移,但在切换时,为了确保源端和目的端数据的一致性,需要等中间件消息队列中的消息完成消费后再切换。如果中间件缓存数据是持久化的,即作为数据库使用,此场景需要进
推数场景:适用于数据源主动向应用推数的场景,切换点在数据源,需要停止旧数据源推数,配置并启动新数据源向应用推数,将应用的数据源从旧数据源切换到新数据源。 图2 推数场景 抽数场景:适用于应用向数据源抽数的场景,切换点在应用,需要先停止应用向旧数据源抽数,然后配置并启动应用从新数据源抽数,将应用的数据源从旧数据源切换到新数据源。
设计原则 大数据的部署架构设计包括大数据集群、大数据任务调度平台和大数据应用,其中大数据应用的部署架构请参考应用架构设计。 图1 大数据架构设计分类 大数据架构设计同样要考虑架构设计的6要素: 成本 可用性 安全性 可扩展性 可运维性 性能 图2 架构设计6要素 父主题: 大数据架构设计
基础设施。 应用系统 是指为了完成特定任务或解决特定问题而设计的软件系统,以支撑组织内特定的业务流程和业务场景。它通常由一系列相互关联的应用程序、数据库、中间件、配置文件和文档等组成,并运行在IT基础设施之上。应用系统可以是独立的,也可以是更大应用系统的一部分。应用系统有时也称为
服务(Multi-cloud high Availability Service 简称 MAS),它源自华为消费者业务多云应用高可用方案,提供从流量入口、应用层到数据层的端到端的业务故障切换及容灾演练能力,保障故障场景下的业务快速恢复,提升业务连续性。详见华为云MAS高可用服务。
去中心化运营模式 去中心化运营模式是常见运营模式中最简单的一种,如下图所示。在这种运营模式中,所有业务系统都由专门的应用团队独立运营,应用团队不仅负责应用的设计、开发、测试、部署和运维工作,还需要负责业务系统所需IaaS和PaaS资源的部署和运维,同时要确保业务系统的安全性和云资
任务适配和改造、任务调优、部署、测试和验证。 大数据应用迁移:是将基于大数据应用从一个运行环境迁移到另一个运行环境。 大数据迁移遵循如下的流程: 图1 大数据迁移流程 其中大数据应用的迁移请参考应用迁移上云,本章只对大数据应用迁移的特殊注意点进行描述。 大数据迁移流程每个阶段概述如下:
设计并实施身份安全、网络安全、数据安全、应用安全、主机安全和安全运维方案。 指导和审核安全运营工程师的工作,提供技术支持。 跟踪最新的安全技术,制定应对策略。 深入了解云平台的云安全服务和安全配置基线。 熟悉身份安全、网络安全、数据安全、应用安全、主机安全和安全运维等领域。 掌握安全评估工具和渗透测试技术。
义上的“迁移”,而是对现有应用的淘汰。 应用程序不再被业务使用。 应用程序的功能已被其他系统取代。 维护应用程序的成本过高,且其业务价值低。 应用程序的技术过时,难以维护和升级。 Retain 将应用程序保持在当前状态,不进行迁移。这通常是针对短期策略或正在进行更广泛的IT战略规划时的临时措施。
请勿在标签中存储用户身份信息或其他敏感信息。 对标签区分大小写格式,并跨所有资源类型一致地应用该格式。 虽然标签有长度规格上限,但尽量不要每个标签都达到标签规格上限,标签长度能标明含义即可。 提前识别标签的应用场景,比如成本管理、运维和自动化、细粒度权限控制、数据分类、安全运营等,并据此制定标签键值规范,下面会介绍。
全面云化的IT治理挑战 大型企业的组织结构复杂,往往拥有数十上百个业务单元(如子公司、事业部、产品线、部门或项目组等),每个业务单元负责建设1到多个应用系统。这些应用系统的全面云化转型将导致在云上同时存在数百个业务系统和海量云资源,而且包括企业自有员工、外包员工及合作伙伴的员工在内的大量用户需要访
即账号和权限设计、整体网络设计、整体安全设计、资源治理设计、运维监控设计、财务管理设计。 应用部署架构设计:应用部署架构是应用在云上的技术架构,应用部署架构要从接入层、应用层、中间件层和数据层来设计,包括每一层的云服务技术选型,同时还要考虑架构设计的6要素(即:可用性、性能、可扩