精华内容
下载资源
问答
  • 2022-04-25 14:39:26

    在这里插入图片描述

    🔎这里是【阿里云·云原生架构·白皮书】,关注我学习云原生不迷路
    👍如果对你有帮助,给博主一个免费的点赞以示鼓励
    欢迎各位🔎点赞👍评论收藏⭐️

    👀专栏介绍

    【阿里云·云原生架构·白皮书】 主要更新一些在学习云原生架构时的一些总结,以及对白皮书内容的解读。

    👀本期介绍

    主要介绍云原生架构原则

    云原生架构原则

    云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。

    服务化原则

    当代码规模超出小团队的合作范围时,就有必要进行服务化拆分了,包括拆分为微服务架构、小服务( Mini Service)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性。同时服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度。

    分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略,所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输,从而帮助业务模块进行基于服务流量的策略控制和治理,不管这些服务是基于什么语言开发的。

    弹性原则

    大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,从提出采购申请,到供应商洽谈、机器部署上电、软件部署、性能压测,往往需要好几个月甚至一年的周期;而这期间如果业务发生变化了,重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩,无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间,让企业不用操心额外软硬件资源的成本支出(闲置成本),降低了企业的IT成本,更关键的是当业务规模面临海量突发性扩张的时候,不再因为平时软硬件资源储备不足而“说不”,保障了企业收益。

    可观测原则

    今天大部分企业的软件规模都在不断增长,原来单机可以对应用做完所有调试,但在分布式环境下需要对多个主机上的信息做关联,才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等,这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM等系统提供的能力不同,前者是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等,这样的能力可以使运维、开发和业务人员实时掌握软件运行情况,并结合多个维度的数据指标,获得前所未有的关联分析能力,不断对业务健康度和用户体验进行数字化衡量和持续优化。

    韧性原则

    当业务上线后,最不能接受的就是业务不可用,让用户无法正常使用软件,影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力,这些异常通常包括硬件故障、硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件 bug、黑客攻击等对业务不可用带来致命影响的因素。

    韧性从多个维度诠释了软件持续提供业务服务的能力,核心目标是提升软件的MTBF ( Mean TimeBetween Failure,平均无故障时间)。从架构设计上,韧性包括服务异步化能力、重试/限流/降级/熔断Ⅰ反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等。

    所有过程自动化原则

    技术往往是把“双刃剑”,容器、微服务、DevOps、大量第三方组件的使用,在降低分布式复杂性和提升迭代速度的同时,因为整体增大了软件技术栈的复杂度和组件规模,所以不可避免地带来了软件交付的复杂性,如果这里控制不当,应用就无法体会到云原生技术的优势。通过 laC ( lnfrastructure asCode ) . GitOps、OAM (Open Application Model ) . Kubernetes operator和大量自动化交付工具在CIICD流水线中的实践,一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程,让自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化。

    零信任原则

    零信任安全针对传统边界安全架构思想进行了重新评估和审视,并对安全架构思路给出了新建议。其核心思想是,默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础,诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆,引导安全体系架构从“网络中心化”走向“身份中心化”,其本质诉求是以身份为中心进行访问控制。

    零信任第一个核心问题就是ldentity,赋予不同的Entity 不同的 Identity,解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下,ldentity 及其相关策略不仅是安全的基础,更是众多(资源,服务,环境)隔离机制的基础;在员工访问企业内部应用的场景下,ldentity 及其相关策略提供了灵活的机制来提供随时随地的接入服务。

    架构持续演进原则

    今天技术和业务的演进速度非常快,很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用,相反往往还需要对架构进行一定范围内的重构,因此云原生架构本身也应该和必须是一个具备持续演进能力的架构,而不是一个封闭式架构。除了增量迭代、目标选取等因素外,还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制,特别是在业务高速迭代情况下的架构、业务、实现平衡

    关系。云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度),但对于存量应用向云原生架构迁移,则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险,以及技术上通过微服务Ⅰ应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。

    唯一不变的是变化

    在动物王国,生存有利于那些适应环境的个体。这不是一个从“坏”到“最好”或从“原始”到“进化”的线性过程,而是一切都在不断变化。随着环境的变化,压力被施加到物种的进化和适应上。类似地,云原生架构不会取代传统架构,但它们可以更好地适应非常不同的云环境。云越来越成为我们大多数人工作的环境,许多物种可以证明,不能进化和适应不是一个长期的选择。

    上面描述的原则并不是创建云原生架构的神奇公式,但希望能为如何最大限度地利用云提供强有力的指导。作为一个额外的好处,移动和调整云架构为您提供了以其他方式改进和调整它们的机会,并使它们能够更好地适应下一个环境变化。改变可能很难,但正如数十亿年来进化所显示的那样,你不一定要成为最好的生存者,你只需要能够适应。
    在这里插入图片描述

    更多相关内容
  • AWS共有云架构介绍.pdf

    2020-03-16 12:13:51
    文档对AWS公有云架构进行了介绍,包含数据中心模块,region,可用域,以及全球数据中心的分布情况,供参考
  • 1与 SaaS不同的这种 计算形式把开发环境或者运行平台也作为一种服务 给用户提供 A 软件即服务 B基于平台服务 C基于 WEB 服务 D基于管理服务 2云计算是对技术的发展与运用 A 并行计算 B网格计算 C分布式计算 D三个...
  • 腾讯云云从、云架构复习资料,包括云从、云架构的知识点总结、试题、课件等。
  • 原生架构概述

    2021-02-24 08:05:11
    在讲原生之前,我们先了解一下CNCF,即原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。目前CNCF所托管的应用已达14个,下图为其公布的...
  • 中国移动5G联创中心创新研究报告-5GXR云网架构与解决方案,5G XR融合了大带宽、低时延的5G和云计算技术,使终端得到“解放”,将数据计算和存储放在云端,包括放在边缘。5G XR是一项复杂的系统工程,目前还...
  • 【阿里·原生架构·白皮书】 对白皮书的一些总结和解读。

    在这里插入图片描述

    🔎这里是【阿里云·云原生架构·白皮书】,关注我学习云原生不迷路
    👍如果对你有帮助,给博主一个免费的点赞以示鼓励
    欢迎各位🔎点赞👍评论收藏⭐️

    👀专栏介绍

    【阿里云·云原生架构·白皮书】 主要更新一些在学习云原生架构时的一些总结,以及对白皮书内容的解读。

    👀本期介绍

    主要介绍云原生架构定义

    👀云原生架构定义

    从技术的角度,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。

    云原生架构在这两年逐渐成为应用部署的主流方式。概括来讲云原生是在云计算时代一种构建和运行应用程序的方法,充分利用和发挥云平台的弹性自动化优势,在云上以最佳方式运行。
    在这里插入图片描述
    在这里插入图片描述
    云原生架构与传统架构的对比:

    上图展示了在代码中通常包括三部分:业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码;“三方软件”是业务代码中依赖的所有三方库,包括业务库和基础库;“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

    三部分中只有业务代码是核心,是对业务真正带来价值的,另外两个部分都只算附属物,但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强,使得今天的软件构建变得越来越复杂,对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步,从业务代码中剥离了大量非功能性特性(不会是所有,比如易用性还不能剥离)到laaS和PaaS中,从而减少业务代码开发人员的技术关注范围,通过云厂商的专业性提升应用的非功能性能力。

    此外,具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力,进一步加快软件开发:

    🪂代码结构发生巨大变化

    云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。今天大部分的编程语言中,都有文件、网络、线程等元素,这些元素为充分利用单机资源带来好处的同时,也提升了分布式编程的复杂性;因此大量框架、产品涌现,来解决分布式环境中的网络调用问题、高可用问题、CPU争用问题、分布式存储问题……

    在云的环境中,比如“如何获取存储”变成了若干服务,包括对象存储服务、块存储服务和没有随机访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面,还在于云产品在这些OpenAPl或者开源SDK背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理了,应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题,也不用处理当业务峰值到来时如何对存储节点进行扩容的问题,而应用的运维人员不用在发现.zero day安全问题时紧急对三方存储软件进行升级……

    云把三方软硬件的能力升级成了服务,开发人员的开发复杂度和运维人员的运维工作量都得到极大降低。显然,如果这样的云服务用得越多,那么开发和运维人员的负担就越少,企业在非核心业务实现上从必须的负担变成了可控支出。在一些开发能力强的公司中,对这些三方软硬件能力的处理往往是交给应用框架(或者说公司内自己的中间件)来做的;在云的时代云厂商提供了更具 SLA的服务,使得所有软件公司都可以由此获益。

    这些使得业务代码的开发人员技能栈中,不再需要掌握文件及其分布式处理技术,不再需要掌握各种复杂的网络技术……简化让业务开发变得更敏捷、更快速!

    🪂非功能性特性的大量委托

    任何应用都提供两类特性,功能性特性和非功能性特性。功能性特性是真正为业务带来价值的代码,比如如何建立客户资料、如何处理订单、如何支付等等;即使是一些通用的业务功能特性,比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值,但通常又是必不可少的特性,比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等等。

    不能说云计算解决了所有非功能性问题,但确实大量非功能性特性,特别是分布式环境下复杂非功能性问题,被云产品处理掉了。以大家最头疼的高可用为例,云产品在多个层面为应用提供了解决方案:

    • 虚机: 当虚机检测到底层硬件异常时,自动帮助应用做热迁移,迁移后的应用不需重新启动而仍然具备对外服务的能力,应用对整个迁移过程都不会有任何感知;
    • 容器: 有时应用所在的物理机是正常的,只是应用自身的问题(比如 bug、资源耗尽等)而无法正常对外提供服务。容器通过监控检查探测到进程状态异常,从而实施异常节点的下线、新节点上线和生产流量的切换等操作,整个过程自动完成而无需运维人员干预;
    • 云服务: 如果应用把“有状态”部分都交给了云服务(如缓存、数据库、对象存储等),加上全局对象的持有小型化或具备从磁盘快速重建能力,由于云服务本身是具备极强的高可用能力,那么应用本身会变成更薄的“无状态”应用,因为高可用故障带来的业务中断会降至分钟级;如果应用是N-M的对等架构架构模式,那么结合Load
      Balancer产品可获得几乎无损的高可用能力!

    🪂高度自动化的软件交付

    软件一旦开发完成,需要在公司内外部各类环境中部署和交付,以将软件价值交给最终客户。软件交付的困难在于开发环境到生产环境的差异(公司环境到客户环境之间的差异)以及软件交付和运维人员的技能差异,填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包,容器及相关技术则帮助屏蔽不同环境之间的差异,进而基于容器做标准化的软件交付。

    对自动化交付而言,还需要一种能够描述不同环境的工具,让软件能够“理解”目标环境、交付内容、配置清单并通过代码去识别目标环境的差异,根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。

    基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例,应用微服务化以后,往往被部署到成千上万个节点上,如果系统不具备高度的自动化能力,任何一次新业务的上线,都会带来极大的工作量挑战,严重时还会导致业务变更超过上线窗口而不可用。

    👀总结

    🪂云原生架构的特点

    容器化封装。 容器化封装是指以容器为基础,应用程序封装在容器之中,在容器里运行,实现资源的相对隔离与容器镜像的重复使用。
    面向微服务。 面向微服务是指把一个大的功能应用拆分成一个个功能单一、相对独立、相互解耦的微应用,微应用之间通过接口进行通讯。
    动态管理。 动态管理指通过一个统一的编排工具,比如K8S,来动态的管理和调度这些微服务。

    🪂云原生架构的优势

    快速。 天下武功,无坚不摧,唯快不破!云原生架构使用敏捷开发和DevOps,不但可以让企业快速的开发产品,自动化部署产品,同时还能持续的更新产品,让产品跟得上需求,甚至是引导需求,让企业立于不败之地。
    弹性扩展。 云原生架构天生具有云计算的特点。它的资源是可以按照实际情况进行伸缩,这样不但提高资源的利用率,也大大降低了企业成本。
    安全与强壮。 云原生架构依托于容器编排工具(K8S)与微服务的组合,应用就拥有了自动恢复能力、容错能力、故障隔离能力,让应用时刻处于可用的状态。
    屏蔽底层差异。 因为使用了容器化技术,应用运行于容器之中,应用就不需要考虑底层硬件的差异,只要是能运行容器镜像的硬件都可以运行程序,大大简化了开发工作量。同时对运维人员也非常友好,不需要再为环境问题而苦恼。
    在这里插入图片描述

    展开全文
  • 2020阿里产品图标素材Visio模具资源,包含官网已停止支持的Visio模具vssx文件+PPT模板素材(官网可以下载到)。导入Visio即可绘制软件架构设计图、网络拓扑图、等,适用于公有、私有原生、微服务、容器、...
  • 边缘云架构体系

    2021-05-31 14:37:14
    本文档为OpenNebula提供了一个强大的分布式边缘云架构,它由边缘集群组成,可以在任何裸金属资源上运行任何工作负载,包括虚拟机和应用程序容器,也可以在任何本地和云提供商上的任何地方运行虚拟化资

    译文:

    Version 2.2 – May 2021

    摘要

    为了支持数字化转型计划,IT部门需要正确地融合本地、公共和边缘云环境,以支持各种现有和新兴用例,同时避免供应商锁定和实现成本优化。他们还需要在共享环境中将容器与Virtual Machine工作负载结合起来,以便从成熟的虚拟化技术和安全的容器编排中获得最大的好处。本文档为OpenNebula提供了一个强大的分布式边缘云架构,它由边缘集群组成,可以在任何裸金属资源上运行任何工作负载,包括虚拟机和应用程序容器,也可以在任何本地和云提供商上的任何地方运行虚拟化资源。我们的边缘云架构通过将公共和私有云操作与工作负载可移植性以及IT基础设施和应用程序的统一管理相结合,实现了真正的混合和多云计算。
    我们将这个体系结构定义得比传统的云计算体系结构简单得多,传统的云计算体系结构通常由用于存储和网络的复杂、专有的通用软件系统组成。该体系结构是根据过去十年中数百名用户和客户参与的集体信息和经验创建的。它基于Linux操作系统中已经存在的存储和网络技术,以及现有云和边缘提供商提供的现代存储硬件,从而大大简化了设计。我们的边缘云架构通过非常简单的设计实现了企业级的性能、可用性和可伸缩性云特性,避免了供应商锁定,降低了复杂性、资源消耗和运营成本。

    1、什么是OpenNebula?
    OpenNebula是一个功能强大但易于使用的开源解决方案,用于构建和管理企业云。它将虚拟化和容器技术与多租户、自动供应和弹性相结合,以提供随需应变的应用程序和服务。OpenNebula提供了一个单一、功能丰富、灵活的平台,对IT基础设施和应用程序进行统一管理,避免了厂商锁定,降低了复杂性、资源消耗和运营成本。OpenNebula管理:

    任何应用程序:将容器与虚拟机工作负载组合在一个公共共享环境中,以提供两方面的最佳服务:成熟的虚拟化技术和应用程序容器的编排。
    任何基础设施:通过结合边缘云、公共云、托管云和私有云运营,释放真正混合和多云平台的力量。
    任何虚拟化:集成多种类型的虚拟化技术,以满足您的工作负载需求,从完全虚拟化环境到系统容器和无服务器部署。

    OpenNebula提供了必要的工具来运行来自Kubernetes和Docker Hub的容器化应用程序,同时确保您的DevOps实践符合企业需求。
    它帮助组织轻松地采用多云计算、混合计算和边缘计算,允许他们利用第三方公共云和AWS和Equinix Metal等裸金属提供商提供的基础设施资源,按需发展企业云。OpenNebula支持多种虚拟化技术,包括用于完全虚拟化云的VMware和KVM虚拟机,用于容器云的LXC系统容器,以及用于无服务器部署的爆竹microVMs。

    本白皮书描述了OpeNebula的边缘云架构,它由边缘集群组成,可以在任何裸金属资源或虚拟化资源上运行任何工作负载(包括虚拟机和应用程序容器),也可以在任何地方或云/边缘提供商上运行。
    如果您想了解更多关于边缘计算的创新方法,请参阅我们的白皮书《如何使用OpenNebula.1加速边缘云计算》如果您对在VMware vCenter之上设计和部署OpenNebula云感兴趣,请参考我们的VMware云参考架构。请参考我们的开放云参考架构。

    OpenNebula的开发遵循了一种由系统管理员、DevOps和企业用户的实际需求驱动的自底向上的方法。OpenNebula是一个开源产品,拥有健康和活跃的社区,并通过OpenNebula系统的OpenNebula订阅获得商业支持。发布版本是定期生成的,并作为一个带有平滑迁移路径的单个包交付。更多关于运行OpenNebula云的好处的信息可以在关键特性页面上找到。

    2、分布式边缘云的设计原则
    IT部门和运营团队的压力正以很高的速度增长。期望他们:

    ● 创新,使新的应用程序和服务更快地进入市场。
    ● 要灵活地满足开发人员对新开发工具和框架(如容器或基础设施代码(IaC))日益增长的需求,同时继续向应用程序管理员提供基础设施,并确保企业对DevOps实践的需求。
    ● 适应新的现实,混合云和多云正在快速增长,边缘计算是下一个IT转型。

    从与数百名用户和客户合作的经验来看,我们已经定义了一个边缘云架构,它构建了一个分布式云平台来运行任何工作负载(从虚拟化到容器化)——跨越可以在任何地方运行的多个集群(可以在任何地方运行)——以及任何资源(从裸金属到虚拟)——具有无与伦比的可用性、性能和简单性。

    该体系结构定义了一个完整的端到端解决方案,基于Linux操作系统中已经存在的经过验证的开源存储和网络技术,以避免厂商锁定;最小化IT复杂性、资源消耗和运营成本;最大化性能、可用性和可靠性;并简化其部署和管理的自动化。
    ● 该架构实现了一个分布式的方法,通过一个云前端控制一个或几个相互连接的边缘集群,可以运行在多个地理分布的数据中心位置,以及云和边缘资源提供商。
    ● 可以动态添加和删除集群,以满足需求高峰,或实现容错策略或延迟需求。
    ● Edge集群基于一个通用的参考架构,该架构被设计为可以部署在任何资源上,从裸金属到虚拟,从而实现工作负载的可移植性。
    ● Edge Cluster的内部设计遵循一种超融合的方法,在每个环境中使用最优的基础设施配置,以确保隔离和性能,轻松地扩展和扩展节点,以匹配计算和存储需求,并迁移工作负载。
    ● 边缘架构实现了真正的混合和多云计算,并利用云、边缘和接入网络云提供商不断增长的生态系统。
    ● Edge集群能够在没有网络连接的情况下自主运行,允许在本地数据中心运行的应用程序在没有任何管理服务的情况下继续运行。
    ● 系统支持现代应用程序,在单一平台上结合应用程序容器和虚拟机,并与现有的虚拟机和容器映像集枢纽和市场集成。虽然基于容器、微服务和功能(无服务器)的新工作负载通常应该是无状态和短暂的,但几乎所有业务应用程序都需要某种形式的数据持久性。这就是边缘云架构为非持久和持久vm以及容器化应用程序提供支持的原因。

    最后,它产生了单一的供应商体验,因为OpenNebula系统完全支持并可选地管理完整的云堆栈。这意味着简化了采购、咨询和支持的体验。您可以加速和简化单一供应商的路线图开发、迁移和升级路径。

    3、高层参考体系结构
    现代云环境已经演变成高度复杂的后端,这限制了它们的可靠性并阻碍了它们的可操作性。它们是由专有的、昂贵的用于存储和网络的通用软件系统组成的,这些系统不必要地复杂,因为它们被设计为一次性解决太多问题。OpenNebula Edge云架构背离了这一趋势,它使用了轻量级系统和软件组件,硬件要求适中,易于修复和操作,同时还提供了最大的应用程序性能,通过实现专门用于管理分布式多站点环境中的虚拟化应用程序的创新设计。

    OpenNebula的边缘云架构是围绕边缘簇的概念而设计的。边缘集群是一组超融合的管理对象功能集,包括存储、网络和主机资源。一个边缘集群提供了运行虚拟化或容器化应用程序所需的所有资源。OpenNebula的管理服务,包括调度、监控和生命周期管理,运行在云中,前端和协调边缘集群。前端还提供对管理工具、用户界面和API的访问。虽然根据集群的数量、大小和API负载的不同,需求可能会有所不同,但前端节点只需要8gb的主存和4个核。体系结构的基本构建块,包括边缘集群,如图1所示。
    图1 边缘云架构的主要组件
    图1: 边缘云架构的主要组件

    边缘集群建立在虚拟化主机和互联网络上。虚拟化主机负责通过适当的虚拟化形式为应用程序提供执行资源(例如CPU、内存或网络访问),例如虚拟机(KVM)、系统容器(LXC)或微型虚拟机(鞭炮/KVM)。实际的虚拟化技术取决于集群主机的配置方式(参见第4节)和工作负载的概要文件。此外,主机为集群提供运行应用程序所需的存储空间。

    集群主机的配置在安装的软件组件、OpenNebula管理用户和可访问存储方面是相同的。前端节点需要连接到集群主机,以接收状态和监控更新,并发起管理操作。集群节点通过一个或多个私有网络相互连接,这些网络通常用于存储传输以及跨虚拟化主机的应用程序通信。最后,需要访问公共链接以提供具有internet连接的应用程序。

    Edge Cloud Architecture能够为中型集群提供轻量级且易于使用的存储平台,这些集群由数十个节点组成,可以在本地和云上运行,也可以在物理和虚拟化资源上运行。总的来说,OpenNebula的边缘云架构能够管理数百个这样的集群,因为它们在网络和存储方面自主运行,并处理数千个虚拟化主机和数万个虚拟化应用程序。

    4、边缘集群部署模型
    OpenNebula Edge云架构的主要优势是能够在任何地方部署集群。这在字面上提供了应用程序移动性和真正的多云计算。集群可以部署在本地基础设施、公共裸金属提供商和虚拟化云环境中,以启用强大的混合云和多云计算。基础设施团队可以灵活地选择他们喜欢的硬件平台和云提供商,并提供出色的OpenNebula体验。

    特别是集群可以以三种不同的形式提供:

    ● On-premises假定资源具有完整的管理能力,并且在网络方面没有任何限制。通常,这种类型的供应使用内部数据中心资源。
    ● 金属远程对IP地址和资源的连通性提出了一些限制。金属供应通常需要与云/边缘提供商API交互,并使用裸金属实例。
    ● 虚拟远程限制了集群主机的能力以及网络连接。虚拟远程集群部署通常基于来自云或边缘提供者的virtual Machine实例。

    请注意,一些集群部署或一些云提供商可能会对集群中可用的功能施加一些限制(例如,支持的管理程序或主机连接)。如图1所示,单个前端可以同时从多个位置管理集群。虽然集群架构已经在主要的云提供商上进行了测试,但自动供应功能只支持Equinix Metal和AWS。OpenNebula正在为其他广泛使用的云和边缘提供商开发驱动程序。

    5、存储体系结构
    我们的边缘云架构基于OneStor,这是一种专门的存储解决方案——完全由OpenNebula系统支持——它是为在高度分布式环境中高效管理磁盘映像而开发的。

    ● 访问作为全局图像存储库的外部(公共)市场。例如OpenNebula Marketplace或Docker Hub,还有私有HTTP存储库或容器注册表。
    ● 最小化映像传输,最大化应用程序I/O性能。集群可以在公共互联网连接上使用云/边缘部署模型。此外,本地供应可以扩展到大量主机。存储不应该成为这些情况的瓶颈。
    ● 简单的部署。通过使用Linux操作系统中已经存在的技术来适应物理和虚拟资源上的任何部署模型,以及增加后端可靠性,从而减少解决方案的复杂性和技术占用。

    边缘云架构结合了用于映像分发的3层全局架构和增强的文件系统数据存储,在每个边缘集群中具有副本缓存、快照和备份。3层存储体系结构(见图2)包括:

    ● 第1层由远程服务器和实现全局应用程序映像存储库的存储组成。它包括第三方网站,如Docker Hub或Linux Containers,以及OpenNebula公共市场。

    ● 第2层-图像数据存储。该层由区域映像数据存储组成,并提供OpenNebula区域的主映像存储位置。这个存储区域是为一个或多个专用节点提供的。它的内容被缓存并按需复制到每个集群。这支持任何位置的边缘集群部署,以及扩展本地基础设施。

    ● 第3层 - 集群复制。应用程序映像缓存在专用的复制主机集群中,以减少映像传输。复制主机利用专门的分发系统使所有集群主机都可以使用映像,并支持主机故障恢复的快照。
    边缘云架构的三层存储系统
    图2:边缘云架构的三层存储系统

    在每个第3层集群中,磁盘映像通过一种增强的SSH传输方式在Image和System数据存储之间传输,这种方式带有副本缓存和快照,极大地提高了其可伸缩性、性能和可靠性。新的复制模式将映像缓存到每个集群中,这样它们就可以在管理程序附近使用,从而减少对第2层映像数据存储服务器的带宽需求,并显著减少部署时间。这在高度分布式的边缘部署中尤其重要,因为将映像从第2层前端复制到第3层集群管理程序可能非常缓慢。

    边缘存储架构是通过轻量级技术组件实现的,这些组件转换成适度的硬件要求,如SATA ssd和10gb网络。此外,它的部署遵循超融合的方法,不需要专用服务器来实现分布式存储系统。这降低了解决方案的复杂性,使云集群主机可以使用本地存储区域。

    应用程序部署的性能
    应用程序映像基于qcow2格式的文件,以最小的开销减少文件传输和实例化时间。使用qcow2文件备份磁盘映像还简化了备份解决方案,减少了映像传输时间,并以一种有效的方式实现了快照等高级特性。预期的部署时间取决于层之间的互连链路和磁盘大小。作为参考,对于法兰克福的裸金属远程集群(第3层),使用公共互联网链接连接到位于阿姆斯特丹的第2层Image数据存储,我们获得了使用0.5 GiB的qcow2磁盘的应用程序的平均部署时间5s(热缓存)和35s(首次部署,空缓存)。图3描述了上述集群(包含缓存映像和不包含缓存映像)的平均部署时间。当集群使用1Gb/s链路部署时,部署时间一般为5s。
    与不具有缓存映像的部署时间的比较。
    图3. 与不具有缓存映像的部署时间的比较。

    应用程序的I/O性能
    应用从主机直接连接的存储上运行,以最大限度地提高应用的可用I/O性能。I/O性能接近本机主机,仅受虚拟化层的影响。为了提供这个开销的估计,我们在主机和VM上都运行了Flexible I/O测试器。已经在t1上采取了措施。Equinix metal上的一个小金属实例和一个运行在同一台服务器上的VM。表1总结了这两种机器的特性。
    在这里插入图片描述
    表2显示了在为顺序和随机的读和写操作运行基准时获得的平均带宽。物理主机与虚拟机性能基本相同,差异不超过5%。注意,虚拟页面缓存隐藏了一些延迟。
    在这里插入图片描述

    应用程序快照性能
    为了提高边缘集群块的可用性,在同一个集群中支持热迁移。应用程序快照也保存在边缘集群(第3层)中,以启用从最后一个应用程序检查点的快速恢复。

    恢复操作可能会影响两个不同的方面:

    ● 快照操作产生的I/O噪声可能会减少相邻应用程序的I/O。在我们的例子中,这个成本可以忽略不计,因为它基于QEMU写时重定向特性。
    ● 将恢复快照移动到集群复制服务器的网络带宽。在这种情况下,我们使用增量传输算法来减少传输到服务器的信息。然而,这个时间会随着磁盘的内容偏离原来的内容而增加。

    另一个需要考虑的重要方面是VM恢复时间。与恢复没有任何快照的VM相比,恢复时间是相似的,因为基本映像已经位于集群副本(第3层)上,唯一的额外开销是磁盘快照的传输,磁盘快照也已经在边缘集群中可用。

    备用存储后端
    OpenNebula支持最流行的企业级SDS(软件定义存储)后端,如Ceph或Gluster,旨在提供高可伸缩性和可用性。尽管这些平台具有高性能和丰富的特性,但运行这些平台需要丰富的经验、更高的财务投资、专用的硬件(无论它们是否是超融合的)和大量的资源。一般来说,它们的成本、复杂性和资源需求阻碍了它们在边缘集群中的实际应用。

    6、网络体系结构
    集群使用四种类型的网络:
    ● 存储网络专用于分发系统的应用程序镜像。
    ● 专网实现应用互联网络。
    ● 管理网络,用于主机接入前端业务。
    ● 将应用程序与因特网互连的公共网络。通常需要在边缘集群中预定义一组可用的公网ip。

    注意,当集群远程部署时,管理流量可以通过公网路由。

    每个网络的特征强烈地依赖于用于集群的部署模型。on-premises模型提供完整的网络功能,并基于标准linux桥接。专用应用网络是通过VLAN标记(802.1Q)实现的。

    另一方面,云集群或Edge集群可能会对每种网络类型的拓扑提供一些限制,这取决于所选的提供商。通常,OpenNebula网络堆栈使用特定的提供商驱动程序向应用程序和私有网络注册弹性公共ip。

    在这两种情况下,应用程序都受益于OpenNebula网络内核实现的特性,包括安全组、自动网络调度和用户自配置模型。
    概述边缘云架构中使用的网络。
    图3.概述边缘云架构中使用的网络.

    7、高可用性
    可用性是云架构设计的一个关键方面,尤其是在涉及应用程序数据恢复和完整性时。

    ● 前端:OpenNebula使用基于Raft的分布式共识协议,提供跨OpenNebula前端服务的容错和状态一致性。至少需要部署3个前端,才能支持1个节点故障。当前端在云资源上运行时,前端HA集群可以跨国家甚至大洲部署。

    ● 多集群:边缘云架构通过允许应用程序跨多个集群,帮助您自动部署地理分布的云和边缘环境,这些环境支持多云可用性模式。通过这种方法,您可以使应用程序比传统的单一数据中心基础设施具有更高的可用性、可伸缩性和容错性。
    集群:OpenNebula实现了远程集群的自治操作,在云上运行的集群和边缘位置可能失去与集中式中心的连接的情况下。在集群中运行的应用程序可以在没有任何管理服务的情况下继续其操作。

    ● 主机:边缘集群中的三层副本存储架构实现了基于定时快照的可用性系统,通过fencing节点防止脑裂(软的,由于本地I/O),并自动重新启动另一个节点中的应用程序,用于从虚拟机和主机故障中恢复。应用程序快照保存在集群(tier 3)中,以启用从最后一个应用程序检查点的快速恢复。可用性可以通过HW复制(HD Raid和NIC)和网络路径在每个节点内提高,也可以通过跨多个集群实现应用程序级HA(当需要数据和应用程序状态完整性时)在应用程序内提高。

    ● 应用:Edge集群的网络架构和OpenNebula编排功能允许开发人员在需要数据和应用状态完整性的地方使用应用特定的复制机制。此外,由于支持集群主机中的应用程序动态迁移,可以在系统运行时执行维护工作,并且可以减少主机故障。

    8、自动提供边缘簇
    OpenNebula提供了所需的配置工具和方法,可以随需动态地发展一个私有云基础设施,其资源运行在远程云和边缘提供商上。这种分解云的方法允许从集中式私有云无缝过渡到分布式类边缘云环境。公司能够利用云和边缘数据中心位置的资源来发展他们的私有云,以满足需求高峰或工作负载的延迟和带宽需求。这种方法涉及一个单一的管理层,在这个管理层中,组织可以继续使用现有的OpenNebula映像和模板,保持对基础设施的完全控制,并避免供应商锁定。

    OneProvision7工具允许在远程提供程序中部署完全可运行的边缘集群,并管理其整个生命周期,从其供应和维护开始,直到未供应为止。每个云或边缘位置(“供应”)被定义为一组从远程裸金属或虚拟提供商分配的物理主机。它们完全配置了用户选择的管理程序,并在云堆栈中为最终用户启用。

    9、在任何地方运行任何应用程序
    OpenNebula云的关键部分之一是支持现代应用程序、在单一平台上组合应用程序容器和虚拟机,以及与现有虚拟机和容器映像中心和市场集成的能力。

    OpenNebula拥有对其自己的市场的固有访问权,该市场允许用户从公共存储库(包含经过OpenNebula Systems测试和认证的常用图像)或私人存储库导入图像。可以将这些映像添加到数据存储中,并由现有的VM模板或实例随时使用。
    OpenNebula公共市场提供的一些虚拟设备。
    图5. OpenNebula公共市场提供的一些虚拟设备.

    OpenNebula用户可以轻松地从其他公共市场下载、上下文化和添加虚拟设备,包括Linux Containers8和TurnKey Linux。
    Linux Containers(左)和TurnKey Linux(右)提供的一些图片。
    图6. Linux Containers(左)和TurnKey Linux(右)提供的一些图片.

    应用程序开发现在越来越依赖于微服务体系结构,这避免了在修改或添加特定功能到应用程序时破坏整个堆栈。这种开发趋势与这些应用程序的部署方式紧密耦合,通常是通过应用程序容器。从版本5.12“Firework”开始,OpenNebula还与Docker Hub无缝集成,10允许在OpenNebula开放云中的任何管理程序上直接执行Docker Hub映像。这是应用程序的开发和分发模型,特别适合于边缘环境,因为只有少数遗留应用程序将部署在边缘,而新的应用程序很可能使用这些现代模型开发。
    OpenNebula与Docker Hub市场的原生集成
    图7. OpenNebula与Docker Hub市场的原生集成

    10、准备好测试了吗?
    您可以在几分钟内使用miniONE,11我们的部署工具来快速安装OpenNebula前端到虚拟机或物理主机中,然后您可以使用它轻松添加基于KVM, LXC或fireacker的远程边缘集群。
    miniONE

    11、结论
    很明显,现代云的发展导致了高度复杂系统的创建,这些系统通常基于专有技术。本文档概述了OpenNebula的简单性选择和开源备选方案,并介绍了由边缘集群组成的强大边缘云架构。它们是使用Linux操作系统中已经存在的存储和网络技术按需构建的,可以运行任何工作负载——虚拟机和应用程序容器——在任何裸金属资源或任何地方的虚拟资源上、在云上或在边缘上。我们的边缘云架构通过将公共和私有云操作与工作负载可移植性以及IT基础设施和应用程序的统一管理相结合,实现了真正的混合和多云计算。现在,您可以享受单一供应商的体验:我们通过我们的OpenNebula软件订阅为完整的软件堆栈提供企业支持,并通过新的OpenNebula管理订阅提供管理云服务,因此您的团队可以忘记基础设施,专注于业务工作负载。联系我们,我们期待在您的云计算旅程的任何阶段为您提供帮助。

    展开全文
  • 编者按:《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践。本文是该系列的第一篇,主要讲解了在新浪微博业务背景下DCP的核心设计...
  • 这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile ...
  • 通过剖析和展示一个端到端的简化微服务应用案例MovieApp,帮助学员学习理解现代微服务应用和原生架构实践,内容包括: 微服务应用架构前后分离应用架构基于Spring Security + JWT的微服务安全架构Spring Boot...
  • 随着行业业务的变化、技术架构的演进以及阿里产品的迭代演进,整体的产品技术选型在不同的游戏场景、业务场景也不尽相同。本文将聚焦阿里弹性计算产品在游戏行业的方案实践经验。 二、游戏行业场景介绍 当前,...

    一、概述

    游戏行业是阿里云最早聚焦的行业之一,近年来游戏行业的变化、云计算产品技术的变化都与日俱进。随着行业业务的变化、技术架构的演进以及阿里云产品的迭代演进,整体的产品技术选型在不同的游戏场景、业务场景也不尽相同。本文将聚焦阿里云弹性计算产品在游戏行业的方案实践经验。

    二、游戏行业场景介绍

    当前,游戏行业的各种场景和行业发展密不可分。简单回顾电子游戏的发展,80年代的黑白机,90年代的PC单机游戏,00年代前夕随着互联网的发展网络游戏开始盛行,2010年后随着移动设备的逐渐普及,手游在国内开始兴起。

    从游戏终端来区别,主要有:主机游戏(往往是3A游戏)、PC游戏、移动游戏和网页游戏等。目前出现跨平台多端游戏,以及云游戏化的趋势。

    关于游戏的品类区别会有非常多的维度:RPG(角色扮演)、MOBA类、竞技类、FPS(射击类)、休闲类、卡牌类、棋牌类、SLG(策略类)等等。目前有多品类融合玩法裂变的趋势。

    随着国内防沉迷、版号因素,近年来游戏行业诞生了越来越多的精品游戏,出海全球化乃至区域化,以及整体存量用户增速放缓,长线运营、精细运营以及私域社区等运营方式也在悄然变化。

    三、游戏行业技术架构介绍

    不同的业务场景技术架构不尽相同,如竞技类游戏和卡牌类游戏对计算的需求就有所区别,云游戏与常规的网络游戏架构也有所区别。这里主要从游戏服和游戏平台、大数据、云游戏这四个目前常见的场景简单介绍其架构。

    1. 游戏服架构与产品实践

    业务场景

    游戏服,从游戏类型来看有RPG、FPS、MOBA、SLG、棋牌、休闲等等;从游戏平台来看通常有主机、手机、PC等;从业务发行来看有全球、国内、海外,从部署架构来看有集中部署和分区部署;从技术架构来看,游戏行业也有逐渐分层解耦的趋势,但与互联网应用相比,有一定其独特性。

    技术特点

    因为游戏的强交互性特点,游戏技术架构与其他互联网应用相比有一定独特性。游戏需要保持会话连接,也就是从一个客户端到服务端的长连接,便于对客户端中玩家的操作、行为等进行及时的反馈以及推送给共同游戏或对战的其他玩家,所以游戏普遍对网络质量更加敏感,网络质量较差的情况会使长连接断开或重连,引起玩家掉线。游戏也需要保持会话的状态,既服务端会保持一份玩家的实体,当玩家进行操作时,下次通信的数据会依赖之前的通信的数据,这也是一些MMO(多人在线)大型游戏对网络吞吐性能要求较高的原因之一。再比如FPS、MOBA类等多人对战类游戏,交互性更强,对网络延迟容忍度更低,要求低延迟。因为游戏需要比较高密度的记录玩家的操作以及结果,所以有频繁写入数据的特点,这类场景需要较强的IO性能。因为游戏强交互性、低延迟的特点,其技术架构也和互联网应用不同,在逐渐分层解耦的同时,需要保证游戏玩家的交互效果,同时也会依赖到底层服务器的计算能力

    这些都是游戏场景普遍存在的特点:长连接保持会话、保持状态、低延迟网络、高IO吞吐、高计算性能。

    部署方案

    游戏的部署架构会结合游戏业务特点、游戏运营需求来制定游戏服务,有分区分服、全区全服业务逻辑,分区分服还是全区全服,最大的架构差异在于数据是不是一套。而从部署方式看,主要是集中式部署和分区域部署。

    集中部署就是不论游戏玩家在哪里,游戏服务集中在一个区域,适合对网络延迟要求通常不高的游戏类型,如休闲类;分区部署是指游戏服务器根据游戏玩家地域分布,分区域部署,方便就近接入,适合对网络延迟要求较高的游戏类型,如MOBA、FPS类。

    典型架构

      1. MMORPG类游戏架构介绍

    MMO类有高并发特点,大量玩家并发的高计算量负载对服务器的计算能力稳定性有着极高的要求。同时MMO类游戏有着比较强的PVE或PVP特性,对网络延迟的容忍度较低。

    其中网关服务器负责所有网络数据包的转发,通常是网络负载较集中的点,对于网络吞吐能力要求较高。单个游戏区承载玩家数量高,逻辑服务器通常按照场景地图来划分,规模再大会通过分区的方式实现。

    数据中心服务器负责缓存玩家数据并异步入库,保障玩家客户快速获取和写入数据,对于可用性要求较高,需要配合应用层实现数据容错机制。

    日志服务器承载了大区所有业务行为的日志收集及处理的压力,对磁盘写入性能要求较高,通常采用多台分组方式实现。 

    弹性计算产品建议:

    (1)MMO游戏服性能与稳定需求,建议使用最第7代ECS实例,根据实际需求选型c计算型(CPU与内存配比1:2)/g通用型(1:4)/r内存型(1:8),Intel Ice Lake 2.9GHz基频3.5GHz睿频提供超高性能,能更好地优化游戏体验。

    (2)异步落库以及日志服务器,对于磁盘读写性能要求高的场景,建议云上使用ESSD PL 0/1/2/3根据业务性能需要选择,避免磁盘读写瓶颈。

    (3)在游戏日常版本更新中,需要各个地域Region镜像的快速复制,基于ESSD快照异地复制的能力,能够提升镜像复制效率。

    (4)分区分服等场景往往需要快速地开服滚服合服,通过CADT云速搭、ESS弹性伸缩、OOS运维编排、ROS资源编排等云上运维工具搭配产品使用,能够提升云上运维效率。

      1. FPS、MOBA类游戏架构介绍

    MOBA类游戏主要包括PVP系统、PVE系统、游戏平台等几个主要部分,其中PVP战斗是MOBA/FPS游戏的核心。

    PVP、PVE、游戏平台功能部署于同一VPC中,构成游戏大区;战斗服务器(往往)单独跨地域部署

    游戏客户端首先接入到登录服务器中,完成登录认证、计费等游戏平台逻辑。为避免单点问题,所以游戏平台服务往往需要高可用方案。可利用云上高可用方案,包括便捷的运维工具满足业务高可用需求。

    FPS/MOBA竞技游戏,往往对延迟特别敏感,可以想象,竞技类游戏中对战的游戏场景:玩家操控人物,在地图里步伐飘逸,枪声密集,每一颗子弹都是一次时间加上空间的矢量计算,而且需要在主进程中完成计算,那么算力需求就随着房间玩家数量上升而指数爆炸,5V5的房间和大房间100人(吃鸡)对算力的需求完全不同。

    游戏这部分重算力场景,推荐阿里云7代高主频或七代实例,更高的单核性能提供更好的战斗效果。

    战斗房间类游戏,因为业务本身峰谷特性,灵活地使用云上资源的弹性能力,往往会较好地优化整体的资源使用成本。阿里云弹性计算本身提供了非常灵活的付费方式,包括常规的按量实例、包月包年实例、以及通过节省计划/预留实例券去抵扣按量实例资源,兼顾资源灵活使用的同时达到更优的成本。

    此外,为更进一步释放开发运维的效率,当前一些游戏也采用了容器化技术架构,阿里云的ACK+ECS/ECI弹性容器实例组合搭配使用,更进一步释放了基础资源的灵活性和弹性能力。

    1. 游戏平台

    业务场景

    游戏平台(不限于FPS、MOBA类)主要提供的服务:官网、客服、注册、登录、充值、兑换、商城、推送、公告、社区、SDK及邮件、短信等公共服务;包括内容审核、视频录制、弹幕、转码、剪辑、RTC这些业务需要的基础服务,以及运维监控、发布平台、测试平台这些运维等平台服务。

    这部分更接近于通用的互联网技术架构,以服务为颗粒度解耦,接入->网关->应用->数据库。

    技术特点

    这往往通常需要构建高可用基础架构来提升稳定性,业务突发期往往需要一定的弹性能力。相比于游戏服务这部分容器化就更加普及,也更容易通过云上的比如弹性容器实例去应对流量峰值场景。在视频录制场景,对实时性要求较高时,往往会基于GPU能力构建,这部分阿里云也提供了vGPU/cGPU能力,释放GPU的灵活性。

    1. 大数据架构与产品实践

    业务场景

    游戏全生命周期的业务表现,用户留存、经营转化、包括游戏内玩法策略等都是游戏厂商非常关注的业务支撑数据。

    大数据是当前游戏业务经营、游戏运营主要的技术手段,主要面向平台数据运营、游戏数据分析、广告转化分析、安全运营分析等游戏核心运营场景。不同的场景对实时性要求不同,实时查询检索通常是经营分析、客户受理、玩家监测、在线等场景;离线报表通常是玩家行为分析、用户画像、特征挖掘等场景。

    总体而言,实时性业务更多是业务查询类、简单计算类任务,比如买量转化的分析;离线类基本是分析类、预测类任务,比如游戏玩法分析。

    架构特点

    从技术架构来看,得益于开源社区技术栈的高丰富度,大数据具体的技术选择非常之多,整体从存算一体到存算分离,也诞生像数据仓库、数据湖乃至湖仓一体等概念。

    从数据架构流程来看,从数据源->数据采集、传输->数据计算、存储->数据应用,其中可选看技术方案也需要因地制宜。

    从部署架构来看,不同的游戏公司处在不同的数据建设阶段,会有不同的选择倾向,包括完全自建、基于云自建大数据、基于云上托管、以及利用更多云上成熟的产品技术去丰富整体的大数据能力集,而后者也成为越来越多客户的选择。

    拿云上大数据方案举例来讲,比如实时计算部分,选择SLS采集、Kafka数据网关通道,通过Flink做数据计算,通过ES或CK做数据分析,通过ADB以及QuickBI做数据应用展示。离线方案通过OSS做冷数据存储,Spark、Hive、HDFS等组件做数据计算存储,通过CK汇聚分析,通过Dataworks做数据应用。

    产品选型

    具体计算存储的产品选型,主要根据不同的业务特性以及大数据应用特性来区分,根据数据容量、IOPS、吞吐、读写特点以及性价比来选择。

    如刚刚举例的实时计算/近实时计算场景,Flink具备高性能、低延迟特点,所以是计算密集、网络性能高场景,推荐选型七代ECS实例或6代增强实例;如HDFS需要超大存储容量,高吞吐,推荐D系列本地盘实例,如D2S存储型本地盘实例。Remote Shuffle Service等处理结果多的场景,读写处理频繁如大量的join计算,需要综合来看计算、网络、存储性能以及综合成本来选择通用实例(如第7代ECS实例)或i系列本地盘实例。所以,最终在云上的资源选型,在性能满足的前期下,需要评估通过网络传输数据成本高(云盘),还是就地取材计算成本高(本地盘),不同模型、不同量级选择不同。

    从内存处理(成本最高、性能最好、存储容量最小)、SSD本地盘、HDD本地盘、ESSD云盘、OSS对象存储(成本最优、性能一般、存储容量最大),逐渐分层解耦,还带来一个好处:充分释放了云上弹性的能力,可以利用更轻巧的弹性计算产品(如SPOT抢占式实例方式,或ECI容器实例)进行大数据计算,达到更好的弹性能力去满足业务需求的同时也能节约更多的成本。

    1. 云游戏架构与产品实践

    业务场景

    从2009年ONLIVE提出云游戏理念与产品开始,云游戏已经熬过了一个技术周期,尤其在近两年,我们也能够看到越来越多的公司关注云游戏,投入云游戏。平台以流化能力为技术基础,以视频流化形式带动游戏运行,使用户以低成本享受更高品质游戏产品,并根据实际将云游戏的需求覆盖到PC端、移动端、电视端等终端场景。

    架构特点

    云游戏主要分终端和云端。终端部分基于Windows、iOS、Linux等操作系统的终端设备包括手机、平板、电脑、电视机、VR一体机等。云端架构主要是游戏应用层、云游戏平台层、IaaS基础资源层,应用层包括PC游戏、手游、VR游戏、H5游戏等多种类型的游戏应用;平台层云游戏必须的运营平台、支撑平台、流化技术平台等;IaaS基础资源层包括基础网络、基于X86架构以及ARM架构的GPU服务器。

    产品推荐

    云游戏落地,在技术上也经历了诸多挑战,为满足端到端高性能低时延,网络调度、指令串流、编解码、多终端的SDK适配等等都是云游戏场景中不可避免的技术问题。

    对于云端算力来讲,阿里云解决了云端渲染、串流以及编解码问题,并通过全系列GPU产品来满足云手游、端游、VR乃至企业级视觉渲染场景的需求。


    总结来讲,阿里云弹性计算通过云上的串流、编码加速、渲染加速等全套的技术帮助游戏客户给云游戏玩家提供更好的性能体验,通过基于阿里云全球数据中心可以帮助云游戏客户覆盖更多的用户,通过GPU多种产品形态和整体的弹性能力,也帮助到游戏客户去更快捷更灵活的构建其云游戏业务。

     

    四、总结

    阿里云通过多年的技术积累和持续的运营,提供了大规模的基础设施云服务,目前在全球部署了26个地域、82个可用区,通过优异稳定的性能表现帮助游戏客户高效稳定地运行游戏业务,为玩家提供极致顺滑的游戏体验,并通过技术手段不断地帮助游戏客户优化用云成本。

    国内的业务出海、游戏出海也是现阶段大的趋势之一,很多游戏公司已经把出海从业务可选项变成了必选项之一。在2022年3月,阿里云上线了韩国和泰国两大Region,能够为本地化的游戏业务提供更流畅、更稳定的游戏体验,以此希望能在游戏客户出海的业务领域,提供更多的帮助。

    当然,作为内容与科技两大热门领域的交叉领域,游戏产业日新月异,架构也随着前端业务的需要不断改变。阿里云弹性计算也针对游戏厂商的不同架构,陆续推出了不同的云服务器类型和付费方式,以及云上运维套件,以帮助客户降本增效。

    未来,阿里云将持续对游戏行业保持高度关注,始终为行业提供坚实、稳定、便捷的基础设施,一同推动游戏产业的健康发展。

     

    展开全文
  • 一文搞懂原生架构

    多人点赞 热门讨论 2022-05-26 15:36:58
    在当今瞬息万变的大数据信息世界中,云...充分利用云革命的关键是为软件开发需求设计正确的云架构。建议在正确的领域实施正确的自动化,充分利用托管服务,整合 DevOps 最佳实践,并应用最佳的云原生应用程序架构模式。
  • 该资源中国矿业大学软件架构课程的课程研讨PPT,是我们小组制作的,主要讲了如何使用云产品,利用云架构搭建一个大型门户网站,内容包括网站的功能,架构以及部署和使用的云产品。 具体内容分为以下几个模块展开: ...
  • 4.1 云架构的基本层次

    千次阅读 2021-06-17 04:21:44
    第4章 核心结构——云的架构4.1 云架构的基本层次从服务类型来看,云计算中的云可以分为基础设施云、平台云和应用云...由美国国家标准研究院(NIST)提出的被全球广泛引用的云架构包含了三个基本层次:基础设施层(Inf...
  • 存储基础架构剖析

    2021-02-26 23:38:57
    增长速度最快的数据是归档数据,鉴于很多因素它是存储的理想之选,这些因素包括成本、访问频率、保护和可用性。但是并非所有存储都是相同的。一家提供商可能主要关注于成本,而另一家提供商关注于可用性或性能。...
  • 阿里神龙架构.ppt

    2020-12-07 10:52:42
    PPT包括神龙是什么、虚拟机vs物理机、云计算的历史性难题、神龙硬件体系、神龙软件体系、一代、二代、三代神龙、AWS nitro
  • 华为一方面以公有云服务的形态提供给客户,另一方面也以HCS解决方案的形态支撑企业私有,双拳合一提供最具竞争力的混合解决方案。华为云服务大致可分为13大类:计算、存储、网络、数据库、安全、应用服务、域名...
  • 原生架构重要组成部分之微服务

    千次阅读 2022-02-15 22:11:15
    各大厂商公司都运用了该技术架构,随着技术与理念的升级迭代,原生概念应世而起,现在火的一塌糊涂。做为新时代的程序员,我们要抓住原生的浪潮。 这篇文章呢大致分为四部分,第一部分简单谈一下什么是...
  • Dustin.Whittle给出了应用的示例架构,它具有高度的可扩展性,如下图所示:在这个图中,应用按照分层的理念进行了拆分,分别介绍如下:客户端层:客户端层包含了针对目标平台的用户界面,可能会包括
  • 华为云-公有云架构

    千次阅读 2020-06-13 19:24:48
    华为云-公有云架构 华为公有云架构 华为公有云的主要服务如弹性云服务器(ECS)、弹性伸缩服务(AS)、云硬盘 (EVS)、云硬盘备份(VBS)、对象存储服务(OBS) 、虚拟私有云(VPC)、弹性负 载均衡(ELB)、...
  • 考试范围包括上云迁移、原生应用设计、高可用架构设计、业务流量高峰处理架构设计、信息安全、大数据产品与服务、构建混合、AI解决方案、游戏行业解决方案及视频行业解决方案,面试题吧来详细说下腾讯高级技术...
  • 最近断断续续花了差不多2到3周的时间阅读完由电子工业出版社出版的《金融级IT架构:数字银行的原生架构解密》的这本书,作者是作者是网商银行技术编委会。 本书契合了当前银行业分布式架构转型趋势,内容是经过...
  • 原生架构白皮书.zip

    2021-08-05 23:34:09
    讲述原生架构包括云原生架构的定义、主要原生技术、原生架构设计、原生产品的介绍、原生架构实践案例、原生架构未来发展趋势,很不错,快来下载吧。
  • 2021-系统架构设计师资料(包括视频资料)
  • 桌面架构纵横

    千次阅读 2019-02-27 14:11:18
    今天我们讲的是一篇关于桌面架构技术的知识,希望给大家带来帮助! 计算模式 看桌面计算模式,了解从用户类型如何到移动用户和任务工作者,如何实现桌面的真正管理。 桌面三种架构(VDI IDV VOI) 1、VDI...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 230,931
精华内容 92,372
关键字:

云架构包含哪些