精华内容
下载资源
问答
  • 云原生应用是什么意思
    千次阅读 多人点赞
    2022-02-25 17:20:28

    📋 个人简介

    • 💖 作者简介:大家好,我是阿牛😜

    • 📝 个人主页:馆主阿牛🔥

    • 🎉 支持我:点赞👍+收藏⭐️+留言📝

    • 💬格言:迄今所有人生都大写着失败,但不妨碍我继续向前!🔥


    请添加图片描述

    前言

    最近老是看到云原生这个概念,闲暇之余也去了解了一下!看了很多文章,对云原生的解释总是迷迷糊糊,看完云里雾里,经过博主的大量查阅,用我的理解总结一下。

    云原生的概念

    云原生(Cloud Native)是一个组合词。我们把它拆分为云和原生两个词来看。
    “云”即在线网络,我们都知道传统的应用都跑在本地服务器上,而本地部署的传统应用可能需要停机更新,且无法动态扩展等,而‘云’表示应用程序运行在分布式的云环境中,支持频繁变更,持续交付。
    ‘原生’表示应用程序在设计之初就考虑到了云平台的弹性和分布式特性,就是为云设计的。

    那么随着云原生的技术的不断发展,他的定义也在不断地迭代和更新,不同的社区和公司对云原生有着不同的理解和定义,感兴趣的可以去看一下云原生的发展历程。

    云原生的四大要点

    可以简单地把云原生理解为:云原生 = 微服务 + DevOps + 持续交付 + 容器化

    微服务

    微服务就是一种软件架构,使用微服务架构可以将一个大型的应用程序按照功能模块拆分成多个独立自治的微服务,每个微服务仅仅实现一种功能,具有很明确的边界。

    使用微服务架构能够为我们带来如下好处:
    1)服务的独立部署。
    每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。
    2)服务的快速启动。
    拆分之后服务启动的速度要比拆分之前快很多,因为依赖的库少了,代码量也少了。
    3)更加适合敏捷开发。
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布。
    4)职责专一,由专门的团队负责专门的服务。
    业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。
    5)服务可以动态按需扩容。
    当某个服务的访问量较大时,我们只需要将这个服务扩容即可。
    6)代码的复用。
    每个服务都提供 REST API,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。

    容器化

    容器技术是云原生的核心技术,容器是一种相对于虚拟机来说更加轻量的虚拟化技术。能为我们提供一种可移植、可重用的方式来打包、分发和运行程序。

    容器的基本思想就是将需要执行的所有软件打包到一个可执行程序包。例如,将一个 Java 虚拟机、 Tomcat 服务器以及应用程序本身打包进一个容器镜像。用户可以在基础设施环境中使用这个容器镜像启动容器并运行应用程序。

    而Docker是目前应用最为广泛的容器引擎,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,Docker和K8s都采用Go编写,(K8s全称Kubernetes,由首字母K,结尾字母s以及中间的8个字母组成,所以简称为K8s)。

    容器技术好处如下。

    • 应用程序的创建和部署过程更加敏捷:与虚拟机镜像相比,使用应用程序的容器镜像更简便和高效。
    • 可持续开发、集成和部署:借助容器镜像的不可变性,可以快速更新或回滚容器镜像版本,进行可靠且频繁的容器镜像构建和部署。
    • 提供环境一致性:标准化的容器镜像可以保证开发、测试和生产环境的一致性,不必为不同环境的细微差别而苦恼。
    • 提供应用程序的可移植性:标准化的容器镜像可以保证应用程序运行于 Ubuntu 、 CentOS 等各种操作系统或云环境下。
    • 为应用程序的松耦合架构提供基础设置:应用程序可以被分解成更小的独立组件,可以很方便地进行组合和分发。
    • 资源利用率更高。
    • 实现了资源隔离:容器应用程序与主机之间的隔离、容器应用程序之间的隔离可以为运行应用程序提供一定的安全保证。

    容器大大简化了云原生应用程序的分发和部署,可以说容器是云原生应用发展的基石。

    devops

    DevOps ( Development & Operations ,开发和运维)是软件开发人员和 IT 运维人员之间的合作过程,是一种工作环境、文化和实践的集合,目标是高效地自动执行软件交付和基础架构更改流程。开发和运维人员通过持续不断的沟通和协作,可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。

    云原生应用通常包含多个子功能组件,devops可以大大简化云原生应用从开发到交付的过程。实现了真正的价值交付。

    持续交付

    持续交付就是不误时开发,不停机更新,是一种软件开发方法,它利用自动化来加快新代码的发布。在持续交付流程中,开发人员对应用所做的更改可通过自动化被推送至代码存储库或容器镜像仓库。

    结语

    附上一张云原生图谱

    在这里插入图片描述

    欢迎各位参考与指导!!!

    更多相关内容
  • 迁移到云原生应用架构.pdf
  • 阿里云原生技术+云原生架构+云原生实践等资料合集,13份。 2021阿里巴巴DevOps实践手册 2021云原生开发者洞察白皮书 ...Knative 云原生应用开发指南 Serverless入门与实战 Spring Cloud Alibabab 从入门到实战
  • 该文档非常详细的介绍了云原生应用的专业体系知识,涵盖了云原生应用设计,云原生架构原则,云原生应用平台,云原生中间件,云原生应用软件交付流程,这几部分的核心内容。
  • Kubernetes中文指南_云原生应用架构实践手册(201910).pdf
  • 企业采用基于云原生的技术和管理方法,可以更好的把业务迁移到云平台,从而享受云的高效和按需资源能力,而容器云PaaS平台则是云原生应用重要的落地形态之一。企业在数字化转型中普遍面临IT系统架构缺乏弹性,
  • 2022阿里云原生应用交付与管理论坛资料汇总,共5份。 集群镜像重塑分布式应用交付 政采云私有化业务交付实践 Nacos2.0的k8s服务发现生态应用及规划 Open Cluster Management 开放模块化多集群管理平台 OpenKruise...
  • 什么云原生应用

    千次阅读 2021-02-02 09:28:35
    云原生定义# 云原生意味着应用程序原生就被设计为在云上以最佳方式运行。 云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥...但是当需要回答“什么云原生”这个问题时,还是会有些困难

    云原生定义#

    云原生意味着应用程序原生就被设计为在云上以最佳方式运行。

    云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥云计算的优势。这些应用的特点是可以实现快速和频繁的构建、发布、部署,结合云计算的特点实现和底层硬件和操作系统解耦,可以方便的满足在扩展性,可用性,可移植性等方面的要求,并提供更好的经济性。同时通过拆解为多个小型功能团队来让组织更敏捷,让人员、流程和工具更好的结合,在开发、测试、运维之间进行更密切的协作。

    但是当需要回答“什么是云原生”这个问题时,还是会有些困难:在过去几年间,云原生的定义一直在变化和发展演进,不同时期不同的公司对此的理解和诠释也不尽相同,因此往往会带来一些疑惑和误解。

    我们一起来看看云原生定义在不同时期的变化。

    Pivotal的定义#

    Pivotal 是Cloud Native/云原生应用的提出者,并推出了Pivotal Cloud Foundry和Spring系列开发框架,是云原生的先驱者和探路者。

    2015年,来自Pivotal公司的Matt Stine编写了一本名为 迁移到云原生应用架构 的电子书,提出云原生应用架构应该具备的几个主要特征:

    • 符合12因素应用(Twelve-Factor Applications)
    • 面向微服务架构(Microservices)
    • 自服务敏捷架构(Self-Service Agile Infrastructure)
    • 基于API的协作(API-Based Collaboration)
    • 抗脆弱性(Antifragility)

    在2017年10月,也是Matt Stine,在接受InfoQ采访时,则对云原生的定义做了小幅调整,将Cloud Native Architectures定义为具有以下六个特质:

    • 模块化(Modularity):(通过微服务)
    • 可观测性(Observability)
    • 可部署性(Deployability)
    • 可测试性(Testability)
    • 可处理性(Disposability)
    • 可替换性(Replaceability)

    而在Pivotal最新的官方网站 https://pivotal.io/cloud-native 上,对cloud native的介绍则是关注如下图所示的四个要点:

    https://skyao.io/learning-cloudnative/introduction/images/pivotal-cloud-native.png

    • DevOps
    • Continuous Delivery
    • Microservices
    • Containers

    CNCF的定义#

    2015年CNCF建立,开始围绕云原生的概念打造云原生生态体系,起初CNCF对云原生的定义包含以下三个方面:

    • 应用容器化(software stack to be Containerized)
    • 面向微服务架构(Microservices oriented)
    • 应用支持容器的编排调度(Dynamically Orchestrated)

    云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。援引宋净超同学的一张图片来描述云原生所需要的能力与特征:

    https://skyao.io/learning-cloudnative/introduction/images/cloud-native-definition-cncf-original.png

    在2018年,随着社区对云原生理念的广泛认可和云原生生态的不断扩大,还有CNCF项目和会员的大量增加,起初的定义已经不再适用,因此CNCF对云原生进行了重新定位。

    2018年6月,CNCF正式对外公布了更新之后的云原生的定义(包含中文版本)v1.0版本:

    Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。

    新的定义中,继续保持原有的核心内容:容器和微服务,但是非常特别的将服务网格单独列出来,而不是将服务网格作为微服务的一个子项或者实现模式,体现了云原生中服务网格这一个新生技术的重要性。而不可变基础设施和声明式API这两个设计指导理念的加入,则强调了这两个概念对云原生架构的影响和对未来发展的指导作用。

     

    可以通过访问 https://github.com/cncf/toc/blob/master/DEFINITION.md 查看。

    云原生定义之外#

    从上面可以看到,云原生的内容和具体形式随着时间的推移一直在变化,即便是CNCF最新推出的云原生定义也非常明确的标注为v1.0,相信未来我们很有机会看到v1.1、v2版本。而且云原生这个词汇最近被过度使用,混有各种营销色彩,容易发生偏离。因此,云原生的定义是什么并不重要,关键还是云原生定义后面的理念、文化、技术、工具、组织结构和行为方式。

    Joe Beda,Heptio 的CTO,指出:

    There is no hard and fast definition for what Cloud Native means. In fact there are other overlapping terms and ideologies. At its root, Cloud Native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity.Cloud Native并没有硬性和牢靠的定义。实际上,还有其他重叠的术语和意识形态。从根本上说,Cloud Native正在构建团队,文化和技术,以利用自动化和架构来管理复杂性和解锁速度。We are still at the beginning of this journey.我们还处在这个旅程的开始阶段。

    Christian Posta 指出:

    “Cloud native” is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that together make it economical to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.“云原生”是一个形容词,用于描述应用,结构,平台/基础设施和流程,这些共同促使我们以比较经济的工作方式来提高能力,实现快速响应变化和减少不可预测性。包括服务架构,自助服务基础设施,自动化,持续集成/交付管道,可观察性工具,实验的自由/责任,坚持结果而不是产出的团队等。

    在下一节,我们将深入分解云原生的理念和诉求,来看看云原生是通过什么方式来实现目标。

    参考资料#

    展开全文
  • 都在说云原生?到底什么云原生

    万次阅读 多人点赞 2022-04-10 13:03:43
    原来这就是云原生,还以为是有多么的高大上,还好还好,看完也不是那么难理解

    一、云原生是什么

    最近一直听到别人说云原生, 那什么是云原生呢?
    可以把云原生拆分为原生两部分。

    云,指的就是云服务器。
    在云服务器流行起来之前,我们都是通过自己购买物理服务器的方式把我们的项目部署起来的。我们需要购买物理机器,要向网络运行商购买公网IP服务,还要在公司找个地方放这些机器,作为服务器机房。
    在这里插入图片描述
    有了云服务器之后,公司不再需要购买物理设备了,我们想要上线部署自己的项目,只需要向云服务器提供商购买,就能拥有自己的服务器了,而云服务器和传统服务器相比,有很多传统服务器无法比拟的优点。比如弹性、分布式等等。
    在这里插入图片描述

    原生

    什么是原生呢?原生就是指土生土长。我们程序在开发设计的时候,在本地自建服务器运行和在云服务器运行,项目的架构设计等方面,都是完全不一样的。
    而原生,就是指,应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,要充分利用云上资源的优点,从而使我们的的应用更强大,更迅速、更稳定。
    在这里插入图片描述

    云+原生

    所以,云原生指的并不是某个技术,它更像是一个技术体系。
    就举个例子,云原生你不熟悉,那大数据总该熟悉了吧?而大数据,里面包括的Spark、Hadoop等技术。
    云原生也是这样,也是由一些我们经常熟知的技术所组成的。我们接着往下看。

    二、云原生四要素

    其实云原生概这个概念的提出来源于谷歌主导的一个基金会原原生计算基金会简称是CNCF。
    在这里插入图片描述
    CNCF在经过了好几代的更新之后,他给出了一个回答, 云原生的四要素包括:

    微服务

    几乎每个云原生的定义都包含微服务,跟微服务相对的是单体应用,微服务有理论基础,那就是康威定律,指导服务怎么切分,很玄乎,凡是能称为理论定律的都简单明白不了,不然就忒没b格,大概意思是组织架构决定产品形态,不知道跟马克思的生产关系影响生产力有无关系。微服务架构的好处就是按function切了之后,服务解耦,内聚更强,变更更易;另一个划分服务的技巧据说是依据DDD来搞。

    容器化

    Docker是应用最为广泛的容器引擎,在思科谷歌等公司的基础设施中大量使用,是基于LXC技术搞的,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,谷歌搞的,Docker和K8S都采用Go编写,都是好东西。

    DevOps

    这是个组合词,Dev+Ops,就是开发和运维合体,不像开发和产品,经常刀刃相见,实际上DevOps应该还包括测试,DevOps是一个敏捷思维,是一个沟通文化,也是组织形式,为云原生提供持续交付能力。

    持续交付

    持续交付是不误时开发,不停机更新,小步快跑,反传统瀑布式开发模型,这要求开发版本和稳定版本并存,其实需要很多流程和工具支撑。

    在这里插入图片描述

    这几个要素还是有点抽象啊。其实业界最有共识的,符合原原生架构的落地应用体系是采用k8s+docker进行容器化部署,基于微服务架构开发前后端完全分离的应用,提高灵活性和可维护性,借助敏捷迭代方法支持功能持续迭代完善的对方工具,支持上线发布自动化利用云平台设施实现弹性伸缩,动态调整,最优化资源利用率,这样的架构共建应用简便快捷,部署应用轻松自如,运行应用5G流量分布秒杀传统的为应用架构,吊打以往的IT建设模式,是整个互联网技术发展到今日的集大成体系.

    三、具体的云原生技术有哪些

    云原生技术有很多,大体可以分为以下5种:容器、服务网格、声明书API、不可变基础设施、微服务。

    在这里插入图片描述

    容器(Containers)

    容器化终端容器化封装是指以容器为基础,应用程序封装在容器之中,在容器里运行,实现资源的相对隔离与容器镜像的重复使用,因为使用的容器化技术应用运行于容器之中,就不需要考虑底层硬件的差异,这大大简化了开发的工作量,同时对于运维人员也极为友好,不需要再为环境问题而苦恼。使用到的技术包括Docker和k8s。

    微服务(Microservices)

    向微服务,面向微服务是指把一个大的功能应用拆分成一个个功能单一,相对独立,相互解耦的微应用。微应用之间通过接口进行通讯,使用的的微服务技术比如SpirngCloud

    服务网格(Service Meshes)

    服务网格(Service Mesh)是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中,它是一组和应用服务部署在一起的轻量级的网络代理,并且对应用服务透明。

    不可变基础设施(Immutable Infrastructure)

    不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。程序设计中不可变变量(Immutable Variable)就是在完成赋值后就不能发生更改,只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性,最基本的就是指运行服务的服务器在完成部署后,就不在进行更改。

    声明式API(Deciarative API)

    声明式 API是Kubernetes的技术点,它的核心原理,就是当用户向 Kubernetes 提交了一个 API 对象的描述之后,Kubernetes 会负责为你保证整个集群里各项资源的状态,都与你的 API 对象描述的需求相一致。更重要的是,这个保证是一项“无条件的”、“没有期限”的承诺:对于每个保存在 etcd 里的 API 对象,Kubernetes 都通过启动一种叫做“控制器模式”(Controller Pattern)的无限循环,不断检查,然后调谐,最后确保整个集群的状态与这个 API 对象的描述一致。简单理解就是对象的声明与对象的创建相解耦,在普通程序中创建对象需要向操作系统申请资源,相似的,在容器云平台上创建对象,需要向k8s申请资源。但k8s更进一步的是,你只需要提交一个申请单,然后由k8s系统完成对象的创建。

    这些技术只是云原生组成的一部分,但是,这些技术,我们自己机房服务器,也能使用,换句话来说,如果不是云环境,就算有了这些技术,这不是云原生,云原生,一定是基于云服务器的。

    四、云服务器相对传统物理服务器的优势

    为什么我们要使用云服务器而不自己搭建物理服务器呢?
    在这里插入图片描述

    云服务器具体优势如下:

    1.灵活性:云服务器采用虚拟化技术,整合了大量集群主机的计算、网络与存储资源,其CPU、内存、硬盘、带宽等资源都可以弹性扩容,按需取用;公司的项目,都有一个特点,就是访问量不是固定的,在做活动的时候,访问量会是日常流量的几倍,为了应对这种情况,如果是物理服务器,公司就必须随时准备能应对流量最高峰的物理设备,但在流量高峰过后,这些物理设备不能像云服务器那样释放,不灵活。

    2.安全稳定性**:基于集群服务器,云服务器拥有更强的主机性能,运行更安全、稳定;

    3.方便性:云服务器操作及升级更方便,传统服务器中的资源都是有限的,如果想要获得更好的技能,只能升级云服务器,所谓“云”,就是网络、互联网的意思,云服务器就是一种简单高效、安全可靠、处理能力可弹性伸缩的计算服务。其操作起来更加简便,如果原来使用的配置过低,完全可以在不重装系统的情况下升级CPU、硬盘、内存等,不会影响之前的使用;

    4.低成本:云服务器有更高的性价比,云服务器是按需付费的,与传统服务器相比,用多少买多少,而且并不会造成资源浪费,而传统物理服务器,必须准备满足流量高峰的设备数量。

    五、云原生的好处

    • 快速云原生架构使用敏捷开发和单位,不但可以让企业快速的进行开发,自动化的不做产品,同时还能持续地更新产品,让产品跟得上需求,甚至是引导需求,让企业立于不败之地。
    • 弹性扩展云原生架构天生具有云计算的特点,资源可以按需进行伸缩,这样不单提高资源的利用率,也大大降低了企业成本。
    • 强壮云原生架构依托于容器编排工去k8s与微服务的组合应用,就拥有了自动恢复能力,容错能力,故障隔离能力,让应用更强。
    • 屏蔽底层差异,因为使用的容器化技术应用运行于容器之中,就不需要考虑底层硬件的差异,这大大简化了开发的工作量,同时对于运维人员也极为友好,不需要再为环境问题而苦恼。

    六、总结

    说了这么多,你可以简单的理解为,云原生就是换了个开发环境,由物理服务器换到了云服务器,然后为了适应这个云服务器的环境做了一些技术架构调整,这就是云原生。

    展开全文
  • 通常,云原生应用程序构建为在Docker容器中运行的一组微服务,在Kubernetes中编排,并使用DevOps和Git Ops工作流进行管理和部署。使用Docker容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。...

    1 什么是云原生

    1.1 云原生起源

    云原生是一种软件开发方法,它充分利用了云计算,使用开源软件技术栈将应用程序部署为微服务。通常,云原生应用程序构建为在Docker容器中运行的一组微服务,在Kubernetes中编排,并使用DevOps和Git Ops工作流进行管理和部署。使用Docker容器的优点是能够将执行所需的所有软件及环境配置打包到一个可执行包中。容器在虚拟化环境中运行,从而将包含的应用程序与其环境隔离。

    ——维基百科“Cloud Native”

    信息技术的发展日新月异,过去几十年,企业IT架构经历了单体架构、分布式架构和云计算架构3个阶段的技术演进。尤其是云计算技术的发展,让企业的整个IT基础设施以及应用运行模式发生了革命性的改变。云时代的第一个十年,作为技术的创新探索先锋,互联网公司引领了云计算技术的发展趋势,大多数互联网应用从诞生之初就生长在云端。随着云计算技术的成熟,以及以移动互联网为特点的创新业务的驱动,很多传统行业(如金融、零售、能源、制造以及政务等领域)的企业和机构也逐渐将各自的业务从互联网数据中心(Internet Data Center,IDC)机房迁移至云上,充分利用云的弹性优势,实现系统的动态伸缩与业务的创新。

    企业应用上云,也经历了从云托管到云原生的架构演进过程。上云初始阶段,多数企业仅仅是把应用从传统的IDC机房搬迁到云上的虚拟机,这是云托管模式,或者叫作基础设施即服务(Infrastructure as a Service,IaaS)上云。但要真正用好云,不仅是基础设施和平台的升级,应用也需要摒弃传统的设计方法,从架构设计、开发方式到部署维护的整个软件生命周期管理,都要基于云的特点进行重构,从而构建“原生为云”而设计的应用,这样才能在云上以最优的架构、最佳的模式运行,并充分利用和发挥云平台的弹性以及分布式优势。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。作为诞生于云计算时代的新技术理念,云原生拥有传统IT无法比拟的优势,可帮助企业高效享受云的弹性和灵活性,以服务化的形态获取各种资源,降低大规模分布式高并发的技术门槛,从而实现快速开发、平滑迁移、稳定可靠、运维简便的应用构建模式。云原生已经成为云时代的新技术标准。

    云原生的概念最早是谁提出的,业界并没有统一的说法。比较有影响力的是Pivotal(Spring开源产品的母公司)的技术产品经理 Matt Stine,他在2015年发表的电子书Migrating to Cloud Native Application Architectures(《迁移到云原生应用架构》)中,提出了将传统的单体应用和面向服务的架构(Service-Oriented Architecture,SOA)应用迁移到云原生架构所需的文化、组织和技术变革。Matt Stine认为云原生是一组思想集合和最佳实践,包括敏捷基础设施(agile infrastructure)、微服务(microservice)、DevOps、持续交付(continuous delivery)等,主要涵盖如下重要的内容。

    (1)十二要素应用程序:云原生应用程序架构模式的集合。

    (2)微服务:独立部署的服务,每个服务只做一件事情。

    (3)敏捷基础设施:快速、可重复和一致地提供应用环境和后台服务的平台。

    (4)基于应用程序接口(Application Programming Interface,API)的协作:发布和版本化的API,允许在云原生应用程序架构中的服务之间进行交互。

    (5)抗压性:系统具备良好的健壮性,能够抵抗外界非预期的流量冲击。

    从狭义上来讲,云原生包含以容器、微服务、持续集成和持续发布(Continuous Integration/ Continuous Delivery,CI/CD)为代表的云原生技术,使用一种全新的方式来构建、部署、运维应用。它不但可以很好地支持互联网应用,也在深刻影响着新的IT技术架构和应用架构。

    从广义上来讲,云原生完全基于分布式云架构来设计开发应用系统,是全面使用云服务的构建软件。随着云计算技术的不断发展和丰富,很多用户对云的使用,不再是早期简单地租用云厂商基础设施(计算、存储、网络)等IaaS资源。

    云原生是当前炙手可热且不断发展的技术方向,其定义也会在日后不断演进。据IDC的市场研究数据和报告,截至2019年,超过三成的企业使用了包含 Docker 在内的容器技术,50%以上的企业认为运维自动化和弹性扩容是容器技术的主要应用场景。Gartner报告指出,到2022年,75%的全球化企业将在生产环境中使用云原生的容器化应用。

    2 企业为什么需要云原生

    云的核心理念是弹性,站在云的视角,过去我们常以虚拟化作为云平台和与客户系统交互的界面,为企业带来灵活性的同时也带来了一定的管理复杂度。容器的出现,在虚拟化的基础上向上封装了一层,逐步成为云平台和与客户系统交互的新界面之一,应用的构建、分发和交付得以在这个层面上实现标准化,大幅降低了企业 IT 实施和运维成本,提升了业务创新的效率。从技术发展的角度看:开源让云计算变得越来越标准化,容器已经成为企业应用分发和交付的标准,可以将应用与底层运行环境解耦;Kubernetes成为资源调度和编排的标准,屏蔽了底层架构的差异性,帮助应用平滑运行在不同的基础设施上;在此基础上建立上层应用抽象(如微服务和服务网格),逐步形成应用架构现代化演进的标准,开发者只需要关注自身的业务逻辑,无须关注底层实现。云原生正在通过方法论、工具集和理念重塑整个软件技术栈和生命周期,帮助企业和开发者在云上构建和运行可弹性扩展、容错性好、易于管理、便于观察的系统。有了诸多标准化的产品技术,企业上云的拐点已经到来,云原生已经成为释放云价值的最短路径之一。

    云并非把原先在物理服务器上运行的东西放到虚拟机里运行,真正的云化不仅是基础设施和平台的事情,应用也要改变传统的做法,实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术等都要做出改变,真正发挥云的弹性、动态调度、自动伸缩等一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多,如容器技术、微服务、可持续交付、DevOps等。

    1.业务复杂需要云原生

    PC的普及,改变了人们加工处理个人数据的方式;移动互联网的普及,改变了人们获取信息的方式;即将到来的万物互联的时代,改变了人们与周围世界的交互方式。随着业务的发展,企业IT架构也随之发生巨大变化,而业务又深度依赖IT能力。

    IT系统让人们的工作和生活越来越简单便捷的同时,其自身的架构却变得越来越复杂。随着技术的发展,业务规模的暴增,商业模式的创新,企业的应用系统也经历了单体应用、应用分层、分布式应用、云应用等不同应用形态。原来一个系统由一个团队就可以开发维护,慢慢发展到一个系统由数十个应用构成,需要几十个团队相互协作,甚至像淘宝、天猫这样的巨型系统,需要上千个应用,由几百个团队开发维护。微服务架构能够解决大型分布式系统的团队协作问题,每个团队独立负责一个或者若干个服务,团队对于所负责的服务拥有绝对的决策权,以减少组织的技术决策成本。服务之间通过契约化的接口以缩小沟通范围,只要接口不变,就无须关注外部的变化,从而减少组织的技术沟通成本。

    在微服务架构中,应用的数量大幅增加,性能、一致性等问题越来越严重,架构变得越来越复杂,大量服务的治理也变得充满挑战,如何处理和解决这些问题?正如人类社会发展伴随着技术革命与社会大分工一样,云原生技术的出现解耦了很多复杂性,这是IT技术的进步。

    (1)以Docker为代表的容器技术实现了应用与运行环境的解耦,众多业务应用负载可以被容器化,而且应用容器化满足了敏捷、可迁移、标准化的需求。

    (2)Kubernetes的出现实现了资源编排调度与底层基础设施的解耦,应用和资源的管控也开始得心应手,容器编排实现资源编排、高效调度。

    (3)以Istio为代表的服务网格技术实现了服务实现与服务治理能力的解耦。

    业务的发展能驱动技术的进步,技术的进步又反哺业务创新。云原生概念及技术提出几年以来,得到众多软件厂商以及云厂商的参与支持,他们也在纷纷贡献自己的产品与技术,绝大多数云厂商提供了容器、Kubernetes编排管理的OpenAPI、软件开发工具包(Software Development Kit,SDK)等丰富的开发工具,实现第三方被集成,为云的生态伙伴提供更多的可能性。这样的技术分层推动了社会分工,极大促进了云原生技术和云原生生态的发展。

    2.业务创新需要云原生

    互联网(尤其移动互联网)的蓬勃发展提高了业务的推广速度,云产品以及服务大幅降低了海量数据与高并发的技术门槛,二者共同作用,使业务的创新速度达到了前所未有的程度。每天有无数的新App产生。一个App从最初上线到日活跃用户过十万、百万、千万,可能只需要短短几个月的时间。我们正处在一个业务快速增长的时代,产品既需要更快的交付速度以便验证业务可行性,又需要更好的用户体验以便在众多的App中脱颖而出。这也是传统企业竞争不过互联网公司的原因。其中一个重要的因素是产品的进化速度太慢,不能根据用户的反馈快速迭代。当某个功能用户使用频率比较高时,产品的发展方向可能会随时发生转变,需要不断在市场中调整和演进产品的发展路线。万众创业的时代机会转瞬即逝,如果不能在第一时间抓住市场的热点,企业很快就会被市场淘汰。有研究数据表明:中国互联网企业的平均生命周期普遍在3~5年。“3年”成为划分一个企业生命周期的分界线。

    产品交付速度的提高不能以降低可用性为代价。我们知道,变更是可用性的“天敌”,以阿里巴巴为例,有统计数据表明,超过50%的线上故障是变更引起的,也正因如此,每逢重要的节假日或者大促活动节点,我们都会进行“封网”,以确保线上系统的稳定和可靠。当然这也是目前技术不够成熟,不得已而为之的折中和让步。就像目前很多传统企业的线上管理策略,提升可用性的一种方法就是少发布、多审核,这显然是和快速试错、快速交付、快速迭代的互联网思想背道而驰的。在传统行业中,企业的应用系统一般是有一个工作时间的,应用的发布和变更会选择在非工作时间进行。但在互联网行业中,尤其在全球化背景下,我们要求应用系统具有7×24小时不间断的在线服务能力,不存在非工作时间,甚至不存在业务低峰期,这就对企业的应用系统运维提出了更高的要求。云计算已经重塑了软件的整个生命周期,从架构设计到开发,再到构建、交付和运维等所有环节。云原生通过一系列产品、工具、方法减少变更导致的可用性问题,而不是因噎废食地控制变更、减少发布次数。

    互联网公司经常提到他们每天实现几十次,甚至上百次的发布。为什么频繁发布如此重要?如果你可以每天实现上百次发布,那么你就可以几乎立即从错误的版本中恢复过来;如果你可以立即从错误中恢复过来,那么你就能够承受更多的风险;如果你可以承受更多的风险,那么你就可以做更“疯狂”的试验——这些试验结果可能会成为你接下来的竞争优势。

    3.业务不确定性需要云原生

    云最主要的特性之一就是弹性,这也是企业应用上云最核心的需求。随着移动互联网的普及,以及网红经济、热门事件营销、秒杀大促等商业模式的推陈出新,企业的业务流量变得无法预估。当然,为了应对突发流量的冲击,企业也可以购买更多更高规格的服务器;但对于绝大部分业务平峰期以及低峰期, CPU都是空闲的,这会让资源使用率指标很低。通过云的弹性伸缩,可以应对业务突发流量的冲击,保证业务的平稳运行,提高资源利用率,降低IT运营成本。

    随着企业的应用系统进行分布式改造,应用由一个单体应用被分割为众多的微服务应用,整个应用集群的节点数由原来的数十个快速上升到了数百以至上千个,垂直拆分带来良好隔离性的同时,也使资源的利用率大幅下降。互联网公司通过以下两个开创性的举措来解决这个问题。

    (1)不再继续购买更大型的服务器,取而代之的是用大量更便宜机器来水平扩展应用实例。这些机器更容易获得,并且能够快速部署。

    (2)将大型服务器虚拟化成几个较小的服务器,并向其部署多个隔离的工作负载,从而改善现有大型服务器的资源利用率。

    纵观IT应用服务器的发展历史:大型机→小型机→x86服务器→虚拟机→容器→Serverless,越来越朝着轻量化的方向发展,这也符合云原生敏捷基础设施的策略。轻量化意味着更好的弹性,应用部署时间相应减少:月(大型机)→天(小型机)→小时(x86服务器)→分钟(虚拟机)→秒(容器)→毫秒(Serverless)。极致的弹性是企业解决业务不确定性的有效手段。

    云原生的核心技术之一是容器。容器技术的兴起源于2013年开源的Docker。容器的价值可以从下面两个层面阐述。

    (1)从应用架构层面,容器技术可以方便地支持微服务架构实现应用的无状态化,更加灵活地应对变化和弹性扩展。在软件生命周期管理方面,容器技术可以帮助把DevOps等最佳实践落地成可运用的标准化工具和框架,大大提升开发效率,加速迭代。DevOps的概念最早起源于2009年的欧洲(更早的20世纪90年代提出的柔性生产模式中也有DevOps的思想),但一直不温不火,直到Docker容器技术的流行,最近几年DevOps才为人们所津津乐道。

    (2)从基础架构层面,容器技术带来的可移植性,可以帮助开发者和企业更便捷地上云和迁云,让应用在自有数据中心和云端实现动态迁移。随着容器技术和云计算的计算、存储、网络的进一步融合,更快速地推动从传统以基础设施为中心,向以应用为中心的IT架构转变。

    容器解决了应用与运行环境的解耦,把运行环境也作为一种资源支持可编程式的管理;Kubernetes的出现则让资源的动态编排与管理变得更加简单,充分满足业务不确定对资源的弹性要求。

    综上所述,云原生不是一个产品,而是一套技术体系和一套方法论。企业数字化转型是思想先行,从内到外的整体变革,更确切地说,它是一种文化,更是一种潮流,是企业云计算战略的必然导向。

    3 云原生的设计原则

    顾名思义,云原生是面向“云”而设计的应用,但要给云原生下一个明确的定义很难,所有的架构的目标都是解决特定的业务场景。一方面,业务场景千变万化,而每个人的技术背景不同,站的角度不同,所理解和设计的系统架构也就各不相同。另一方面,架构总是不断演进的,新的技术层出不穷,因此云原生的落地形式与能力边界也在不断演进中。

    换一个思路,云原生所倡导的思想与设计原则,或许能更好地让大家理解什么是云原生,云原生具体解决哪一类问题。

    1.去中心化原则

    中心化意味着单点,为了具备良好的线性扩展能力,分布式系统要求去中心化,避免单点故障。对于系统的服务能力,随着资源加入,微服务的性能和容量能够呈线性扩展。在微服务场景下,每个服务可以独立采用自己的技术方案或技术栈,每个微服务应用独立部署,服务之间进程隔离,每个服务都有独立的数据库,一个服务实例的失效不会导致大规模的故障。这也是微服务架构和SOA非常重要的区别之一。SOA一般有一个中心化的企业服务总线(Enterprise Service Bus,ESB)负责所有服务的注册发现以及调用路由;微服务架构虽然也有一个服务注册中心,但服务注册中心只负责应用启动或者状态变更时做服务推送,真正在运行过程中微服务之间的相互调用都是点对点直接调用,即运行时是去中心化的。

    另外,从研发流程的角度来说,去中心化意味着关注点分离。云原生对开发团队一个很重要的要求是独立自主,每个服务由独立的团队负责开发运维,所有者的团队对服务具有决策权,可以自主选择技术栈以及研发进度,服务之间只要接口不变,外部就不必对其过度关注,更容易实现关注点分离。

    2.松耦合原则

    (1)实现的松耦合:这是基本的松耦合,即服务消费端不需要依赖服务契约的某个特定实现,这样服务提供端的内部变更就不会影响消费端,而且消费端未来还可以自由切换到该契约的其他服务提供方。

    (2)时间的松耦合:典型的是异步消息队列系统,由于有中介者(broker),因此生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量,而且生产者也不需要马上等到回复。

    (3)位置的松耦合:典型的是服务注册中心,消费端完全不需要直接知道提供服务端的具体位置,而都通过注册中心查找服务来访问。

    (4)版本的松耦合:消费端不需要依赖服务契约的某个特定版本来工作,这就要求服务的契约在升级时要尽可能地提供向下兼容性。

    3.面向失败设计原则

    为了保证系统的健壮性,软件设计领域中一个很重要的原则是,所有的外部输入和外部依赖都是不可信的,系统间依赖的调用随时可能会失败,也包括硬件基础设施服务随时可能死机,还有后端有状态服务的系统能力可能有瓶颈。总之在发生异常时能够快速失败,然后快速恢复,以保证业务永远在线,不能让业务半死不活地僵持着。

    面向失败设计(design for failure),意味着所有的外部调用都有容错处理,我们希望失败的结果是我们可预期的、经过设计的。在微服务架构场景中,当服务数量越来越多,依赖越来越复杂时,出现问题的概率也就越大,问题定位也会越来越困难,这时再用传统的解决办法将是一个灾难。传统的方法通常是通过重试、补偿等手段尽可能避免失败,微服务架构下由于存在更多的远程调用,任何外部依赖都有可能失效或延迟,这是潜在的故障和瓶颈。故障总是无法避免的,设计的目标是预测和解决这些故障。因此在设计服务时,应充分考虑异常情况,从使用者的角度出发,能够容忍故障的发生,最小化故障的影响范围。系统架构设计时需要考虑到应用系统的每一个层面,包括硬件和软件是可能出现故障的,并据此在应用系统架构设计上消除单一故障点,从而实现高可用性(High Availability,HA)的系统架构。

    4.无状态化原则

    云原生的应用服务设计尽可能是无状态的,使得业务天生具有扩展性,在业务流量高峰和低峰时期,依赖云的特性自动弹性扩容、缩容,满足业务需求。无状态指的是服务在处理请求时,不依赖除请求本身以外的其他内容,也不会有除响应请求之外的额外操作。这样如果要实现无状态服务的并行横向扩展,只需要对服务节点进行并行扩展,在服务之上添加一个负载均衡。

    将“有状态”的业务处理过程改造成“无状态”的过程,思路比较简单,主要有以下两种手段。

    (1)状态分离:服务端所有的状态信息统一保存在外部独立的分布式存储中(如缓存、消息队列、数据库)。

    (2)请求附带全部状态信息:将状态信息前置,丰富请求的入参,将需要处理的数据尽可能都通过上游的客户端放到入参中传过来。

    5.不变性原则

    容器技术带来的最大优势,是通过镜像实现了可编程式的运行环境定义,从而实现了应用与运行环境的解耦。作为一种服务(IaaS),云原生基础设施提供可编程式的需求描述,并实现记录版本变更,保证环境的一致性。使用软件工程中的原则、实践和工具来加强基础设施服务的生命周期管理,这意味着开发人员可以更频繁地构建更强可控或更稳定的基础设施。对资源调度而言,我们希望所有的服务(包括环境)无差异化配置,实现标准化可迁移,而不希望在部署任何服务的过程中还需要手动操作,因为手动操作是无法批量化、自动化执行的,也是不容易回溯的。

    实现不变性原则的前提是,基础设施中的每个服务、组件都可以自动安装、部署,不需要人工干预。所有的资源都可以随时拉起、随时释放,同时以API的方式提供弹性、按需的计算、存储能力。每个服务或者组件在安装部署完成后将不会发生更改,如果要更改,就丢弃老的服务或组件,并重新部署一个服务或组件。另外,为了提升可用性,我们应该尽量减少故障修复时间,要知道替换的速度远远快于修复的速度。

    6.自动化驱动原则

    为了满足业务需求的频繁变动,通过快速迭代,产品能做到随时可发布,这是一系列开发实践方法。自动化驱动分为持续集成、持续部署、持续交付等阶段,用来确保需求的提出、设计开发测试,再到代码快速、安全地部署到生产环境中。持续集成是指每当开发人员提交了一次改动,就立刻进行构建、自动化测试,确保业务应用和服务均能符合预期,从而可以确定新代码和原有代码能否正确地集成在一起。持续部署是指使用完全的自动化过程把每个变更自动提交到测试环境中,触发自动化测试用例,测试验证通过后将应用安全地部署到生产环境中,打通开发、测试、生产等各个环节。持续交付是软件发布的能力,在持续集成完成后,能够提供到预发布之类的环境上,满足生产环境的条件。

    应用系统的部署与运维的成本会随着服务的增多呈指数级增长,每个服务都需要部署、监控、日志分析等运维工作,成本会显著升高。在服务划分之前,应该首先构建自动化的工具及环境,开发、测试人员应该以自动化为驱动力,简化服务在创建、开发、测试、部署、运维上的重复性工作,尽可能通过自动化工具完成所有重复的工作。当提交代码后,自动化的工具链自动编译、构建、测试、集成。开发人员持续优化代码,当满足上线要求时,自动化部署到生产环境中。这种自动化的方式能够实现更可靠的操作,既避免了人为失误,又避免了微服务数量增多带来的开发、运维、管理的复杂化。

    云原生架构设计你需要有这样一本书:

    1.基于作者在阿里公司多年的大型项目架构设计实践经验,介绍云原生相关技术及产品
    2.内容深入浅出,既有方法论详述也有技术原理深入分析
    3.理论与实践并重,深入阐述云原生架构设计
    4.紧贴技术趋势,把握主流技术发展

    内容简介
    《企业级云原生架构:技术、服务与实践》较为全面、系统地介绍了云原生架构相关的方法论与技术产品,并结合作者多年的大型项目建设实施经验,阐述了分布式环境下面向云原生的架构设计最佳实践。本书主要分为4个部分,分别是云原生概述、云原生技术、云原生服务、云原生架构实践。本书兼顾理论、技术与实践,对从事相关行业的读者具有很好的学习指导意义。

    《企业级云原生架构:技术、服务与实践》面向的读者对象为互联网行业的业务咨询师、系统架构师,以及相关领域的技术开发人员。

    展开全文
  • 云原生从字面意思上来看可以分成云和原生两个部分。 云是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS,、PaaS和SaaS。 原生就是土生土长的意思,我们在开始设计应用的...
  • 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过CloudProvider、CRDController、Operator等等的方式从Kubernetes...
  • 原生云应用 企业创新路1
  • 云原生2.0白皮书.pdf

    2021-11-26 21:58:05
    一句话来讲,云原生,基于云构建企业应用系统的技术方法体系,快速响应业务需求、支撑微服务应用的敏捷方式。 回顾云原生发展历程不难看到,云原生的初衷是解决复杂系统快速迭代与稳定运行的问题,并且,互联网、...
  • 快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;
  • Rainbond 是云原生且易用的云原生应用管理平台,云原生应用交付的最佳实践,简单易用。专注于以应用为中心的理念。赋能企业搭建云原生开发云、云原生交付云。 对于企业: Rainbond 是开箱即用的云原生平台,借助 ...
  • 基于Istio on Kubernetes云原生应用的最佳实践
  • 《Knative 云原生应用开发指南》
  • 云原生应用的12要素

    2021-02-23 22:40:04
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生,而针对云原生应用开发的最佳实践原则,12-Factor脱颖而出,同时也带来了新的解读。12-Factor,...
  • 2022云原生——云原生应用调研.pdf
  • 为了能够给大家尽可能说出云原生是个什么东西,我读了很多很多文章,拜访了很多名家,包括业界的知名大佬、年薪千万的骨灰级专家、名下数十万记学生的成功学大师,真是生怕自己才疏学浅耽误了大家,所以我希望大家能...
  • 自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注...Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础设施分心,把更多的精力投入到业务逻辑上。
  • DevOps流程和工具链作为云原生的核心特征,让云网融合应用可以敏捷迭代和部署,用持续交付的高质量应用实现商业价值。以通信运营商的视角,从敏捷流程转型、敏捷交付关键技术、DevOps平台建设3方面,给出云原生环境...
  • 本课程从云原生时代大背景下分析应用上云带来的的优势与对业务开发人员带来的挑战,从而说明构建业务-应用服务上云知识库的重要性与必要性;主要根据知识库建设的通用性原理,从知识生产到消费再到知识再生产的完整...
  • 云原生应用配置代码化实践.pdf 从 Fluentbit-operator 到Fluent-operator.pdf 基于KubeSphere的分级管理实践.pdf 开源 DevOps 工具链整合可以更简单.pdf 镜像构建技术 Buildpacks 的原理及在 FaaS 平台中的实践.pdf
  • 下面将从云计算的发展历程引入云原生计算,请先看下图:云计算包含的内容十分繁杂,也有很多技术和公司牵强赴会说自己是云计算公司,说自己是做云的,实际上可能风马牛不相及。说白了,云计算就是一种配置资源的方式...
  • 云原生应用的概念和云原生应用的 15 个特征

    千次阅读 多人点赞 2022-06-12 20:53:14
    微服务架构只是一种软件架构风格,并不限制所采用的实现技术,开发团队可以自由选择最合适的技术来实现。微服务架构实现最大的挑战是它的复杂度,这些...云原生(Cloud Native)应用就是微服务架构的最佳实现方式。...
  • 基于 Kubernetes 与 OAM 构建统一而强大的云原生应用引擎 分布式追踪不是银弹 从架构设计到代码 三、微服务开源专场 Sentinel 微服务高可用容错最佳实践 Dubbo3.0-开启下一代云原生微服务 云原生微服务下混沌工程...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 105,891
精华内容 42,356
热门标签
关键字:

云原生应用是什么意思