精华内容
下载资源
问答
  • 云存储技术的两种架构
    千次阅读 多人点赞
    2022-05-26 15:36:58

    前言俯瞰:什么是云原生?

    目前,每个 IT 资源或产品都作为服务提供。而且伴随云计算的滚滚浪潮,云原生(CloudNative)的概念应运而生,云原生很火,火得一塌糊涂,都0202年了,如果还不懂云原生,那真的out了。因此,云原生软件开发成为每个企业的关键要求,无论其规模和性质如何。在加入云计算潮流之前,了解什么是云原生架构以及如何为云原生应用程序需求设计正确的架构非常重要。

    云原生架构是一种创新的软件开发方法,专为充分利用云计算模型而设计。它使组织能够使用微服务架构将应用程序构建为松散耦合的服务,并在动态编排的平台上运行它们。因此,基于云原生应用程序架构构建的应用程序是可靠的,可提供规模和性能,并缩短上市时间。
    在这里插入图片描述

    有人会说,云原生就是微服务,我觉得是不对的。云原生和微服务是两个不同维度的东西。 云原生更侧重应用程序的运行环境, 它是以k8s和容器为基础的云环境。“云原生计算基金会”致力于打造一整套工具来帮助应用程序从开发,测试,运行以及部署到云环境。

    微服务是应用程序的软件架构,可以是单体式和微服务式。 微服务是基于分布式计算的。 你的应用程序即使不采用微服务架构也可以是云原生的,例如分布式的,但效果没有微服务好。 如果是单体式的,云原生就基本发挥不出什么优势。 另外微服务的程序也可以不是云原生的。它们虽然是两个不同的东西,但云原生和微服务是天生良配,相得益彰,相辅相成。 而且很多云原生的工具都是针对微服务架构设计的。

    当然,更合适的方式是可以说现代应用程序的趋势就是"微服务+云原生"。因为云原生的几大特征就是:容器化封装管理、服务编排、微服务架构、持续交付、DevOps。

    在当今瞬息万变的大数据信息世界中,云原生架构不再是可选的,而是必需的。变化是云中唯一不变的东西,这意味着您的软件开发环境应该足够灵活,以便在不干扰业务运营的情况下快速适应新技术和方法。云原生架构为使用正确的工具、技术和流程构建应用程序提供了正确的环境。充分利用云革命的关键是为软件开发需求设计正确的云架构。建议在正确的领域实施正确的自动化,充分利用托管服务,整合 DevOps 最佳实践,并应用最佳的云原生应用程序架构模式。

    后起之秀:云原生

    日薄西山:传统的软件开发模型?

    传统的软件开发环境依赖于由单体架构驱动的所谓“瀑布”模型,其中软件是按顺序开发的。

    1、设计师准备产品设计以及相关文件。
    2、开发人员编写代码并将其发送给测试部门。
    3、测试团队运行不同类型的测试来识别错误并衡量云原生应用程序的性能。
    4、发现错误时,会将代码发送回开发人员。
    5、代码成功通过所有测试后,将部署到测试生产环境并部署到实时环境。
    在这里插入图片描述

    如果需要更新代码或添加/删除功能,则必须重新完成整个过程。当多个团队在同一个项目上工作时,相互协调代码更改是一个很大的挑战。它还限制他们使用单一的编程语言。此外,部署大型软件项目需要建立庞大的基础架构以及广泛的功能测试机制。整个过程效率低下且耗时。

    引入了微服务架构来解决大多数这些挑战。微服务架构是一种面向服务的架构,其中应用程序构建为松散耦合的独立服务,可以通过 API 相互通信。它使开发人员能够处理不同的服务并独立使用不同的语言。借助充当版本控制系统的中央存储库,组织能够同时处理代码的不同部分并更新特定功能,而不会干扰软件或导致应用程序停机。此外,实施自动化后,企业可以轻松、频繁地进行具有重大影响的更改,而无需付出多少努力。

    横空出世:云原生简介

    在微服务架构基础上改进增强的云原生应用程序利用高度可扩展、灵活和分布式的云特性,在持续交付环境中生产以客户为中心的软件产品。云原生架构的显着特点是它允许您抽象基础架构的所有层,例如数据库、网络、服务器、操作系统、安全性等,能够使用脚本独立地自动化和管理每一层。同时,可以使用代码立即启动所需的基础架构。因此,开发人员可以专注于向软件添加功能和编排基础架构,而不必担心平台、操作系统或运行时环境。

    在这里插入图片描述

    纵横驰骋:三大技术基石

    1:基础设施即代码

    Infrastructure As Code,是指把创建基础设施(包括服务器和网络环境)的命令像应用程序一样储存在源码库中,并进行版本管理。这样创建基础设施的过程就变成了部署软件的过程。它的最大的好处就是可重复性。以前的方法是用人工敲入命令来创建运行环境,出了问题就在原来的基础之上进行修修补补,一旦需要把整个环境重新建立,很难保证与原来的一样。 当使用基础设施即代码之后,再也没有了这个担心。

    2:不可变基础设施

    Immutable Infrastructure,它是基础设施即代码的升级版。有了基础设施即代码之后,随时都可以通过运行软件再构建出一个一模一样的服务器和其他需要的设备,并且还能预装应用程序,创建的时间还是秒级的。这时当服务器出现问题时,就没有必要去花时间查找原因了并修复了,而是直接把服务器销毁重新创建一个新的。因此这时的基础设施是不可变的,只有创建和删除,而没有修改操作。这彻底改变了运维的方式。

    3:声明式API

    Declarative APIs:声明式API也是基础设施即代码的升级版。最开始时,当用软件定义基础设施时是用的过程式描述,也就是通过运行一系列的命令来创建运行环境。后来发现更好的办法是描述最终运行环境的状态,而由系统来决定如何来创建这个环境。例如,你的描述就变成“创建一个有三个Nginx的集群”,而不是把创建Nginx的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时,系统能检测到差异,并自动修复,这样系统就有了自动容错的功能。

    如日中天:云原生的优点

    1:加速软件开发周期

    云原生应用程序补充了基于 DevOps 的持续交付环境,并在整个产品生命周期中嵌入了自动化,从而为桌面带来速度和质量。跨职能团队由来自设计、开发、测试、运营和业务的成员组成,通过SDLC无缝协作和协同工作。通过开发部分的自动化CI/CD 管道和运营部分的基于 IaC 的基础设施协同工作,可以更好地控制整个过程,使整个系统快速、高效且无错误。整个环境也保持透明度。所有这些元素都显着加快了软件开发生命周期。

    软件开发生命周期 (SDLC) 是指软件产品开发中涉及的各个阶段。典型的 SDLC 包括 7 个不同的阶段。

    1、需求收集/计划阶段:收集有关当前问题、业务需求、客户请求等的信息。
    2、分析阶段:定义原型系统要求、现有原型的市场研究、针对提议的原型分析客户需求等。
    3、设计阶段:准备产品设计、软件需求规范文档、编码指南、技术栈、框架等。
    4、开发阶段:编写代码以根据规范和指南文档构建产品
    5、测试阶段:测试代码的错误/错误,并根据 SRS 文档评估质量。
    6、部署阶段:基础设施配置、软件部署到生产环境
    7、运营和维护阶段:产品维护、处理客户问题、根据指标监控性能等。

    2:更快的上市时间

    速度和服务质量是当今快速发展的 IT 世界中的两个重要要求。由 DevOps 实践增强的云原生应用程序架构可帮助轻松构建和自动化持续交付管道,从而更快、更好地交付软件。IaC 工具使按需自动配置基础设施成为可能,同时允许随时随地扩展或拆除基础设施。通过简化 IT 管理和更好地控制整个产品生命周期,SDLC 显着加快,使组织能够更快地进入市场。DevOps 专注于以客户为中心的方法,团队负责整个产品生命周期。因此,更新和后续版本也变得更快更好。开发时间缩短,生产过剩,过度工程和技术债务也可以降低总体开发成本。同样,提高生产力也会增加收入。

    3:高可用性与弹性

    现代 IT 系统不允许停机。如果产品经常停机,那就是大问题。通过将云原生架构与微服务和 Kubernetes 相结合,可以构建可自我修复的弹性和容错系统。在停机期间,应用程序仍然可用,因为可以简单地隔离故障系统并通过自动启动其他系统来运行应用程序。因此,可以实现更高的可用性、改进的客户体验和正常运行时间。

    4:更低的成本

    云原生应用程序架构带有按使用付费的模式,这意味着所涉及的组织只需为使用的资源付费,同时从规模经济中受益匪浅。随着资本支出转变为运营支出,企业可以将其初始投资转换为获取开发资源。在运营支出方面,云原生环境利用了由开源 Kubernetes 软件管理的容器化技术。市场上还有其他云原生工具可以有效地管理系统。借助无服务器架构、基础设施标准化和开源工具,运营成本也随之下降,从而降低了 TCO。

    5:将应用程序转变为API

    云原生环境能够使用基于 API 的集成将海量企业数据与前端应用程序连接起来。由于每个 IT 资源都在云中并使用 API,因此应用程序也变成了 API。因此,它提供了引人入胜的客户体验,并允许使用传统基础架构,从而将其扩展到云原生应用程序的 Web 和移动时代。

    厚积薄发:云原生架构模式特点详解

    1:现收现付

    在云架构中,资源通过按使用付费或即用即付模式通过 Internet 集中托管和交付。客户根据资源使用情况付费。这意味着可以在需要时扩展资源,将资源优化到核心。它还提供了各种支付率的灵活性和服务选择。例如,无服务器架构允许仅在执行代码时提供资源,这意味着只需在应用程序使用时付费。

    2:自助服务基础设施

    基础设施即服务(IaaS) 是云原生应用架构的关键属性。无论您是在弹性、虚拟还是共享环境中部署应用程序,您的应用程序都会自动重新调整以适应底层基础设施,并根据不断变化的工作负载进行扩展和缩减。这意味不必从服务器、负载平衡器或中央管理系统寻求和获得许可来创建、测试或部署 IT 资源。在缩短等待时间的同时,简化了 IT 管理。

    3:分布式架构

    分布式架构是云原生架构的另一个关键组件,它允许跨基础架构安装和管理软件。它是安装在不同位置的独立组件的网络。这些组件共享信息以实现单一目标。分布式系统使组织能够大规模扩展资源,同时给最终用户留下他正在一台机器上工作的印象。在这种情况下,数据、软件或硬件等资源是共享的,单个功能同时在多台机器上运行。这些系统具有容错性、透明度和高可扩展性。虽然较早使用客户端-服务器架构,但现代分布式系统使用多层、三层或对等网络架构。分布式系统提供无限的水平扩展、容错和低延迟。不利的一面是,他们需要智能监控、数据集成和数据同步。避免网络和通信故障是一项挑战。云供应商负责治理、安全、工程、演进和生命周期控制。不必担心云原生应用程序中的更新、补丁和兼容性问题。

    4:管理服务

    云架构允许充分利用云托管服务,从而有效地管理云基础架构,从迁移和配置到管理和维护,同时优化核心时间和成本。由于每个服务都被视为一个独立的生命周期,因此将其作为敏捷的 DevOps 流程进行管理很容易。可以同时使用多个 CI/CD 管道,也可以独立管理它们。

    例如,AWS Fargate 是一种无服务器计算引擎,可让构建应用程序,而无需通过按使用付费模式管理服务器。Amazon lambda 是另一个用于相同目的的工具。Amazon RDS 使您能够在云中构建、扩展和管理关系数据库。Amazon Cognito 是一个强大的工具,可帮助安全地管理所有云应用程序上的用户身份验证、授权和管理。借助这些工具,可以以最少的成本和精力轻松设置和管理云开发环境。

    5:自动放缩

    自动缩放是云原生架构的一项强大功能,可自动调整资源以将应用程序维持在最佳水平。自动缩放的好处是可以抽象每个可缩放层并缩放特定资源。有两种方法可以扩展资源。垂直扩展增加了机器的配置来处理不断增长的流量,而水平扩展增加了更多的机器来横向扩展资源。垂直扩展受容量限制。水平扩展提供了无限的资源。

    例如,AWS 提供开箱即用的水平自动扩展。无论是弹性计算云 (EC2) 实例、DynamoDB 索引、弹性容器服务 (ECS) 容器还是 Aurora 集群,Amazon 都会根据定义的每个应用程序的统一扩展策略监控和调整资源。您可以定义可扩展的优先级,例如成本优化或高可用性,也可以同时平衡两者。AWS 的 Autoscaling 功能是免费的,但需要为横向扩展的资源付费。

    6:自动恢复

    在如今必须保证产品每时每刻运行可用的时代,为确保所有资源的高可用性,为所有服务、数据资源和基础架构制定灾难恢复计划非常重要。云架构允许从一开始就将弹性整合到应用程序中。可以设计自我修复应用程序,并可以立即恢复数据、源代码存储库和资源。

    例如, Terraform 或 CloudFormation 等IaC 工具允许自动配置底层基础设施,以防系统崩溃。从预置 EC2 实例和 VPC 到管理和安全策略,可以自动化灾难恢复工作流程的所有阶段。它还可以帮助您立即回滚对基础架构所做的更改或在需要时重新创建实例。同样,可以使用 Jenkins 或 Gitlab 等 CI 自动化服务器回滚对CI/CD 管道所做的更改。这意味着灾难恢复快速且具有成本效益。

    7:自动化和基础设施即代码IaC

    通过在现代系统设计支持的微服务架构上运行容器,组织可以在业务流程中实现速度和敏捷性。为了将此功能扩展到生产环境,企业现在正在实施基础架构即代码 (IaC)。组织可以通过应用软件工程实践来自动化资源配置,通过配置文件来管理基础设施。通过测试和版本控制部署,可以自动化部署以将基础架构保持在所需状态。当需要更改资源分配时,您可以简单地在配置文件中定义它并自动将其应用到基础架构中。IaC 将一次性系统带入画面,可以在其中即时创建、管理和销毁生产环境,同时自动执行每项任务。

    云设计非常有利于自动化。可以使用Terraform 或 CloudFormation自动化基础架构管理、使用 Jenkins/Gitlab 的 CI/CD 管道,以及使用 AWS 内置功能自动扩展资源。云原生架构使您能够构建与云无关的应用程序,这些应用程序可以部署到任何云提供商平台。Terraform 是一款功能强大的工具,可帮助您使用 Hashicorp 配置语言 (HCL) 创建模板,以便在 AWS、Azure、GCP 等流行云平台上自动配置应用程序。CloudFormation 是 AWS 提供的一项流行功能,用于自动配置工作负载在 AWS 服务上运行的资源。它使您可以轻松地在 AWS 服务上自动设置和部署各种 IaaS 产品。如果您使用各种 AWS 服务,使用 CloudFormation 可以轻松实现基础设施自动化。

    8:不可变的基础设施

    不可变的基础设施或不可变的代码部署是部署服务器的概念,因此它们不能被编辑或更改。如果需要更改,则服务器将被销毁,并从公共图像存储库在该位置部署新的服务器实例。并非每个部署都依赖于前一个部署,并且没有配置偏差。由于每个部署都带有时间戳和版本,因此如果需要,您可以回滚到早期版本。

    不可变的基础架构使管理员能够轻松更换有问题的服务器,而不会干扰应用程序。此外,它使部署在所有环境中变得可预测、简单且一致。它还使测试变得简单。自动缩放也变得容易。总体而言,它提高了部署环境的可靠性、一致性和效率。Docker、Kubernetes、Terraform 和 Spinnaker 是一些有助于不可变基础架构的流行工具。此外,实施 12 要素方法原则还有助于维护不可变的基础架构。

    9:12因子方法论

    为了促进开发同一应用程序的开发人员之间的无缝协作,并随着时间的推移有效地管理应用程序的动态有机增长,同时最大限度地降低软件侵蚀成本,Heroku 的开发人员提出了一种 12 因素方法,可帮助组织轻松地在云中构建和部署应用程序 -本机应用程序架构。这种方法的关键要点是应用程序应该对所有部署使用单一代码库,并且应该打包所有相互隔离的依赖项。配置代码应与应用代码分开。进程应该是无状态的,以便您可以单独运行它们、扩展它们并终止它们。同样,应该构建自动化 CI/CD 管道,同时单独管理构建、发布和运行无状态流程。另一个关键建议是应用程序应该是一次性的,以便您可以独立启动、停止和扩展每个资源。12 因素方法非常适合云架构。

    更多相关内容
  • ☁️原生技术 ☁️起源 ☁️CNCF组织 ☁️原生介绍 ☁️十二要素 ☁️容器化封装 ☁️服务编排 ☁️微服务架构 ☁️小结 ☁️原生相关技术图谱 ☁️CNCF 的原生全景图 ☁️原生全景图的 4 层 ☁️供应层 ...

    ☁️起源

    2014年,谷歌开源了一个主要用于容器编排的Borg内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而后来Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。

    ☁️CNCF组织

    CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。

    CNCF在云端的自我使命是通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。

    目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。

    640?wx_fmt=jpeg

    CNCF成员项目包括12个类别:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流,下面内容重点介绍前几个类别。

    编排:Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。

    应用程序开发: Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)

    监控: Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案,灵感来自于谷歌的Borgman监控系统。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。

    日志和跟踪: Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。另外,还有Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing日志跟踪软件兼容。

    容器注册:Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。

    ☁️云原生介绍

    CNCF给出了云原生应用的三大特征:

    • 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。

    • 动态管理:通过集中式的编排调度系统来动态的管理和调度。

    • 面向微服务:明确服务间的依赖,互相解耦。

    云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构DevOps以容器为代表的敏捷基础架构组成。

    这边引用网上关于云原生所需要的能力和特征总结,如下图。

    640?wx_fmt=jpeg

    云原生所需要的能力和特征

    ☁️十二要素

    12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下:

    • 基准代码

    • 显式声明依赖关系

    • 在环境中存储配置

    • 把后端服务当作附加资源

    • 严格分离构建、发布和运行

    • 无状态进程

    • 通过端口绑定提供服务

    • 通过进程模型进行扩展

    • 快速启动和优雅终止

    • 开发环境与线上环境等价

    • 日志作为事件流

    • 管理进程

    另外,除了上述的12要素外,还有补充的三点跟API、认证授权和监控告警相关的要素。

    • API声明管理

    • 认证和授权

    • 监控与告警

    距离12原则的提出已有五年多,12原则的有些细节可能已经不那么跟得上时代,也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎么说,12原则依旧是业界最为系统的云原生应用开发指南

    ☁️容器化封装

    Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器,让其可以在任何安装了Docker的机器上运行,而不用关心底层操作系统。

    Docker可以解决虚拟机能够解决的问题,同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括:

    • 隔离应用依赖

    • 创建应用镜像并进行复制

    • 创建容易分发的即启即用的应用

    • 允许实例简单、快速地扩展

    • 测试应用并随后销毁它们

    自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下,使用Docker的好处越来越多。

    ☁️服务编排

    Kubernetes——让容器应用进入大规模工业生产。 这个总结确实很贴切。编排调度的开源组件还有 Kubernetes、Mesos和Docker Swarm

    Kubernetes是目前世界上关注度最高的开源项目,它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司,它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念,通过极其简易的安装,以及灵活的网络层对接方式,提供一站式的服务。

    Mesos则更善于构建一个可靠的平台,用以运行多任务关键工作负载,包括Docker容器、遗留应用程序(例如Java)和分布式数据服务(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用两级调度的架构,开发人员可以很方便的结合公司业务场景自定制MesosFramework。

    他们为云原生应用提供的强有力的编排和调度能力,它们是云平台上的分布式操作系统。在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos和Kubernetes的大战已经基本宣告结束,Kubernetes成为了无可争议的赢家。

    ☁️微服务架构

    传统的Web开发方式,一般被称为单体架构所有的功能打包在一个WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器里,包含了DO/DAO,Service,UI等所有逻辑。其架构如下图所示。

    640?wx_fmt=jpeg

    传统的单体架构

    单体架构进行演化升级之后,过渡到SOA架构,即面向服务架构。近几年微服务架构是最流行的架构风格,旨在通过将功能模块分解到各个独立的子系统中以实现解耦,它并没有一成不变的规定,而是需要根据业务来做设计。微服务架构是对SOA的传承,是SOA的具体实践方法。微服务架构中,每个微服务模块只是对简单、独立、明确的任务进行处理,通过REST API返回处理结果给外部。

    在微服务推广实践角度来看,微服务将整个系统进行拆分,拆分成更小的粒度,保持这些服务独立运行,应用容器化技术将微服务独立运行在容器中。过去设计架构时,是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求,服务控制模块至少包含服务的发布、注册、路由、代理功能。

    容器化的出现,一定程度上带动了微服务架构。架构演化从单体式应用到分布式,再从分布式架构到云原生架构,微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题


    640?wx_fmt=png

    Spring Cloud整体架构图

    从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件,包括:服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件

    640?wx_fmt=png

    Spring Cloud VS Kubernetes

    Spring Cloud和Kubernetes有很大的不同,Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点,而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点,而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。看起来各取所长,充分利用这两者的优势是自然而然的趋势了。

    ☁️小结

    技术架构的演变非常快,各种新的名词也是层出不穷。本文主要是对云原生的概述。云原生应用的三大特征:容器化封装、动态管理、面向微服务。首先由CNCF组织介绍了云原生的概念,然后分别对这三个特征进行详述。云原生架构是当下很火的讨论话题,是不同思想的集合,集目前各种热门技术之大成。

    ☁️云原生相关技术图谱

    ☁️CNCF 的云原生全景图

    ☁️云原生全景图的 4 层

    剥离掉所有单个的技术,仅查看类别(如下图)。

    图中有不同的“行”,像建筑的不同层,每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上,你可以开始添加运行和管理应用程序所需的工具,比如运行时和调度层。在最上层,有定义和开发应用程序的工具,比如数据库、镜像构建和 CI/CD 工具。

    ☁️供应层 (Provisioning)

    供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略,在应用程序和平台中构建身份验证和授权,以及处理密钥分发等等的工具,也拓展到了安全领域。

    供应层包括:

    • 自动化和部署工具: 帮助工程师在无需人工干预情况下即可构建计算环境;

    • 容器注册表: 存储应用程序的可执行文件;

    • 不同安全领域的安全和合规框架;

    • 密钥管理解决方案: 通过加密确保只有授权的用户才能访问特定的应用程序。

    这些工具使工程师可以编写基础设施参数,使系统可以按需搭建新环境,确保了一致性和安全性。

    ☁️运行时层(Runtime)

    接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样,运行时没有严格的定义,且可以根据语境有不同的用法。狭义上讲,运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲,运行时是运行一个应用程序所需的所有工具。

    在 CNCF 云原生全景图中,运行时保障了容器化应用程序组件的运行和通信, 包括:

    • 云原生存储: 为容器化应用提供虚拟磁盘或持久化存储;

    • 容器运行时: 为容器提供隔离、资源和安全;

    • 云网络: 分布式系统的节点(机器或进程)通过其连接和通信。

    ☁️编排和管理层(Orchestration and Management)

    一旦按照安全和合规性标准(供应层)自动化基础设施供应,并安装了应用程序运行所需的工具(运行时层),工程师就需要弄清楚如何编排和管理应用程序。

    编排和管理层将所有容器化服务(应用程序组件)作为一个群组管理。这些容器化服务需要相互识别和通信,并需要进行协调。这一层可为云原生应用提供自动化和弹性能力,使云原生应用天然具有可扩展性

    这一层包含:

    • 编排和调度: 部署和管理容器集群,确保它们具有弹性伸缩能力,相互之间低耦合,并且可扩展。事实上,编排工具(绝大多数情况下就是 Kubernetes)通过管理容器和操作环境构成了集群;

    • 协调和服务发现: 使得服务(应用程序组件)之间可以相互定位和通信;

    • 远程进程调用(RPC): 使跨节点服务间通信的技术;

    • 服务代理: 服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制,而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格(service mesh)至关重要。

    • API 网关: 一个抽象层,外部应用可通过 API 网关进行通信;

    • Service Mesh: 某种程度上类似于 API 网关,它是应用程序进行通信的专用基础架构层,提供基于策略的内部服务间通信。此外,它还可能包含流量加密、服务发现、应用程序监控等内容。

    ☁️应用定义和开发层 (Application Definition and Developement)

    现在,我们来到了最顶层。应用定义和开发层,顾名思义,聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境,以及提供全部所需的应用程序依赖。

    这一层包括:

    • 数据库: 使应用程序能以有序的方式收集数据;

    • 流和消息传递: 使应用程序能发送和接收消息(事件和流)。它不是网络层,而是让消息成为队列并处理消息的工具;

    • 应用程序定义和镜像构建: 用于配置、维护和运行容器镜像(应用程序的可执行文件)的服务;

    • 持续集成和持续交付(CI/CD): 使开发者可自动测试代码是否与代码库(应用程序的其余部分)兼容。如果团队足够成熟,甚至可以自动部署代码到生产环境。

    ☁️贯穿所有层的工具

    可观察性和分析(Observability&analysis)是监控各层的工具,平台则将各层中不同的技术捆绑为一个解决方案。

    ☁️可观察性和分析(Observability and Analysis)

    为了限制服务中断并降低解决问题的平均时间(MRRT),你需要监控和分析应用层序的方方面面,以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障,这些工具可快速识别并解决故障,从而降低故障带来的影响。由于这一类别贯穿并监控各层,因此它在侧面,而不是嵌入到某一层中。

    这这一类别你将发现:

    • 日志工具: 收集事件日志(有关进程的信息);

    • 监控方案: 收集指标(以数字表示的系统参数,例如 RAM 可用性);

    • 追踪工具: 追踪比监控更进了一步,它们监控用户请求的传播,与服务网格相关。

    • 混沌工程(Chaos Engineering): 在生产环境中测试软件的工具,可识别缺陷并进行修复,减少其对服务交付的影响。

    ☁️平台类(Platform)

    每一个模块解决一个特定的问题。仅有存储并不能提供应用程序所需的全部功能。还需要编排工具,容器运行时,服务发现,网络,API 网关等等。平台覆盖多层,将不同的工具组合在一起,以解决更大的问题。

    配置和微调不同的模块使其安全可靠,并确保它利用的技术都能及时更新、所有漏洞都打了补丁,这并不是一件容易的事情。使用平台时,用户不用额外担心这些细节问题。

    你可能会注意到,所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块,但它却是云原生技术栈的核心。顺便说一下,CNCF 刚创建时,Kubernetes 就是其中的第一个种子项目,后来才有了其他项目。

    平台可分为四类:

    • Kubernetes 发行版: 采用未经修改的开放源代码(尽管有人对其进行了修改),并根据市场需要增加了其他功能;

    • 托管的 Kubernetes: 类似于 Kubernetes 发行版,但是由提供商托管;

    • Kubernetes 安装程序: 自动执行 Kubernetes 的安装和配置过程;

    • PaaS/容器服务: 类似于托管的 Kubernetes,但是包含了一套更广泛的应用部署工具(通常是来自云原生景观图)。

    ☁️小结

    在选择技术栈时,工程师必须仔细考虑每种能力和需要权衡取舍的地方,以确定最合适的选项。
    虽然这样会让情况变得更复杂,但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时,这样做是最可行的办法。现在,构建一个系统比云原生之前的时代容易多了。如果构建恰当,云原生技术将提供更强大的灵活性

    参考文献

    云原生技术的前世今生
    关于云原生,这是最详细的技术知识
    云原生生态中的技术栈

    展开全文
  • 【阿里·原生架构·白皮书】 对白皮书的一些总结和解读。

    在这里插入图片描述

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

    👀专栏介绍

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

    👀本期介绍

    主要介绍云原生架构定义

    👀云原生架构定义

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

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

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

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

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

    🪂代码结构发生巨大变化

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

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

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

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

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

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

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

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

    🪂高度自动化的软件交付

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

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

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

    👀总结

    🪂云原生架构的特点

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

    🪂云原生架构的优势

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

    展开全文
  • 分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用与大规模,高并发场景下的 Web 访问问题。它 采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了...

     最新文章欢迎关注笔者公众号“畅游云海”

      《重识云原生系列》专题索引:

    1. 第一章——不谋全局不足以谋一域
    2. 第二章计算第1节——计算虚拟化技术总述
    3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
    4. 第二章计算第3节——主流虚拟化技术之Xen
    5. 第二章计算第4节——主流虚拟化技术之KVM
    6. 第二章计算第5节——商用云主机方案
    7. 第二章计算第6节——裸金属方案
    8. 第三章云存储第1节——分布式云存储总述
    9. 第三章云存储第2节——SPDK方案综述
    10. 第三章云存储第3节——Ceph统一存储方案
    11. 第三章云存储第4节——OpenStack Swift 对象存储方案
    12. 第三章云存储第5节——商用分布式云存储方案
    13. 第四章云网络第一节——云网络技术发展简述
    14. 第四章云网络4.2节——相关基础知识准备
    15. 第四章云网络4.3节——重要网络协议
    16. 第四章云网络4.3.1节——路由技术简述
    17. 第四章云网络4.3.2节——VLAN技术
    18. 第四章云网络4.3.3节——RIP协议
    19. 第四章云网络4.3.4节——OSPF协议
    20. 第四章云网络4.3.5节——EIGRP协议
    21. 第四章云网络4.3.6节——IS-IS协议
    22. 第四章云网络4.3.7节——BGP协议
    23. 第四章云网络4.3.7.2节——BGP协议概述
    24. 第四章云网络4.3.7.3节——BGP协议实现原理
    25. 第四章云网络4.3.7.4节——高级特性
    26. 第四章云网络4.3.7.5节——实操
    27. 第四章云网络4.3.7.6节——MP-BGP协议
    28. 第四章云网络4.3.8节——策略路由
    29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
    30. 第四章云网络4.3.10节——VXLAN技术
    31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
    32. 第四章云网络4.3.10.3节——VXLAN隧道机制
    33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
    34. 第四章云网络4.3.10.5节——VXlan组网架构
    35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
    36. 第四章云网络4.4节——Spine-Leaf网络架构
    37. 第四章云网络4.5节——大二层网络
    38. 第四章云网络4.6节——Underlay 和 Overlay概念
    39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
    40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
    41. 第四章云网络4.7.3节——Vhost-net方案
    42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
    43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
    44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
    45. 第四章云网络4.7.8节——SR-IOV方案
    46. 第四章云网络4.7.9节——NFV
    47. 第四章云网络4.8.1节——SDN总述
    48. 第四章云网络4.8.2.1节——OpenFlow概述
    49. 第四章云网络4.8.2.2节——OpenFlow协议详解
    50. 第四章云网络4.8.2.3节——OpenFlow运行机制
    51. 第四章云网络4.8.3.1节——Open vSwitch简介
    52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
    53. 第四章云网络4.8.4节——OpenStack与SDN的集成
    54. 第四章云网络4.8.5节——OpenDayLight
    55. 第四章云网络4.8.6节——Dragonflow
    56.  第四章云网络4.9.1节——网络卸载加速技术综述

    57. 第四章云网络4.9.2节——传统网络卸载技术

    58. 第四章云网络4.9.3.1节——DPDK技术综述

    59. 第四章云网络4.9.3.2节——DPDK原理详解

    60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

    61. 第四章云网络4.9.4.2节——智能网卡实现

    62. 第六章容器6.1.1节——容器综述

    63. 第六章容器6.1.2节——容器安装部署

            分布式云存储知识地图: 

    1 分布式存储发展简述

    1.1 存储发展简史

            在了解什么是分布式存储之前,我们先来简单了解一下存储几十年来的大概历程。

    • 直连存储(DAS):存储和服务器直连,拓展性、灵活性差。
    • 中心化存储(SAN、NAS):设备类型丰富,通过IP/FC网络互连,具有一定的拓展性,但是受到控制器能力限制,拓展能力有限。同时,设备到了生命周期要进行更换,数据迁移需要耗费大量的时间和精力。
    • 分布式存储:基于标准硬件和分布式架构,将数据分散存储到多个存储服务器上,并将这些分散的存储资源构成一个虚拟的存储设备,可实现千节点/EB级扩展,同时可以对块、对象、文件等多种类型存储统一管理。

            直连存储与中心化存储也可以统称为集中式存储。

    1.1.1 集中式存储简述

            集中式存储系统中,整个存储资源是集中在一个系统中的,但集中式存储并不是一个单独的设备,是集中在一套系统当中的多个设备,比如下图中的 EMC 存储就需要几个机柜来存放。

            在这个存储系统中包含很多组件,除了核心的机头(控制器)、磁盘阵列( JBOD )和交换机等设备外,还有管理设备等辅助设备。

            结构中包含一个机头,这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器,互为备用, 避免硬件故障导致整个存储系统的不可用。机头中通常包含前端端口和后端端口,前端端口用户为服务器提供存储服务,而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备,从而形成一个非常大的存储资源池。

            在整个结构中,机头中是整个存储系统的核心部件,整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理,将磁盘抽象化为存储资源池,然后划分为 LUN 提供给服务器使用。这里的 LUN 其实就是在服务器上看到的磁盘 。当然,一些集中式存储本身也是文件服务器,可以提供共享文件服务。无论如何,从上面我们可以看出集中式存储 最大的特点是有一个统一的入口,所有数据都要经过这个入口 ,这个入口就是存储系统的机头。这也就是集中式存储区别于分布式存储最显著的特点。如下图所示:

    1.1.2 分布式存储简述

            分布式存储最早是由谷歌提出的,其目的是通过廉价的服务器来提供使用与大规模,高并发场景下的 Web 访问问题。它 采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了系统的可靠性、可用性和存取效率,还易于扩展。

    1 、分布式存储的兴起

            分布式存储的兴起与互联网的发展密不可分,互联网公司由于其数据量大而资本积累少,而通常都使用大规模分布式存储系统。

            与传统的高端服务器、高端存储器和高端处理器不同的是,互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通 PC 服务器通过网络连接而成。其主要原因有以下三点:

    1. 互联网的业务发展很快,而且注意成本消耗,这就使得存储系统不能依靠传统的纵向扩展的方式,即先买小型机,不够时再买中型机,甚至大型机。互联网后端的分布式系统要求支持横向扩展,即通过增加普通 PC 服务器来提高系统的整体处理能力。
    2. 普通 PC 服务器性价比高,故障率也高,需要在软件层面实现自动容错,保证数据的一致性。
    3. 另外,随着服务器的不断加入,需要能够在软件层面实现自动负载均衡,使得系统的处理能力得到线性扩展。

    2 、分布式存储的重要性

            从单机单用户到单机多用户,再到现在的网络时代,应用系统发生了很多的变化。而分布式系统依然是目前很热门的讨论话题,那么,分布式系统给我们带来了什么,或者说是为什么要有分布式系统呢?

    1. 升级单机处理能力的性价比越来越低,企业发现通过更换硬件做垂直扩展的方式来提升性能会越来越不划算;
    2. 单机处理能力存在瓶颈,某个固定时间点,单颗处理器有自己的性能瓶颈,也就说即使愿意花更多的钱去买计算能力也买不到了;
    3. 出于稳定性和可用性的考虑,如果采用单击系统,那么在这台机器正常的时候一切 OK ,一旦出问题,那么系统就完全不能用了。当然,可以考虑做容灾备份等方案,而这些方案就会让系统演变为分布式系统了;
    4. 云存储和大数据发展的必然要求,云存储和大数据是构建在分布式存储之上的应用。移动终端的计算能力和存储空间有限,而且有在多个设备之间共享资源的强烈的需求,这就使得网盘、相册等云存储应用很快流行起来。然而,万变不离其宗,云存储的核心还是后端的大规模分布式存储系统。大数据则更近一步,不仅需要存储海量数据,还需要通过合适的计算框架或者工具对这些数据进行分析,抽取其中有价值的部分。如果没有分布式存储,便谈不上对大数据进行分析。仔细分析还会发现,分布式存储技术是互联网后端架构的神器,掌握了这项技能,以后理解其他技术的本质会变得非常容易。

    1.2 分布式存储整体架构总述

            分布式存储包含的种类繁多,除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外,还包括分布式数据库和分布式缓存等,但其中架构无外乎于三种:

    A、 中间控制节点架构

            以 HDFS ( Hadoop Distribution File System )为代表的架构是典型的代表。在这种架构中,一部分节点 NameNode 是存放管理数据(元数据),另一部分节点 DataNode 存放业务数据,这种类型的服务器负责管理具体数据。这种架构就像公司的层次组织架构, namenode 就如同老板,只管理下属的经理( datanode ),而下属的经理,而经理们来管理节点下本地盘上的数据。

            在上图中, 如果客户端需要从某个文件读取数据,首先从 NameNode 获取该文件的位置(具体在哪个 DataNode ),然后从该 NameNode 获取具体的数据。在该架构中 NameNode 通常是主备部署( Secondary NameNode ),而 DataNode 则是由大量节点构成一个集群。由于元数据的访问频度和访问量相对数据都要小很多,因此 NameNode 通常不会成为性能瓶颈,而 DataNode 集群中的数据可以有副本,既可以保证高可用性,可以分散客户端的请求。因此,通过这种分布式存储架构可以通过横向扩展 datanode 的数量来增加承载能力,也即实现了动态横向扩展的能力。

    B、 完全无中心架构 – 计算模式

            以 Ceph 为代表的架构是其典型的代表。在该架构中与 HDFS 不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系 计算出来 其写入数据的位置,这样客户端可以直接与存储节点通信,从而避免中心节点的性能瓶颈。

            如上图所示, 在 Ceph 存储系统架构中核心组件有 MON 服务、 OSD 服务和 MDS 服务等。

    (1) MON 服务用于维护存储系统的硬件逻辑关系,主要是服务器和硬盘等在线信息。MON 服务通过集群的方式保证其服务的可用性。

    (2) OSD 服务用于实现对磁盘的管理,实现真正的数据读写,通常一个磁盘对应一个 OSD 服务。

    (3) MDS 只为 CephFS 文件存储系统跟踪文件的层次机构和存储元数据。Ceph 块设备和 RADOS 并不需要元数据,因此也不需要 Ceph MDS 守护进程。

    (4) RADOS :RADOS 就是包含上述三种服务的 ceph 存储集群。在 Ceph 中所有的数据都以对象形式存在的,并且无论哪种数据类型 RADOS 对象存储都将负责保存这些对象。RADOS 层可以确保数据始终保持一致性。要做到这一点必须执行数据复制、故障检测和恢复,以及数据迁移和所在集群节点实现在平衡。

    (5) RBD (块设备):原名 RADOS 块设备,提供可靠的分布式和高性能块存储磁盘给客户端。

    (6) CephFS :Ceph 文件系统提供了一个使用 Ceph 存储集群存储用户数据的与 POSIX 兼容的文件系统。

    (7) Librados :libRADOS 库为 PHP 、 RUBY 、 Java 、 Python 、 C++ 等语言提供 了方便的访问 RADOS 接口的方式。

    (8) RADOS GW :RGW 提供对象存储服务,它允许应用程序和 Ceph 对象存储建立连接, RGW 提供了与 Amazon S3 和 openstack Swift 兼容的 RUSTFUL API。

            客户端访问存储的大致流程是,客户端在启动后会首先通过 RADOS GW 进入,从 MON 服务拉取存储资源布局信息,然后根据该布局信息和写入数据的名称等信息计算出期望数据的位置(包含具体的物理服务器信息和磁盘信息),然后和该位置信息对应的 CephFS 对应的位置直接通信,读取或者写入数据

    C、 完全无中心架构 – 一致性哈希

            以 swift 为代表的架构是其典型的代表。与 Ceph 的通过计算方式获得数据位置的方式不同,另外一种方式是通过一致性哈希的方式获得数据位置。一致性哈希的方式就是将设备做成一个哈希环,然后根据数据名称计算出的哈希值映射到哈希环的某个位置,从而实现数据的定位。

            Swift 中存在两种映射关系,对于一个文件,通过哈希算法( MD5 )找到对应的虚节点(一对一的映射关系),虚节点再通过映射关系( ring 文件中二维数组)找到对应的设备(多对多的映射关系),这样就完成了一个文件存储在设备上的映射。

    1.3 云上分布式存储简述

            分布式存储架构由三个部分组成:客户端、元数据服务器和数据服务器。客户端负责发送读写请求,缓存文件元数据和文件数据。元数据服务器负责管理元数据和处理客户端的请求,是整个系统的核心组件。数据服务器负责存放文件数据,保证数据的可用性和完整性。该架构的好处是性能和容量能够同时拓展,系统规模具有很强的伸缩性。

            分布式存储分为文件存储、对象存储块存储,但它们三种存储方式的基本架构都是大同小异的。即客户端或应用端、元数据(MDS)服务器和数据节点服务器。客户端和元数据服务器之间交互是“信令交互”,而客户端到数据节点是“媒体交互”。元数据服务器或通过数据节点服务器获取各节点服务器的基本配置情况和状态信息。

    1.3.1 块存储

            典型设备:磁盘阵列,硬盘

            块存储主要是将裸磁盘空间整个映射给主机使用的,就是说例如磁盘阵列里面有5块硬盘(为方便说明,假设每个硬盘1G),然后可以通过划逻辑盘、做Raid、或者LVM(逻辑卷)等种种方式逻辑划分出N个逻辑的硬盘。(假设划分完的逻辑盘也是5个,每个也是1G,但是这5个1G的逻辑盘已经于原来的5个物理硬盘意义完全不同了。例如第一个逻辑硬盘A里面,可能第一个200M是来自物理硬盘1,第二个200M是来自物理硬盘2,所以逻辑硬盘A是由多个物理硬盘逻辑虚构出来的硬盘。)

            接着块存储会采用映射的方式将这几个逻辑盘映射给主机,主机上面的操作系统会识别到有5块硬盘,但是操作系统是区分不出到底是逻辑还是物理的,它一概就认为只是5块裸的物理硬盘而已,跟直接拿一块物理硬盘挂载到操作系统没有区别的,至少操作系统感知上没有区别。

            此种方式下,操作系统还需要对挂载的裸硬盘进行分区、格式化后,才能使用,与平常主机内置硬盘的方式完全无异。

    优点:

    1. 这种方式的好处当然是因为通过了Raid与LVM等手段,对数据提供了保护。
    2. 另外也可以将多块廉价的硬盘组合起来,成为一个大容量的逻辑盘对外提供服务,提高了容量。
    3. 写入数据的时候,由于是多块磁盘组合出来的逻辑盘,所以几块磁盘可以并行写入的,提升了读写效率。
    4. 很多时候块存储采用SAN架构组网,传输速率以及封装协议的原因,使得传输速度与读写速率得到提升。

    缺点:

    1. 采用SAN架构组网时,需要额外为主机购买光纤通道卡,还要买光纤交换机,造价成本高。
    2. 主机之间的数据无法共享,在服务器不做集群的情况下,块存储裸盘映射给主机,再格式化使用后,对于主机来说相当于本地盘,那么主机A的本地盘根本不能给主机B去使用,无法共享数据。
    3. 不利于不同操作系统主机间的数据共享:另外一个原因是因为操作系统使用不同的文件系统,格式化完之后,不同文件系统间的数据是共享不了的。例如一台装了WIN7/XP,文件系统是FAT32/NTFS,而Linux是EXT4,EXT4是无法识别NTFS的文件系统的。就像一只NTFS格式的U盘,插进Linux的笔记本,根本无法识别出来。所以不利于文件共享。

    1.3.2 文件存储

    典型设备:FTP、NFS服务器

            为了克服上述文件无法共享的问题,所以有了文件存储。

            文件存储也有软硬一体化的设备,但是其实普通拿一台服务器/笔记本,只要装上合适的操作系统与软件,就可以架设FTP与NFS服务了,架上该类服务之后的服务器,就是文件存储的一种了。

            主机A可以直接对文件存储进行文件的上传下载,与块存储不同,主机A是不需要再对文件存储进行格式化的,因为文件管理功能已经由文件存储自己搞定了。

    优点:

    1. 造价交低:随便一台机器就可以了,另外普通以太网就可以,根本不需要专用的SAN网络,所以造价低。
    2. 方便文件共享:例如主机A(WIN7,NTFS文件系统),主机B(Linux,EXT4文件系统),想互拷一部电影,本来不行。加了个主机C(NFS服务器),然后可以先A拷到C,再C拷到B就OK了。

    缺点:

    1. 读写速率低,传输速率慢:以太网,上传下载速度较慢,另外所有读写都要1台服务器里面的硬盘来承担,相比起磁盘阵列动不动就几十上百块硬盘同时读写,速率慢了许多。

    1.3.3 对象存储

    典型设备:内置大容量硬盘的分布式服务器

            对象存储最常用的方案,就是多台服务器内置大容量硬盘,再装上对象存储软件,然后再额外搞几台服务作为管理节点,安装上对象存储管理软件。管理节点可以管理其他服务器对外提供读写访问功能。

            之所以出现了对象存储这种东西,是为了克服块存储与文件存储各自的缺点,发扬它俩各自的优点。简单来说块存储读写快,不利于共享,文件存储读写慢,利于共享。能否弄一个读写快,利 于共享的出来呢。于是就有了对象存储。

            首先,一个文件包含了了属性(术语叫metadata,元数据,例如该文件的大小、修改时间、存储路径等)以及内容(以下简称数据)。

            以往像FAT32这种文件系统,是直接将一份文件的数据与metadata一起存储的,存储过程先将文件按照文件系统的最小块大小来打散(如4M的文件,假设文件系统要求一个块4K,那么就将文件打散成为1000个小块),再写进硬盘里面,过程中没有区分数据/metadata的。而每个块最后会告知你下一个要读取的块的地址,然后一直这样顺序地按图索骥,最后完成整份文件的所有块的读取。

            这种情况下读写速率很慢,因为就算你有100个机械手臂在读写,但是由于你只有读取到第一个块,才能知道下一个块在哪里,其实相当于只能有1个机械手臂在实际工作。

            而对象存储则将元数据独立了出来,控制节点叫元数据服务器(服务器+对象存储管理软件),里面主要负责存储对象的属性(主要是对象的数据被打散存放到了那几台分布式服务器中的信息),而其他负责存储数据的分布式服务器叫做OSD,主要负责存储文件的数据部分。当用户访问对象,会先访问元数据服务器,元数据服务器只负责反馈对象存储在哪些OSD,假设反馈文件A存储在B、C、D三台OSD,那么用户就会再次直接访问3台OSD服务器去读取数据。

            这时候由于是3台OSD同时对外传输数据,所以传输的速度就加快了。当OSD服务器数量越多,这种读写速度的提升就越大,通过此种方式,实现了读写快的目的。

            另一方面,对象存储软件是有专门的文件系统的,所以OSD对外又相当于文件服务器,那么就不存在文件共享方面的困难了,也解决了文件共享方面的问题。

            所以对象存储的出现,很好地结合了块存储与文件存储的优点。

    1.3.4 块存储、对象和文件存储架构区别

    1.3.4.1 块存储

            块存储是一种裸设备,它是将存储设备以“块”的方式直接提供给客户,由客户自己的操作系统里的文件系统进行管理。

            华为的FusionStorage是一个典型的“块”存储。FusionStorage分成了MDC、OSD和Client三部分。和其他分布式存储重大的差别是:MDC是记录、更新OSD服务器、磁盘等的状态,并把这些状态数据实时同步给Vbs,由Vbs计算出来数据所落的位置。MDC可以单独部署,也可以集中部署,也可以分布部署。

            一般分布式存储的MDC采用的是数据库或内存储数据库来记录数据块和物理位置关系。客户端向MDC发出询问位置的请求,MDC查询数据库后返回请求数据的存储位置。

            这种方法存储访问的速度较慢,而且MDC作为交通的“枢纽”,绝对是整个存储的核心,当MDC发生故障,会导致整个存储都不能使用。但是采取这个方式,也有好处,比如可以根据不同需求设置不同的副本策略等。

    1.3.4.2 对象存储

            对象存储是在同样容量下提供的存储性能比文件存储更好,又能像文件存储一样有很好的共享性。实际使用中,性能不是对象存储最关注的问题,需要高性能可以用块存储,容量才是对象存储最关注的问题。

            所以对象存储的持久化层的硬盘数量更多,单盘的容量也更大。对象存储的数据的安全性保障也各式各样,可以是单机raid或网络raid,也可以副本。

            Ceph和google基于GFS的存储就是典型的对象存储。

    1.3.4.3 区别

            分布式块存储里是没有文件系统的,是通过客户端直接将最简单明了的命令传递给存储的“块”来执行。

            对象存储和文件存储虽然结构类似,但并不将存储底层的“块”直接提供出来,而是通过隐藏着一个文件系统,包装成为“文件”或“对象”提供出来。

            这些存储“不挑”操作系统或终端,最终执行命令的是存储里面的文件系统操控存储执行的,所以共享性很好。

            文件存储通过“目录+文件名+偏移量”来检索,文件间有目录层次的;

            而对象存储采用“唯一对象ID+偏移量”来检索,对象扁平存储的,是没有层次的。而且块、对象、文件存储是可以相互转换的。

    2 主流开源分布式存储方案概述

            在主流的分布式存储技术中,HDFS/GPFS/GFS属于文件存储,Swift属于对象存储,而Ceph可支持块存储、对象存储和文件存储,故称为统一存储。

    2.1 Ceph

            Ceph最早起源于Sage就读博士期间的工作、成果于2004年发表,并随后贡献给开源社区。经过多年的发展之后,已得到众多云计算和存储厂商的支持,成为应用最广泛的开源分布式存储平台。

            Ceph根据场景可分为对象存储、块设备存储和文件存储。Ceph相比其它分布式存储技术,其优势点在于:它不单是存储,同时还充分利用了存储节点上的计算能力,在存储每一个数据时,都会通过计算得出该数据存储的位置,尽量将数据分布均衡。同时,由于采用了CRUSH、HASH等算法,使得它不存在传统的单点故障,且随着规模的扩大,性能并不会受到影响。

    2.1.1 Ceph的主要架构

    • 基础存储系统RADOS

            Ceph的最底层是RADOS(分布式对象存储系统),它具有可靠、智能、分布式等特性,实现高可靠、高可拓展、高性能、高自动化等功能,并最终存储用户数据。RADOS系统主要由Ceph OSD、Ceph Monitors两部分组成,Ceph OSD 的功能是存储数据,处理数据的复制、恢复、回填、再均衡,并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。Ceph Monitor维护着展示集群状态的各种图表,包括监视器图、 OSD 图、归置组( PG )图、和 CRUSH 图。 

    • 基础库LIBRADOS

            LIBRADOS层的功能是对RADOS进行抽象和封装,并向上层提供API,以便直接基于RADOS进行应用开发。RADOS是一个对象存储系统,因此,LIBRADOS实现的API是针对对象存储功能的。物理上,LIBRADOS和基于其上开发的应用位于同一台机器,因而也被称为本地API。应用调用本机上的LIBRADOS API,再由后者通过socket与RADOS集群中的节点通信并完成各种操作。

    • 上层应用接口

            Ceph上层应用接口涵盖了RADOSGW(RADOS Gateway)、RBD(Reliable Block Device)和Ceph FS(Ceph File System),其中,RADOSGW和RBD是在LIBRADOS库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。

    • 应用层

            应用层就是不同场景下对于Ceph各个应用接口的各种应用方式,例如基于LIBRADOS直接开发的对象存储应用,基于RADOSGW开发的对象存储应用,基于RBD实现的云主机硬盘等。

    2.1.2 Ceph的功能模块

    • Client客户端:负责存储协议的接入,节点负载均衡。
    • MON监控服务:负责监控整个集群,维护集群的健康状态,维护展示集群状态的各种图表,如OSD Map、Monitor Map、PG Map和CRUSH Map。
    • MDS元数据服务:负责保存文件系统的元数据,管理目录结构。
    • OSD存储服务:主要功能是存储数据、复制数据、平衡数据、恢复数据,以及与其它OSD间进行心跳检查等。一般情况下一块硬盘对应一个OSD。

    2.1.3 Ceph的优点

    1.CRUSH算法

            CRUSH算法是ceph的两大创新之一,简单来说,ceph摒弃了传统的集中式存储元数据寻址的方案,转而使用CRUSH算法完成数据的寻址操作。采用CRUSH算法,数据分布均衡,并行度高,不需要维护固定的元数据结构。

    2.高可用

            Ceph中的数据副本数量可以由管理员自行定义,并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域,支持数据强一致性,适合读多写少场景;ceph可以忍受多种故障场景并自动尝试并行修复。

    3.高扩展性

            Ceph本身并没有主控节点,扩展起来比较容易,并且理论上,它的性能会随着磁盘数量的增加而线性增长。

    4.特性丰富

            Ceph支持对象存储、块存储和文件存储服务,故称为统一存储。

    2.1.4 Ceph的缺点

    1. 去中心化的分布式解决方案,需要提前做好规划设计,对技术团队的要求能力比较高。
    2. Ceph扩容时,由于其数据分布均衡的特性,会导致整个存储系统性能的下降。

     2.2 GFS

            GFS是google的分布式文件存储系统,是专为存储海量搜索数据而设计的,2003年提出,是闭源的分布式文件系统。适用于大量的顺序读取和顺序追加,如大文件的读写。注重大文件的持续稳定带宽,而不是单次读写的延迟。

    2.2.1 GFS的主要架构

            GFS 架构比较简单,一个 GFS 集群一般由一个 master 、多个 chunkserver 和多个 clients 组成。

            在 GFS 中,所有文件被切分成若干个 chunk,每个 chunk 拥有唯一不变的标识(在 chunk 创建时,由 master 负责分配),所有 chunk 都实际存储在 chunkserver 的磁盘上。

            为了容灾,每个 chunk 都会被复制到多个 chunkserve.

    2.2.2 GFS的功能模块

    • GFS client客户端:为应用提供API,与POSIX API类似。同时缓存从GFS master读取的元数据chunk信息;
    • GFS master元数据服务器:管理所有文件系统的元数据,包括命令空间(目录层级)、访问控制信息、文件到chunk的映射关系,chunk的位置等。同时 master 还管理系统范围内的各种活动,包括chunk 创建、复制、数据迁移、垃圾回收等;
    • GFS chunksever存储节点:用于所有 chunk的存储。一个文件被分割为多个大小固定的chunk(默认64M),每个chunk有全局唯一的chunk ID。

    2.2.3 GFS的写入流程

    1. Client 向 master 询问要修改的 chunk在哪个 chunkserver上,以及 该chunk 其他副本的位置信息。
    2. Master 将Primary、secondary的相关信息返回给 client。
    3. Client 将数据推送给 primary 和 secondary;
    4. 当所有副本都确认收到数据后,client 发送写请求给 primary,primary 给不同 client 的操作分配序号,保证操作顺序执行。
    5. Primary 把写请求发送到 secondary,secondary 按照 primary 分配的序号顺序执行所有操作
    6. 当 Secondary 执行完后回复 primary 执行结果。
    7. Primary 回复 client 执行结果。

            由上述可见,GFS在进行写数据时,有如下特点:

    • GFS在数据读写时,数据流与控制流是分开的,并通过租约机制,在跨多个副本的数据写入中, 保障顺序一致性;
    • Master将chunk租约发放给其中一个副本,这个副本称为主副本,由主副本确定chunk的写入顺序,次副本则遵守这个顺序,这样就保障了全局顺序一致性
    • Master返回客户端主副本和次副本的位置信息,客户端缓存这些信息以备将来使用,只有当主副本所在chunkserver不可用或返回租约过期了,客户端才需要再次联系Master;
    • GFS采用链式推送,以最大化利用每个机器的网络带宽,避免网络瓶颈和高延迟连接,最小化推送延迟;
    • GFS使用TCP流式传输数据,以最小化延迟。

    2.2.4 GFS特点

    • 适合大文件场景的应用,特别是针对GB级别的大文件,适用于数据访问延时不敏感的搜索类业务
    • 中心化架构,只有1个master处于active状态
    • 缓存和预取,通过在client端缓存元数据,尽量减少与master的交互,通过文件的预读取来提升并发性能
    • 高可靠性,master需要持久化的数据会通过操作日志与checkpoint的方式存放多份,故障后master会自动切换重启。

    2.3 HDFS

            HDFS(Hadoop Distributed File System),是一个适合运行在通用硬件(commodity hardware)上的分布式文件系统,是Hadoop的核心子项目,是基于流数据模式访问和处理超大文件的需求而开发的。该系统仿效了谷歌文件系统(GFS),是GFS的一个简化和开源版本。

    2.3.1 HDFS的主要架构

    • HDFS Client(客户端):从NameNode获取文件的位置信息,再从DataNode读取或者写入数据。此外,client在数据存储时,负责文件的分割;
    • NameNode(元数据节点):管理名称空间、数据块(Block)映射信息、配置副本策略、处理客户端读写请求;
    • DataNode(存储节点):负责执行实际的读写操作,存储实际的数据块,同一个数据块会被存储在多个DataNode上
    • Secondary NameNode:定期合并元数据,推送给NameNode,在紧急情况下,可辅助NameNode的HA恢复。

    2.3.2 HDFS的特点(Vs GFS)

    • 分块更大,每个数据块默认128MB;
    • 不支持并发,同一时刻只允许一个写入者或追加者;
    • 过程一致性,写入数据的传输顺序与最终写入顺序一致;
    • Master HA,2.X版本支持两个NameNode,(分别处于Active和Standby状态),故障切换时间一般几十秒到数分钟;

    2.3.3 HDFS适合的应用场景

    • 适用于大文件、大数据处理,处理数据达到 GB、TB、甚至PB级别的数据。
    • 适合流式文件访问,一次写入,多次读取。
    • 文件一旦写入不能修改,只能追加。

    2.3.4 HDFS不适合的场景

    • 低延时数据访问;
    • 小文件存储;
    • 并发写入、文件随机修改;

    2.4 OpenStack Swift

            Swift 最初是由Rackspace公司开发的分布式对象存储服务, 2010 年贡献给 OpenStack 开源社区。作为其最初的核心子项目之一,为其 Nova 子项目提供虚机镜像存储服务。

    2.4.1 Swift的主要架构

            Swift 采用完全对称、面向资源的分布式系统架构设计,所有组件都可扩展,避免因单点失效而影响整个系统的可用性。

     Swift 组件包括:

    • 代理服务(Proxy Server):对外提供对象服务 API,转发请求至相应的账户、容器或对象服务
    • 认证服务(Authentication Server):验证用户的身份信息,并获得一个访问令牌(Token)
    • 缓存服务(Cache Server):缓存令牌,账户和容器信息,但不会缓存对象本身的数据
    • 账户服务(Account Server):提供账户元数据和统计信息,并维护所含容器列表的服务
    • 容器服务(Container Server):提供容器元数据和统计信息,并维护所含对象列表的服务
    • 对象服务(Object Server):提供对象元数据和内容服务,每个对象会以文件存储在文件系统中
    • 复制服务(Replicator):检测本地副本和远程副本是否一致,采用推式(Push)更新远程副本
    • 更新服务(Updater):对象内容的更新
    • 审计服务(Auditor):检查对象、容器和账户的完整性,如果发现错误,文件将被隔离
    • 账户清理服务(Account Reaper):移除被标记为删除的账户,删除其所包含的所有容器和对象

    2.4.2 Swift的数据模型

            Swift的数据模型采用层次结构,共设三层:Account/Container/Object(即账户/容器/对象),每层节点数均没有限制,可以任意扩展。数据模型如下:

    2.4.3 一致性散列函数

            Swift是基于一致性散列技术,通过计算将对象均匀分布到虚拟空间的虚拟节点上,在增加或删除节点时可大大减少需移动的数据量;

            为便于高效的移位操作,虚拟空间大小通常采用 2 n;通过独特的数据结构 Ring(环),再将虚拟节点映射到实际的物理存储设备上,完成寻址过程。如下图所示:

            散列空间4 个字节(32为),虚拟节点数最大为232,如将散列结果右移 m 位,可产生 2(32-m)个虚拟节点,(如上图中所示,当m=29 时,可产生 8 个虚拟节点)。

    2.4.4 环的数据结构

            Swift为账户、容器和对象分别定义了的环。

            环是为了将虚拟节点(分区)映射到一组物理存储设备上,并提供一定的冗余度而设计的,环的数据信息包括存储设备列表和设备信息、分区到设备的映射关系、计算分区号的位移(即上图中的m)。

            账户、容器和对象的寻址过程。(以对象的寻址过程为例):

    1. 以对象的层次结构 account/container/object 作为键,采用 MD5 散列算法得到一个散列值;
    2. 对该散列值的前 4 个字节进行右移操作(右移m位),得到分区索引号;
    3. 在分区到设备映射表里,按照分区索引号,查找该对象所在分区对应的所有物理设备编号。如下图:

    2.4.5 Swift的一致性设计

    Swift 采用 Quorum 仲裁协议

    • 定义:N:数据的副本总数;W:写操作被确认接受的副本数量;R:读操作的副本数量
    • 强一致性:R+W>N, 就能保证对副本的读写操作会产生交集,从而保证可以读取到最新版本;
    • 弱一致性:R+W<=N,读写操作的副本集合可能不产生交集,此时就可能会读到脏数据;

            Swift 默认配置是N=3,W=2,R=2,即每个对象会存在 3 个副本,至少需要更新 2 个副本才算写成功;如果读到的2个数据存在不一致,则通过检测和复制协议来完成数据同步。

            如R=1,就可能会读到脏数据,此时,通过牺牲一定的一致性,可提高读取速度,(而一致性可以通过后台的方式完成同步,从而保证数据的最终一致性)

            Quorum 协议示例如下所示:

    2.4.6 Swift特点

    • 原生的对象存储,不支持实时的文件读写、编辑功能
    • 完全对称架构,无主节点,无单点故障,易于大规模扩展,性能容量线性增长
    • 数据实现最终一致性,不需要所有副本写入即可返回,读取数据时需要进行数据副本的校验
    • 是OpenStack的子项目之一,适合云环境的部署
    • Swift的对象存储与Ceph提供的对象存储区别:客户端在访问对象存储系统服务时,Swift要求客户端必须访问Swift网关才能获得数据。而Ceph可以在每个存储节点上的OSD(对象存储设备)获取数据信息; 在数据一致性方面,Swift的数据是最终一致,而Ceph是始终跨集群强一致性)

    2.5 Lustre分布式存储

            Lustre是基于Linux平台的开源集群(并行)文件系统,最早在1999年由皮特•布拉姆创建的集群文件系统公司(Cluster File Systems Inc.)开始研发,后由HP、Intel、Cluster File System和美国能源部联合开发,2003年正式开源,主要用于HPC超算领域。

    2.5.1 Lustre的主要架构

    Lustre组件包括:

    • 管理服务器(MGS):存放集群中所有Lustre文件系统的配置信息,Lustre客户通过联系MGS获取信息,可以与MDS共享存储空间
    • 元数据服务器(MDS): 管理存储在MDT中的元数据,使存储在一个或多个MDT中的元数据可供Lustre客户端使用,每个MDS可管理一个或多个MDT。
    • 元数据目标(MDT): MDS用于存储元数据(例如文件名,目录,权限和文件布局),一个MDT可用于多个MDS,但一次只能有一个MDS访问
    • 对象存储服务器(OSS):为一个或多个本地OST提供文件I / O服务和网络请求处理, 通常,OSS服务于两个到八个OST
    • 对象存储目标(OST):用户文件数据存储在一个或多个对象中,每个对象位于单独OST中
    • Lustre客户端:运行Lustre客户端软件的计算节点,可挂载Lustre文件系统。客户端软件包括一个管理客户端(MGC),一个元数据客户端(MDC)和多个对象存储客户端(OSC)。每个OSC对应于文件系统中的一个OST。
    • 逻辑对象卷(LOV)通过聚合OSC以提供对所有OST的透明访问,逻辑元数据卷(LMV)通过聚合MDC提供一种对所有MDT透明的访问。

    2.5.2 Lustre特点

    • 支持数万个客户端系统,支持PB级存储容量,单个文件最大支持320TB容量
    • 支持RDMA网络,大文件读写分片优化,多个OSS能获得更高的聚合带宽
    • 缺少副本机制,存在单点故障。如果一个客户端或节点发生故障,存储在该节点上的数据在重新启动前将不可访问
    • 适用高性能计算HPC领域,适用于大文件连续读写。

    2.6 主流分布式存储技术的比较

            几种主流分布式存储技术的特点比较如下:

             此外,根据分布式存储系统的设计理念,其软件和硬件解耦,分布式存储的许多功能,包括可靠性和性能增强都由软件提供,因此大家往往会认为底层硬件已不再重要。但事实往往并非如此,我们在进行分布式存储系统集成时,除考虑选用合适的分布式存储技术以外,还需考虑底层硬件的兼容性。一般而言,分布式存储系统的产品有三种形态:软硬件一体机、硬件OEM和软件+标准硬件,大家在选择时,需根据产品的成熟度、风险规避、运维要求等,结合自身的技术力量等,选择合适的产品形态。

    3 参考链接

    主流分布式存储技术的对比分析与应用 - fanyqing - twt企业IT交流平台

    一文看懂分布式存储架构,这篇分析值得收藏-51CTO.COM

    分布式存储主流框架 - 知乎

    架构设计:系统存储(1)——块存储方案(1)_说好不能打脸的博客-CSDN博客_存储方案

    Longhorn 云原生分布式块存储解决方案设计架构和概念

    Longhorn 云原生分布式块存储解决方案设计架构和概念 - 为少 - 博客园

    Ceph的整体架构介绍,这篇文章带入Ceph的大门

    Ceph介绍及原理架构分享 - 简书

    分布式存储架构_百度百科

    Ceph介绍(一):基本原理_Yannick_J的博客-CSDN博客_ceph

    Openstack Swift 原理、架构与API介绍_HeyManLeader的博客-CSDN博客_swift架构

    OpenStack Swift学习笔记_i_chips的博客-CSDN博客_openstack swift

    OpenStack对象存储:Swift架构详解_西门仙忍的博客-CSDN博客_对象存储swift架构

    展开全文
  • 在3月2日的阿里开源 Polar...主要分享了存储计算分离架构、HTAP架构、节点高可用架构是PolarDB 可支持的三种架构,PolarDB还具备可用性、高性能、安全的企业级特性。并对PolarDB 总体架构和企业级特性进行展开分析。
  • 桌面架构纵横

    千次阅读 2019-02-27 14:11:18
    本文作者:张瑞鑫先生(资深云计算专家) ... 今天我们讲的是一篇关于桌面架构技术的知识,希望给大家带来帮助! 计算模式 看桌面计算模式,了解从用户类型如何到...桌面三种架构(VDI IDV VOI) 1、VDI架构 ...
  • 磁盘驱动器是讨论存储I/O路径的最终目的地,这里主要讨论两种磁盘驱动器:常规磁盘驱动器以及固态磁盘驱动器。常规磁盘驱动器即传统机械式磁盘驱动器,图是一个常规磁盘驱动器主要组件示意图。 固态驱动器(Solid ...
  • 阿里云技术架构3.地域和可用区三、云端实践1.杭州城市大脑2.12306网站3.天弘基金与余额宝 一、初识阿里 1.概述 阿里,阿里巴巴集团旗下云计算品牌,全球卓越的云计算技术和服务提供商(云计算及人工智能科技...
  • 深度解析阿里云存储

    万次阅读 2017-08-31 18:41:06
    图1 2017年Gartner全球云存储魔力象限图在去年首次进入Gartner魔力象限即取得了不错的位置之后,今年阿里云存储再次强势进入公共云存储魔力象限,紧跟Google成为公共云存储厂商中在利基象限中最接近领导者象限的公共...
  • 作者:从墨 随着企业的不断发展,企业产生大量的数据...在2019年HC大会上,华为重磅推出最新一代高扩展海量存储分布式数据库——TaurusDB,它拥有一个最大的特点就是将存储和计算以一分离的架构形式运行。很多人...
  • 在“云存储及灾备技术论坛”,百度资深架构师王耀介绍了百度的发展历程,并就百度云存储产品体系中的块存储与对象存储架构与特点进行了重点分享。 在BAT中,百度做公有比较晚,但在技术上却有很多创新。...
  • 【杂记】数据存储架构

    千次阅读 2022-02-24 10:19:44
    1. 存储架构分类 随着主机、磁盘、网络等技术的发展,对于承载大量数据存储的服务器来说,服务器内置存储空间,或者说内置磁盘往往不足以满足存储需要。因此,在内置存储之外,服务器需要采用外置存储的方式扩展...
  • 阿里基本概念与基础架构(一)

    万次阅读 多人点赞 2022-01-31 08:45:54
    是一思想,是按需付费的模式,这种模式提供了计算、存储、网络等资源,这些资源能够被快速提供。 如下图:需要依托于虚拟化技术才可以实现,由一组高配置的多个机器通过虚拟化技术形成一个逻辑上的资源池,这...
  • 分布式文件系统 -- OSS云存储

    千次阅读 多人点赞 2022-04-12 20:39:46
    OSS 云存储、应用场景、计费方式、基本概念、存储空间、对象、文件、地域、访问域名、访问秘钥、基本功能、外链地址、OSS防盗链、自定义域名、访问日志记录、权限控制、ACL、Bucket ACL、Objcet ACL、RAM Policy、...
  • 我们在上篇文章已经对比了不同的存储系统之间的区别,本章开始逐步深入记录Ceph的学习和运用。 开源分布式存储系统的对比 Ceph简介 Ceph是一个分布式存储系统,提供对象,块和文件存储,是一个免费开源软件的存储...
  • 平台的层次架构

    万次阅读 2019-03-19 15:03:04
    ​ 云计算是一资源的服务模式,该模式可以实现随时随地、便捷按需地从可配置计算资源共享池中获取所需的资源(如网络、服务器、存储、应用及服务),资源能够快速供应并释放,大大减少了资源管理工作开销。...
  • 文章目录前言 前言 本文整理自华为社区【内容共创】活动第14期。 查看活动详情:https://bbs.huaweicloud.com/blogs/336904 相关任务详情:任务16.企业核心业务未来架构演进路线及华为方案
  • 在云计算走向成熟之前,我们更应该关注系统云计算架构的细节,从传统的架构上大数据,实现了很多的转变。传统的大数据平台计算和数据一般都在一起,到上之后计算有可能是虚拟机、有可能是容器,存储和计算是...
  • 总结:原生架构理解

    千次阅读 2022-04-08 11:00:23
    一、 为什么需要原生架构?...应用的开发人员不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端(云存储,如对象存储,文件存储,块存储等)的问题,也不用处理当业务峰值到来时如何对存储节点进
  • 云存储相关技术及术语的探讨

    千次阅读 2019-01-03 12:52:35
    在经历计算浪潮和网络浪潮之后,数据存储技术已经发展成为信息领域的三大支撑技术之一。随着云计算、等信息技术的发展,异构数据源越来越多,数据量飞速增长,这就使得社会对数据存储的需求逐日攀升。同时,借力于大...
  • 阿里运维架构实践秘籍

    万次阅读 2021-12-07 10:31:47
    中国互联网发展编年史、 运维、 ...、缓存、 Session管理六策略、分库分表、迁移步骤、监控方案、运维的发展阶段、传统运维痛点、云服务供应商排行、黑客常见入侵步骤、架构阶段、云端运维安全、黑客常见系统层攻击
  • 原生架构是一创新的软件开发方法,专为充分利用云计算模型而设计。它使组织能够使用微服务架构将应用程序构建为松散耦合的服务,并在动态编排的平台上运行它们。因此,基于原生应用程序架构构建的应用程序是...
  • 物联网平台概念及系统架构

    千次阅读 2021-09-02 01:06:48
    物联网平台概念联动感知层和应用层的中枢系统,功能与价值凝聚的PaaS软件物联网平台是由物联网中间件这一概念逐步演进形成。简单而言,物联网平台是物联网平台与云计算的技术融合,是架设在...
  • 浅谈分布式存储架构: IPFS和HDFS

    千次阅读 2020-07-12 19:18:53
    分布式存储架构是一个复杂的系统工程,针对特定应用的数据存储有不同的系统架构解决方案。不同的存储方法会影响存储性能、存储成本、冗余度、工程复杂性等。 分布式存储的历史 分布式存储最早是由谷歌提出的,其...
  • 大数据、云计算和虚拟化等技术的出现,使得传统的 IT 架构难以满足企业日益增长的数据存储需求。为应对这一挑战,软件定义存储(SDS,Software Defined Storage)和超融合基础架构(HCI,Hyper-Converged ...
  • 1. 硬盘 HDD(普通云盘) 特征: 性能一般, IOPS大概在数百左右。 应用场景: 数据不被经常访问或者低I/O负载的应用场景,需要低成本并且有随机读写I/O的应用环境。 混合HDD(高效云盘) 特征: 结合HDD和SSD...
  • 02 去中心化存储的技术证明 去中心化存储目前分为无效和有效两种空间存储方案,Leo 同开发者们分享了几个商业存储赛道的代表性项目,如 IPFS+Filcoin 存储技术原理分析、FIL 存储证明等,总结了目前去中心化...
  • 这一架构不仅能很好的应对数据库化的需求,同时也可以通过层的分离,同时实现SQL更好的兼容以及底层存储的分布式拓展,极大拓展数据库的技术能力。 本次分享主题,就将从新一代分布式NewSQL数据库出发,介绍 ...
  • 1.1云存储技术的起源与发展

    千次阅读 2017-07-25 16:13:48
    1云存储技术的起源 存储是云计算技术的衍生品,是一新型网络的存储方式。那么探索云存储技术的起源,必将追溯至云计算技术的形成与发展,而云计算技术的出现又将追溯至计算机技术、存储技术、网络技术、...
  • 云计算的三形式 1.基础设施即服务 (IaaS) 基础设施即服务有时缩写为 IaaS,包含云 IT 的基本构建块,通常提供对联网功能、计算机(虚拟或专用硬件)以及数据存储空间的访问。基础设施即服务提供最高等级的灵活性和...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 358,705
精华内容 143,482
热门标签
关键字:

云存储技术的两种架构