精华内容
下载资源
问答
  • 原生的不同解释及正确含义

    千次阅读 2019-12-12 19:28:00
    原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。 云原生起源 网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”...

    云原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。

    云原生起源

    网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”。我搜索了英文“CloudNative”,阅读了首页的所有文章,里面没有一篇提到“Matt Stine首次提出云原生”,但它们每一篇都提到了“云原生计算基金会”的定义。“Matt Stine”确实写了一本书,叫《迁移到云原生架构》,他以前确实在Pivotal公司工作,但说他“首次提出云原生(CloudNative)的概念”应该是不准确的, 而且他的定义和云原生的含义是有一定偏差的。

    我觉得比较接近的说法是Netflix公司首创了云原生,详见Going Cloud Native: 6 essential things you need to know

    虽然那篇文章主要是讲的Netflix如何开创了微服务,但Netflix的微服务是部署在亚马逊云上的。而当时亚马逊云也才刚起步,各方面都不成熟,Netflix是它的最大客户。是Netflix的层出不穷的需求帮助亚马逊云不断完善它的功能和性能,最终登顶云服务商。因此Netflix的微服务演进是和云计算交织在一起,共同推进的。Netflix在微服务领域的开创和领先地位是大家公认的,它的“Netflix OOS”系列工具至今仍被广泛使用,特别是Java社区,并被移植到其他语言。在这个过程中,也同时开创了云计算的先河,它的起点是2009年。详情请见Goto Berlin - Migrating to Microservices (Fast Delivery)

    但我想说的是云计算(Cloud)和云原生(Cloud Native)还是有很大区别的。Netflix是云计算的开拓者,但并不是云原生的创造者。云原生的基石是k8s,没有k8s就没有云原生, 而k8s的1.0版诞生于2015年。云原生计算基金会(CNCF)也诞生于2015年并致力于推动云原生的发展。云原生的概念是在2017才开始被广泛接受和流行,因此云原生和云计算是由本质区别的。云原生的诞生是和云原生计算基金会密切相关的。

    云原生计算基金会(CNCF)的定义:

    下面就让我们看一下CNCF给出的云原生的定义:

    “云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
    云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。”

    摘要来源:CNCF Cloud Native Definition v1.0

    这个定义还是比较靠谱的,尽管它并不严谨,也并没有挖掘出云原生的本质。但考虑到每个组织的目的和立场不同,看问题的角度不同,CNCF的主要目的是培育云原生工具市场,因此它的定义带有很重的实用色彩,偏重工具方面。若是从这个角度看,这个定义还是比较贴切的。我觉得唯一不严谨的地方是把微服务列了进去,其他的都没什么问题。

    让我们来分析一下定义中提到的工具。其中k8s是整个云原生的基石,也是CNCF的第一个项目。云原生的整个生态体系都是依靠k8s建立起来的。因此在k8s之前是不可能有云原生的。定义里还提到了容器(Container)、服务网格(Service Mesh)、微服务(Microservice)、不可变基础设施(immutable infrastructure)和声明式API(declarative APIs)。其中容器(Container)是k8s的底层引擎,服务网格(Service Mesh)是建立在k8s上的针对请求的扩展功能,不可变基础设施(immutable infrastructure)是现代运维的基石,声明式API(declarative APIs)是k8s的编码方式,这些无一不是和k8s紧密相关的。但微服务(Microservice)就不同了,它其实跟云原生没什么关系,它们是两个完全不同的东西并沿着各自的轨道独立向前发展。但由于认容器技术和微服务是天生的良配,它们现在的演进轨道交织在一起密不可分。

    但实际上没有容器技术,微服务也可以部署在虚机上,只不过资源的利用率可能不够高。没有微服务,容器技术虽然不能大展宏图,但也能在分布式应用里找到一席之地。当然把它们放在一起确实能如虎添翼,但把微服务划归到云原生里实在是有点扩大外延,跑马圈地的意味。因为云原生的重点还是在基础设施,运维和运行环境以及软件的开发环境,而微服务是一个软件的架构,两者之间有明显的不同。

    云原生的表层含义

    那么到底什么是“云原生(Cloud Native)”呢?它分表层含义和深层含义。表层含义从字面上理解就比较容易了,我们管母语叫“Native Language”,也就是你一生下来就说的语言。“Cloud Native”就是一开始开发的时候就是为了最终部署到云环境上的。而在云计算初创时,大部分的程序都是从本地环境移植到云上的,它们在设计是就根本没考虑云环境的问题。

    云环境与本地环境的差异

    那么部署到云环境和部署到本地服务器有什么不同?这个才是问题的本质。

    你可能会说“是容器技术”,这个是现代云计算的不可或缺的支撑,但云计算开始的时候是基于虚拟化的,并没有容器技术,是在发展的过程中才有了容器技术。
    是“自动伸缩(auto-scaling)”吗?这是云环境的一个主要优点和特性,但它只是结果,不是本质。

    云技术的三大基石:

    基础设施即代码 (Infrastructure As Code)

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

    详情请见 InfrastructureAsCode

    不可变基础设施(immutable infrastructure)

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

    详情请见 What is “Immutable Infrastructure”?

    声明式API(declarative APIs)

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

    上面讲了云计算环境和传统基础设施的不同,其实随着云计算的发展,传统基础设施也在不断地采纳云计算的先进技术和理念,例如虚拟化和容器技术,而各个云计算厂商也提供了本地私有云的版本。只不过在公有云上的管理功能更强大,而通常本地私有云的版本是公有云的一个简化版。

    云原生应用程序的不同

    上面讲到了,只有一开始就是按照部署到云环境的要求来设计的应用程序才是云原生的。那么部署到云环境需要做哪些特殊设计呢?

    它主要有两个部分:
    第一部分是服务调用。不论是微服务之间的调用,还是微服务调用数据库或前端调用后端,调用的方式都是一样的。都需要知道IP地址,端口和协议,例如“http://127.0.0.1:80”, 其中“http”是协议,“127.0.0.1”是IP地址,“80”是端口。由于程序是部署在k8s上的,k8s会负责程序之间的寻址和调用。由于k8s会自动销毁出错的服务器,并创建新的服务器,IP地址就变成了动态的,而不是静态的。这时就只能通过服务名而不是IP地址来进行调用。也就是说k8s会给每个服务一个服务名,并通过k8s内部的DNS对服务名进行寻址。服务名是写在k8s的配置文件里的,软件设计的关键让应用程序和k8s配置文件都共享相同的调用地址。

    第二部分是数据的持久存储。在程序运行时,经常要访问持久存储(硬盘)上的数据,例如日志,配置文件或临时共享数据。程序在容器中运行,一旦出现问题,容器会被摧毁,k8s会自动重新生成一个与原来一模一样的容器,并在上面重新部署应用程序。在集群环境下,用户感觉不到容器故障,因为系统已经自动修复了。但当容器被摧毁时,容器上的数据也一起被摧毁了,因此要保证程序运行的连续性,就要让持久存储不受容器故障的影响。

    如果你对它的具体设计感兴趣,请参见把应用程序迁移到k8s需要修改什么?

    云原生的深层含义

    不过云原生还有一层引申含义。当你的最终生产环境是云环境时,你的本地开发环境最好也是云环境,这虽然不是必须的,但它能保证本地环境和生产环境的一致性,减少部署时的意外,是一个很自然的选择。而要在本地使用云环境来进行开发,你需要一系列的工具来保证开发的顺利和高效。要想了解云原生的开发环境及工具,请继续阅读下一篇“ 云原生开发环境初探"。

    索引:

    1. Going Cloud Native: 6 essential things you need to know
    2. Goto Berlin - Migrating to Microservices (Fast Delivery)
    3. CNCF Cloud Native Definition v1.0
    4. InfrastructureAsCode
    5. What is “Immutable Infrastructure”?
    6. 把应用程序迁移到k8s需要修改什么?
    7. 云原生开发环境初探

    不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考

    展开全文
  • 简介:日前,在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上,阿里云高级技术专家黄玉奇发表了题为《云原生新边界:阿里云边缘计算云原生落地实践》的主题演讲。...

    简介: 日前,在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上,阿里云高级技术专家黄玉奇发表了题为《云原生新边界:阿里云边缘计算云原生落地实践》的主题演讲。

    作者 | 黄玉奇
    来源 | 阿里巴巴云原生公众号

    日前,在由全球分布式云联盟主办的“Distributed Cloud | 2021 全球分布式云大会·云原生论坛”上,阿里云高级技术专家黄玉奇发表了题为《云原生新边界:阿里云边缘计算云原生落地实践》的主题演讲。

    1.png

    大家好,我是阿里云云原生团队的黄玉奇,非常感谢能有这个机会来跟大家分享。今天分享的题目是《云原生新边界∶ 阿里云边缘计算云原生落地实践》,从题目也能看到,分享内容应该是包括几个部分:云原生、边缘计算、二者结合架构设计、阿里云在商业和开源的实践以及案例。

    今天大家所熟知的云原生(Cloud Native)理念,本质是一套“以利用云计算技术为用户降本增效”的最佳实践与方法论。所以,云原生这个术语自诞生,到壮大,再到今天的极大普及,都处于一个不断的自我演进与革新的过程当中。云原生已经作为一系列的工具、架构、方法论而深入人心,并为广泛使用;那么云原生到底是如何定义的呢?早期,云原生含义包括∶ 容器、微服务、Devops、CI/CD;2018 年以后 CNCF 又加入了服务网格和声明式 Api。

    而回过头,我们再粗线条的看看云原生的发展历史,早期因为 Docker 的出现,大量的业务开始容器化、Docker 化。容器化通过统一交付件、隔离性从而带来了 Devops 的快速发展;Kubernetes 的出现让资源编排调度与底层基础设施解耦,应用和资源的管控也开始得心应手,容器编排实现资源编排、高效调度;随后,lstio 为代表的服务网格技术解耦了服务实现与服务治理能力。今天云原生几乎"包罗万象"般的无处不在,越来越多的企业、行业开始拥抱云原生。

    2.png

    而阿里巴巴作为云原生技术的践行者之一,云原生早已成为阿里的核心技术战略之—,这源自于过去十多年阿里在云原生领域的积累、沉淀和实践。大致可以分为三个阶段:

    • 第一阶段通过应用架构的互联网化沉淀了核心中间件、容器、飞天云操作系统等基础云原生能力;
    • 第二阶段是核心系统的全面云原生以及云原生技术的全面商业化;
    • 第三是云原生技术的全面落地和升级阶段,尤其是以 Serverless 为核心代表的下一代云原生技术正在引领整个技术架构升级。

    阿里云容器服务 ACK 作为阿里云原生能力相关的商业化平台,正在为广大客户提供丰富的云原生产品及能力,这些都是拥抱云原生最好的佐证,我们坚信云原生是未来。

    云原生技术已经无处不在, 阿里云作为云原生服务的提供者,我们认为云原生技术会继续高速发展,并被应用于"新的应用负载"、"新的计算形态"和"新的物理边界";从阿里云云原生产品家族大图中我们可以看到∶ 容器正被用于越来越多类型应用和云服务中;并且通过越来越多的计算形态承载,如 Serverless、函数计算等等;而丰富的形态也开始从传统的中心云走向边缘计算,走向终端。这就到了今天分享的主题:边缘计算中的云原生,下面我们看看什么是边缘计算。

    首先,我们从直观感受上看看什么是边缘计算。随着 5G、loT、音视频、直播、CDN 等行业和业务的发展,我们看到一个行业趋势,就是越来越多的算力和业务开始下沉到距离数据源或者终端用户重近的地方,从而来获得很好的响应时间和降低成本;这明显区别传统的中心式的云计算模式。并越来越被广泛应用于汽车、农业、能源、交通等各行各业。

    3.png

    再从 IT 架构上看边缘计算,可以看到它具有明显的按照业务时延和计算形态来确定的分层结构,这里分别引用 Gartner 和 IDC 对边缘计算顶层架构的解释∶ Gartner 将边缘计算分为"Near Edge"、"Far Edge"、"Cloud"三部分,分别对应常见的设备终端,云下 IDC/CDN 节点,以及公共云/私有云;而 IDC 则将边缘计算定义为更直观的"Heavy Edge"、"Light Edge"来分别表示数据中心维度,和低功耗计算的端侧。从图中我们可以看到分层结构中,层层相依。互相协作。

    这种定义也是现在业界对边缘计算和云计算关系所达成的一个共识。说完背景、架构,我们再看看边缘计算的趋势;我们尝试从业务、架构和规模三个维度去分析边缘计算的三大趋势:

    第一,Al、loT 与边缘计算的融合,会有种类越来越多、规模越来越大、复杂度越来越高的业务运行在边缘计算场景中,从图上我们也能看到一些非常震撼人心的数字。

    第二,边缘计算作为云计算的延伸,将被广泛应用于混合云场景,这里面需要未来的基础设施能够去中心化、边缘设施自治、边缘云端托管能力,同样图上也有部分引用数字。

    第三,基础设施的发展将会引爆边缘计算的增长,随着 5G、loT、音视频行业的发展,边缘计算的爆发是理所当然,去年疫情期间在线直播、在线教育行业的爆发式增长也是一个例子。

    随着架构的共识形成,在落地过程中我们发现,边缘计算的规模、复杂度正逐日攀升,而短缺的运维手段和运维能力也终于开始不堪重负,那么如何去解决这个问题呢? 

    云和边缘天然就是不可分割的有机整体,"云边端一体"的运维协同是目前比较能形成共识的一种方案。而作为云原生领域的从业人员,我们试着从云原生的角度来思考和解决这个问题;试想,如果"云边端一体"有云原生的加持,将会更好的加速云边融合进程。

    4.png

    在这个顶层架构设计下,我们抽象出了云边端协同的云原生架构:在中心(云),我们保留了原汁原味的云原生管控和产品化能力,通过云边管控通道将之下沉到边缘,使海量边缘节点和边缘业务摇身一变成为云原生体系的工作负载,通过服务流量和服务治理更好的和端进行交互;从而完成业务、运维、生态的一体化;而通过边缘云原生,我们可以获得和云上一致的运维体验,更好的隔离性,安全性以从及效率。产品落地就顺师理成章了许多。

    接下来我们介绍阿里云在商业化和开源上的边缘计算云原生实践。

    5.png

    阿里云 ACK@Edge 主打“云端标准管控,边缘适度自治”的服务理念;“云边端”三层结构分层明显,能力协同。第一层是中心的云原生管控能力,提供标准的云原生北向接口供上层业务集成,诸如城市大脑、工业大脑、CDN PaaS,loT PaaS 等;第二层是云边运维管控通道,有多规格、软硬多链路方案来承载云边下沉管控流量和业务流量;再往下就是关键的边缘侧,我们在原生的 K8s 能力基础上叠加了类似:边缘自治、单元化管理,流量拓扑,边缘算力状态精细化检测等能力;边云协同,从而构成了一个完整的云边管控闭环;目前,这套架构已经广泛用于 CDN、loT 等领域。

    那么边缘容器到底需要哪些核心能力和业务目标呢,图中所示包括∶ 四个能力,五个目标;四个能力是边缘算力管理、边缘业务容器化管理、边缘业务高可用支持和最终要实现的边缘云原生生态;从而实现边缘算力可接入、可运维,业务可管理、编排,服务高可用,业务有生态。下面对这些核心能力的设计做简单阐述。

    阿里云边缘容器产品 ACK@Edge 通过内置 SD-WAN 能力实现云上云下网络互联,业务流量互通,大大提升云边协同效率和稳定性、安全性;而通过云端资源对接,实现了云上云下的资源弹性互通,提升了边缘场景下的业务弹性能力。

    6.png

    第二个核心能力是边缘自治能力,在云边一体架构中,运维协同是一项重要的能力,但是通常受限于云和边缘之前的网络条件,边缘需要适当的自治能力来保证业务的连续性和持续稳定运行,换句话讲就是边缘资源和边缘业务能够在脱离云端管控的条件下继续完成业务的全生命周期管理,包括创建、启停、迁移、扩缩容等。

    7.png

    第三个异构资源的支持比较好理解,边缘计算区别于传统中心云计算的一个标志性特征就是计算资源、存储资源种类多样、异构明显。ACK@Edge 目前支持 arm x86 cpu 架构,支持 linux、windows 操作系统,支持将 linux 应用和 windows 应用混合部署,来很好地解决边缘场景资源异构问题。

    通过配合阿里云容器镜像服务,提供在边缘场景下的多地域交付能力,能够支持多种云原生制品的多地域交付,包括容器镜像,应用编排资源包等。

    8.png

    这里还要和大家同步一个信息,就是上述所有核心的边缘容器能力我们都开源在边缘容器平台项目 OpenYurt 中,OpenYurt 是 CNCF 的边缘容器官方项目,是一个延伸原生 Kubernetes 到边缘计算的智能开放平台项目。

    作为 ACK@Edge 的核心框架,已经服务了超百万容器实例规模,并被广泛应用于主流的边缘计算场景中;在介绍完商业和开源实践后,还有几个案例和大家分享:

    9.png

    第一个,是盒马鲜生基于边缘云原生实现的“人货场”数字化融合转型,通过云原生体系将多种类型的边缘异构算力统一接入、统一调度,包括∶ENS(阿里公共云边缘节点服务)、线下自建边缘网关节点, GPU 节点等。获取了强大的资源弹性和业务混编带来的灵活性;并通过 ACK@Edge 提供的边缘云原生 Al 解决方案,构建云、边、端一体化协同的天眼 Al 系统,充分发挥了边缘计算就近访问,实时处理的优势,轻松实现全方位的降本提效,门店计算资源成本节省 50%,新店开服效率提升 70%。

    10.png

    第二个是我们在一家视频网站客户的案例,使用 ACK@Edge 来管理跨 region、跨类型、跨地域的边缘算力,用于部署视频加速服务,通过对异构资源的支持,客户在边缘计算场景获得了强大的资源弹性能力;有一个数字分享给大家,通过边缘容器的弹性和异构资源管理能力,能够节省 50% 左右的成本。

    11.png

    第三个案例是 ACK@Edge 在 loT 智慧楼宇项目中的落地,其中 loT 网关设备作为边缘节点托管在 ACK@Edge 的云端管控,网关设备上的业务和楼宇的智能设备交互;网关和端设备的运维都统一收编到中心云,效率大大提升。

    原文链接

    本文为阿里云原创内容,未经允许不得转载。

    展开全文
  • 浅析云原生12要素

    2021-01-05 19:00:36
    以前不太明白其中的含义,经过一些实战之后,再回头看这些理论,发现这些“要素”个个一针见血,讲的正是实践中最容易踩的、最常见的坑。 12要素具体指什么? 《The Twelve-Factor App》是Heroku创始人 Adam ...

    "Twelve-Factor App[1]"的概念出现很久了,一般叫"12要素",衡量一个后端服务是否适合搬到云上,描述了云端应用服务应当遵循的一些最佳实践。以前不太明白其中的含义,经过一些实战之后,再回头看这些理论,发现这些“要素”个个一针见血,讲的正是实践中最容易踩的、最常见的坑。

    12要素具体指什么?

    《The Twelve-Factor App》是Heroku创始人 Adam Wiggins 在2012年提出的。相比于不符合这些特征的传统应用服务,具有这些特征的应用更合适云化。“Twelve-Factor”具体指的是下面的12条(不是一一对应翻译):

    1. Codebase:基线代码
    2. Dependencies:显式和隔离的依赖
    3. Configuration:配置分离存储到环境中
    4. Backing services:分离基础的后端组件
    5. Build, release, run:严格分离构建、发布、运行
    6. Processes:无状态的服务进程
    7. Port binding:自带端口绑定
    8. Concurrency:通过进程的水平扩展增大并发能力
    9. Disposability:易处置 - 快速启动和优雅退出
    10. Dev/prod parity:环境对等
    11. Log:日志作为事件流
    12. Admin processes:分离管理类任务

    如何理解这12点?

    Adam是在Heroku这个 Platform as a Service 模式的企业积累了大量经验,总结出的这些“要素”。对于PaaS提供商,关注的是应用服务如何在其Platform上运行的更好,因此要理解这些要素,我们先得搞清楚一个服务是怎么在Platform上跑起来的,简化的流程如下图所示:

     

     

    注:图片来自《Beyond the Twelve-Factor App》

    落实到真实场景中具体是什么样的呢?Heroku国内用的很少,我们以标准的Kubernetes平台为例展开来看:一个典型的容器化后端服务,从开发到上线需要经历哪些步骤

    1. 设计阶段:需求分析和领域设计、技术选型确定依赖的框架和组件、建立项目框架
    2. 开发阶段:开发、测试、代码评审,迭代到可发布的版本
    3. 创建镜像仓库,为服务编写Dockerfile,构建出服务的容器镜像
    4. 创建容器编排文件,确定非产线环境部署运维阶段的各项细节
    5. 在测试环境确认基础设施容量以及第三方组件,符合条件并初始化完毕,比如数据库的创建和初始化DDL的执行
    6. 准备部署到测试环境,在配置中心创建或更新配置文件,配置参数和密钥等
    7. 创建或更新持续集成、交付系统的任务管道, 执行CI/CD Pipeline,部署到测试环境
    8. 配置测试环境的访问入口,如反向代理的路由、域名等等
    9. 日志、监控、告警、链路追踪等相关组件接入
    10. 在测试环境进行完整的功能集成测试、性能测试
    11. 在预上线环境,重复步骤6-10
    12. 在产线环境,重复步骤6-10
    13. 继续迭代,完成开发和单测后,在每个环境重复步骤6-10,其中7,8,9中无需修改的部分可以跳过
    14. 每次迭代灰度发布,逐步放开新版本的流量

    可以看出,一个正经的后端系统,初次上线、后续迭代的流程已经比较复杂。如果单靠人力,单体系统勉强可以应付,毕竟单体系统即使变成"大泥球",也大多处于人力可控的范围内。但随着复杂度进一步提升,整个系统演化成微服务系统,往往包含十几个、数十个、甚至成百上千个子服务,多个服务之间还有依赖关系,这其中的技术挑战是显而易见的。

    复杂性无法避免,如何在复杂情况下,尽量提高效率、减少错误呢?

    答案就是,在设计和开发阶段去迎合云平台以及整个生态的能力,从一开始就要做一个适合在云上跑的服务

    “12要素”应运而生,给了我们一把衡量“是否适合上云”的标尺。用个不太恰当的比喻就是“屁股决定脑袋”。如果不遵循这些“要素”,不适应云平台提供的能力、不剥离业务无关的部分,随着服务规模增大、业务复杂度进一步提高,就非常容易引发问题了。

    这也是“12要素”出现的背景和原因,了解这些之后,其内容就更好理解了。下面我们把12要素归为两类,一类是放之四海而皆准的,第二类是对云原生应用特别重要的,以举反例的形式逐一讲解。

    第一类:几乎任何场景都适合的

    基线代码 - Codebase

    One codebase tracked in revision control, many deploys.

    基线代码可以理解为多层意思:一个项目一个仓库;Git分支也不要分岔之后合不回来了;不要在多个仓库出现重复的代码,把通用的代码抽成独立维护的仓库。

    反模式的例子:多个不相干项目数百万行代码全部放到一个代码仓库;对于一些需求差异,直接复制项目仓库单独开发,同时维护多个仓库代码。想象一下这两个例子,CI/CD系统心理阴影面积多大。

    另外,代码仓库的管理还影射了更深的含义。康威定律告诉我们,组织和团队的形态最终会反映到产品的形态上。因此看一个公司的代码仓库如何被创建和管理的,这个公司开发团队组织结构和技术管理水平也可见一斑。

    显式和隔离的依赖 - Dependencies

    Explicitly declare and isolate dependencies

    完善的依赖管理机制、显式的依赖声明文件和版本锁机制,能够减少因为错误的依赖版本导致的Bug。

    反模式的例子:Node.js之父Ryan Dahl另起炉灶创造了Deno,Deno的import远程代码就是Node世界的npm反向极端,造成了隐式依赖;Golang在1.13之前没有go module的时候,也是违反这条原则的。且不说不清晰的第三方依赖容易导致“投毒”,这对代码的问题定位、维护、交接都是很大的负担。

    注:这一小节的“反模式”并不是指技术本身哪里不好,其创造者都是世界顶级的工程师和科学家,仅指它们的一些原生特性,对开发复杂的应用不够友好。

    配置分离存储到环境中 - Configuration

    Store config in the environment

    配置数据和构建产物完全分离,配置数据单独管理,只在运行环境中出现。

    《Beyond the Twelve-Factor App》[2]中有一个比喻:代码制品、生产环境配置 是两个危险的化学物质,混合到一起就可能随时爆炸。因此,我们需要把配置(尤其是密钥类、功能开关、策略类配置)的重要性提升到很高的级别,小心翼翼地管理。

    若是配置不完全和代码分离,相当于两个危险的化合物一开始就被混合在一起,部署的时候原地爆炸也不足为奇。

    反模式的例子:环境相关的配置,混在容器镜像、甚至代码包中,每个环境需要单独构建打包一个版本。这种“不正确”的做法在传统的开发模式中很常见。

    分离构建、发布、运行 - Build, Release, Run

    Strictly separate build and run stages

    在本节一开始分享的图中,有6个阶段:设计、开发、构建、发布、配置、运行

    配置在上一小节已经说明为什么一定要分离出来。设计、开发在传统软件生命周期模型中已经是两步。

    剩下的3个阶段就是:构建、发布、运行,而这三者在传统软件的发布流程中有时候并没有完全分离。

    为什么要强调“构建、发布、运行”三个阶段一定要分离开来呢?

    有两个好处:

    • 职责和关注点的分离。构建是开发测试人员更关注的、发布是产品经理更关注的、运行是运维更关注的;
    • 流水线模式带来的效率提升,以及各阶段之间的缓冲空间,每个阶段有专门的工具和方法论。

    怎么做到这三个阶段的分离呢?流水线的运行不是靠人力保障的,自动化系统很重要。用好CI/CD系统、项目管理系统,制定好规则和流程并自动运转起来,足矣。

    反模式的例子:开发改完代码,本地打个Patch发给运维,也不告知产品经理改了什么,直接口头告诉运维批量更换某些文件。

    环境对等 - Dev/Prod Parity

    Keep development, staging, and production as similar as possible

    开发、测试、预上线、生产环境等等,甚至本地环境,都保持环境一致,这样能最大限度减少“我本地是正常的啊”、“开发环境是正常的啊”、“是不是环境/机器问题”这类甩锅式的抱怨。

    反模式的例子:开发环境不容器化,产线容器化;开发环境用的MariaDB,产线用的MySQL;开发环境数据库没主从,产线配置了主从同步。这样在MySQL读写分离时,主从同步那几毫秒的延迟导致各种奇怪Bug,在开发环境也许永远都重现不出来。

    第二类:对云原生应用及其重要的

    这篇题目为什么叫“云原生12要素"呢?其实Adam的原义只是云端应用应当具备的特征,并不是指云原生(Cloud Native)。本文想讲的不单是跑在云端的应用,而是有更现代化特征的云原生应用,所以用了这个题目。

    其实在Adam提出“12要素”一年后的2013年,才出现“云原生”的概念,云原生的含义也经历了一些演变。

    2015年Matt Stine在《Migrating to Cloud-Native Application Architectures》一书中对云原生的定义就是:

    • 符合12要素(The Twelve-Factor App)
    • 微服务(Microservices)
    • 自助式敏捷基础设施(Self-Service Agile Infrastructure)
    • 基于API协作(API-based Collaboration)
    • 健壮、抗压能力(Anti-Fragility)

    之后,2015年Linux基金会发起云原生基金组织(CNCF),给出的定义是:容器、自动化、微服务

    到了2017年,Pivotal稍微改了一点,变成了:DevOps、持续交付、微服务、容器。

    目前,CNCF官方最新的定义在技术方面对云原生的解释是[3]:容器、服务网格、微服务、不可变基础设施和声明式API。

    云原生含义的演化过程,有一个基调一直没变,就是微服务。微服务是当前云原生应用的表现形式,或许云原生以后还会进一步增加Serverless。下面讲的这些“要素”,对微服务/无服务的设计和开发非常重要。

    分离基础的后端组件 - Backing services

    Treat backing services as attached resources

    所有依赖的基础组件或者其他应用服务,比如数据库、缓存服务、消息队列、二方/三方服务,都视为外部资源,独立部署,通过网络访问

    用面向对象的术语类比,就是视别的服务为“关联”的而非“组合的”。“关联”意味着更弱的耦合,仅通过网络端口与这些依赖的服务交互,而不是进程间通信

    “关联”模式像人与手机的关系,“组合”模式像人与人的大脑、四肢的关系。因此,“关联”模式还有一个好处,它会强迫我们去思考:如果依赖的服务宕机了怎么办?

    就像很多人会有备用手机一样,大量的容错、降级处理的逻辑被写出来了,应用服务也获得了更强的鲁棒性。

    反模式的例子:把缓存服务和应用服务打包到同一个容器镜像,通过/var/redis.sock这样的Domain Socket形式访问;或者把第二方应用服务的源码直接复制到自己的代码中,在一个进程中互相调用。

    无状态的服务进程 - Processes

    Execute the app as one or more stateless processes

    按照上一节说的,把依赖的服务分离出去,一些应用服务已经可以实现“无状态”了。但有时候,还需要对应用内部做一些改造才能实现无状态。无状态是水平扩展的前提,对于Serverless应用更是必要条件。

    反模式的例子:应用服务的多个实例之间互相通信,共享一些内存数据;或者开发自治的集群选主、任务分发等功能。

    自带端口绑定 - Port Binding

    Export services via port binding

    不要依赖运行平台提供端口绑定的功能,提供出去的可运行程序,直接运行就会绑定到某个端口。比如Springboot应用通常内嵌tomcat/undertow/jetty等Java Web容器,构建出的包直接运行就绑定了端口。

    反模式的例子:提供出去部署的包的是 放到Tomcat的war、放到IIS的dll,自己本身没有描述通信协议,也没有指定绑定的端口,完全依赖Tomcat/IIS的配置。

    通过进程的水平扩展增大并发能力 - Concurrency

    Scale out via the process model

    无状态的应用服务,很容易实现水平扩展,自身不会制约到并发能力。传统应用服务通常是性能靠提升单机配置,可用性靠双机热备;而云原生应用,注重的是伸缩能力(Elastic, Scalable)。

    反模式的例子:把Session放到内存中。

    易处置:快速启动和优雅退出 - Disposability

    Maximize robustness with fast startup and graceful shutdown

    因为云原生应用需要保持更优秀的可伸缩性,服务的部署实例随时可能被创建出来、或者被销毁掉,这就要求服务自身提供快速启动和优雅退出能力。

    不具有快速启动能力,水平扩容的速度受限;不具备优雅退出能力,缩容时未处理完的业务中断,会导致用户请求错误、数据不一致性等问题。

    反模式的例子:很重的Java服务启动耗时十几分钟;缩容靠kill -9强杀进程;服务也没有实现收到SIGTERM信号进入“跛脚鸭状态”,也没有等待请求处理完再关闭进程。

    日志作为事件流 - Logs

    Treat logs as event streams

    应用服务不应该管日志怎么处理,日志如何处理是平台的职责,而非应用自身的业务。因此,应用服务只要把日志作为事件流抛出去就好了,容器环境中,最好的办法就是直接打印到标准输出和标准错误(stdout, stderr)。

    反模式的例子:项目中写了一堆log4xx的复杂配置,日志文件存哪个路径、多长时间轮滚、保留多久删除。传统的软件这是必备的,但云原生应用,请仅保留打印到标准输出/标准错误。还有一个反模式的例子,在应用内就通过代码把日志抛到Kafka这类Broker中,无形中也让应用服务和Kafka耦合到了一起。

    很多人不相信日志打印到stdout/stderr就完事了,是因为不够了解云原生世界中,各类日志收集和处理组件的强大。我们对传统的做法习以为常,却忘记了“单一职责原则”。

    分离管理类任务 - Admin Processes

    Run admin/management tasks as one-off processes

    什么是管理类任务(Admin Processes)?直译成“管理进程”感觉不太好,这里是Admin Processes指的是执行数据库DDL、周期执行的运维任务、一次性的数据迁移和修复等等这类事情,更贴切的说法是“后台管理类任务”。

    反模式的例子:在应用服务运行环境中安装一个数据库客户端,运维人员手动跑一堆修改数据库的SQL;或者安装一些运维脚本,放到机器的cron table定期执行一些脚本。

    这一条“要素”看似晦涩难懂,看反例就很清楚了。上述反例的做法是传统模式经常干的事情,但这种模式显然不“Scalable”。

    用自动化流水线和统一的任务调度平台,而不是手动SSH到机器上靠人做。《Beyond the Twelve-Factor App》中传达了更激进的观念:压根不要出现这类一次性的(“One-Off”)任务,这类业务也视为后端服务,调度中心仅触发一个HTTP/RPC请求,调用服务的接口做这类业务。

    再举个正例帮助理解:如果要实现每天跑一次的数据分析脚本,除了到机器上加crontab这个最坏的办法,还有什么其他办法呢?

    • 《The Twelve-Factor App》告诉我们,可以用一次性的容器,每天创建一个容器执行脚本,确认执行成功后随即销毁,不成功可以自动重试,比如Kuernetes提供的CronJob机制。
    • 《Beyond the Twelve-Factor App》告诉我们,可以在应用内或应用外单独做一个服务,提供一个HTTP/RPC接口做这件事,调度平台每天触发的仅仅是HTTP调用,根据调用返回结果决定重试。彻底去除Admin Processes,所有的东西都是可伸缩的Backing Service。

    彩蛋:第三类

    如果说“12要素”是云原生应用的必要条件,那它们也不能构成充分条件。

    Kevin Hoffman在2016年写的《Beyond the Twelve-Factor App》一书中,又重新修订了“12要素”,修改了一些解释,另外添加了API First、Telemetry、Authentication & Authorization三个要素。前两个对微服务系统非常重要,第三个则是安全性的核心保障机制。

    • API First:以API为中心的协作模式,永远先定义好API再做其他事情。微服务系统的开发模式,大多是多个小团队齐头并进,设计好之后,先定义API就非常重要了。以API作为团队、应用服务之间沟通的桥梁
    • Telemetry:翻译成“遥测”有些别扭,属于可观测性(Observability)的一部分,上面说过的日志也属于可观测性的一部分。对于云原生系统,要杜绝传统的“SSH进去运行Debug工具”的事情发生,“遥测”是实现这一点的唯一手段。监控、告警、链路追踪,在微服务系统中缺一不可。
    • Authentication & Authorization:认证和授权,属于安全性方面的“要素”,对传统的应用服务也适合。但云原生应用实现认证和授权的方式有所不同:对终端用户的认证授权往往在网关层就通过OAuth 2.0/OpenID Connect等协议统一处理了;对服务之间调用的认证授权通过Service Mesh可以做到零信任安全模式。

    这三个Kevin Hoffman新增的“要素”,本文篇幅有限就不展开了,有兴趣可以读原书了解细节。

    结语

    本文简述了云原生应用应具备的12+3个特征,主要受到《The Twelve-Factor App》和《Beyond the Twelve-Factor App》的启发,也借鉴了其中的一些理论和案例。写这篇文章,不是为了“3分钟入门云原生理论”,而是我自己经过一些实战后,思考的一点浅薄的个人理解。

    实践归纳出理论,理论指导实践。我们在真正开发一个应用服务时,尽量按这些指导思想,可以做的更加“Cloud Native”一些,但也不能教条主义,把这些视为“金科玉律”。日志一定要用stdout打印吗?Admin Processes一定要独立执行吗?所有的服务都能实现“无状态”吗?

    都不一定。

    Experience shows that compromise on purist ideals is as ever-present as death and taxes.

    “取舍”、“折衷”、“Trade-off”,一直是工程领域的关键词。没有最好的,只有适合的。

    参考

    1. ^https://12factor.net/
    2. ^https://www.oreilly.com/library/view/beyond-the-twelve-factor/9781492042631/
    3. ^https://github.com/cncf/toc/blob/master/DEFINITION.md
    展开全文
  • 今天我们不讲行业和商业,讲讲2019年最热的概念-云原生(Cloud Native)。 我认为云原生是未来10年IT发展最重要的趋势,但是它涵盖的概念非常多,需要花很多时间研究,同时浩如烟海的资料分散在网络上各个地方,...

    今天我们不讲行业和商业,讲讲2019年最热的概念-云原生(Cloud Native)。

    我认为云原生是未来10年IT发展最重要的趋势,但是它涵盖的概念非常多,需要花很多时间研究,同时浩如烟海的资料分散在网络上各个地方,缺乏系统性的梳理。今年2月我在基金内部做过一个分享,今日成文,希望让更多的人有所了解。

    本文试图解答:

    • 为什么云原生概念具有革命性?

    • 什么是微服务?

    • 微服务和中台的关系

    • 容器和微服务为什么是最佳搭档?

    • 容器化与虚拟化的区别

    • API管理与API集成的区别

    • Kubernetes是做什么用的?

    • 开源软件商业化遇到的典型问题是什么?

    • 等等

    涉及到的概念包括云原生、DevOps、持续集成、持续交付、持续部署、微服务、API管理、iPaaS、Service Mesh、Serverless、容器、Docker、Kubernetes等等,我争取用比较形象和通俗的方式把这些技术概念讲清楚。

    本文内容较多,共分为六个章节。

    第一部分 云原生及CNCF基金会

    第二部分 DevOps与CI/CD

    第三部分 微服务、API管理与集成

    第四部分 容器与Docker

    第五部分 Kubernetes与容器编排之战

    第六部分 思考与机会

    今天开启文章的第一部分——云原生及CNCF基金会,欢迎持续关注我的博客,接下来将为大家陆续讲解云原生时代其他五部分内容。


    从集装箱革命说起

    有一本非常有名的书,叫《集装箱改变世界》,说的是看起来平淡无奇的铁箱子,如何从二十世纪起永久性的改变了这个世界,并促进了全球化和全球分工。集装箱的出现和发展是实体货物包装、运输、交付方式的一次革命。

    《经济学家》杂志曾经评价说“没有集装箱,不可能有全球化”。集装箱为什么具有革命性?

    经济全球化的基础就是现代运输体系,而一个高度自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。集装箱最大的成功在于其产品的标准化及由此建立的一整套运输体系。能够让一个载重几十吨的庞然大物实现标准化,并且以此为基础逐步实现全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多试联运相配套的物流系统,这的确堪称人类有史以来创造的伟大奇迹之一,而撬动这个系统的理念就是标准化和系统化

    改变世界的不仅仅是集装箱本身,还有一整套货物处理的新方法,包括港口、货船、起重机、卡车,还有发货人的自身操作方式等

    云原生在IT领域的意义非常类似于集装箱,只是里面装载的不再是实体货物,而是虚拟世界的二进制代码和软件。我们将在介绍完众多概念之后再来对应解释。


    云原生的诞生

    随着虚拟化技术的成熟和分布式框架的普及,在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。

    云原生的发展史,来自CNCF基金会执行董事Dan Kohn

    云计算的3层划分,即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引,真正的云化不仅仅是基础设施和平台的变化,应用也需要做出改变,摈弃传统的土方法,在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点,重新设计,从而建设全新的云化的应用,即云原生应用。

    云原生(Cloud Native)这个概念,是由Pivotal的Matt Stine于2013年首次提出,他还在2015年出版了《Migrating to Cloud-Native Application Architectures(迁移到云原生架构)》一书。

    Gartner提到云原生的定义尚不明确,但含义丰富。云原生对于不同的人和组织来讲,有着不同的理解。众多顶级技术的铸造者、Matt Stine的东家Pivotal如此定义云原生。

    “Cloud native is an approach to building and running applications that fully exploit the advantages of the cloud computing model.”--云原生是一种构建和运行充分利用云计算模型优势的应用程序的方法。

    CNCF云原生计算基金会如此定义云原生:

    “云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格(Service Mesh)、微服务、不可变基础设施和声明式API。

    这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”

    其中服务网格和声明式API是新加入的内容,而不可变基础设施指的是应用的基础设施应是不可变的,是一个自包含、自描述可以完全在不同环境中迁移的东西,容器技术正是这一理念实现的基石。

    而CNCF同时把云原生计算定义为:

    “Cloud native computing uses an open source software stack to be:

    Containerized. Each part (applications, processes, etc) is packaged in its own container. This facilitates reproducibility, transparency, and resource isolation.

    Dynamically orchestrated. Containers are actively scheduled and managed to optimize resource utilization.

    Microservices-oriented. Applications are segmented into microservices. This significantly increases the overall agility and maintainability of applications.”

    云原生计算使用的开源技术栈包括:

    容器化。每个部分(应用、流程等等)都打包在自己的容器中,这有助于提升复用性、透明度以及改善资源隔离。

    动态编排。容器受到有效的调度和管理,以便优化资源利用。

    以微服务为导向。应用被分割到不同的微服务中,这种分割可以显著的提高应用的整体敏捷性和可维护性。

    我个人理解,云原生是指从云的原生应用角度出发,一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。

    下表列举了云原生应用和传统应用的有哪些主要区别。

    要转向云原生应用需要以新的云原生方法开展工作,云原生有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。

    云原生的发展脉络

    云原生背后的价值主张有哪些?

    • 隔离性:把应用程序打包在容器中加快了代码和组件的重用,并且简化了操作;

    • 无锁定:开源软件栈支持在任何公共或私有云上或以组合方式进行部署;

    • 无限扩展:为能够扩展到数万个自修复多租户节点的现代分布式系统环境而优化;

    • 灵活性和可维护性:将应用程序拆分为具有明确描述的依赖关系的微服务;

    • 提高效率和资源利用率:动态管理和调度微服务的中央编排流程降低了与维护和操作相关的成本;

    • 应用的弹性:以应对单个容器甚至数据中心的故障,以及不同级别的需求

    2019年,Gartner曾经发布报告表示云原生时代已经到来,在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。

    请注意,云原生相关技术不仅仅能用于云计算,即便是和云计算即对立又协同的边缘计算,微服务、容器、Kubernetes依然是事实上的杀手应用和标准。如由著名的Kubernetes管理平台创业公司Rancher所贡献的K3s项目,就是Kubernetes(K8s)的最轻量级版本,以满足边缘计算和IOT环境中,在x86、ARM64和ARMv7处理器上运行小型、易于管理的Kubernetes集群日益增长的需求。


    云原生计算基金会CNCF 

    提到云原生,就不能不介绍云原生计算基金会CNCF(Cloud Native Computing Foundation)。CNCF于2015 年7月由Google 牵头成立,隶属于 Linux 基金会,初衷是围绕云原生服务云计算,致力于培育和维护一个厂商中立的开源生态系统,维护和集成开源技术,支持编排容器化微服务架构应用,通过将最前沿的模式民主化,让这些创新为大众所用。

    CNCF的使命包括以下三点:

    • 容器化包装

    • 通过中心编排系统的动态资源管理

    • 面向微服务

    全球主流的科技企业和云计算厂商绝大部分都是CNCF会员,其中不乏多家来自中国的科技巨头。

    CNCF黄金、白金会员

    截止2020年4月,CNCF 基金会共托管49个云原生项目,每个CNCF项目都对应一个成熟度等级,申请成为CNCF项目的时候需要确定项目的成熟度级别,Kubernetes和 Envoy等项目基于生产可用和高稳定性首先成为毕业项目(9个),其他项目则根据其成熟度分别位于孵化(17个)和沙箱(23个)阶段。CNCF目前托管的项目共同构成了云原生生态的基石。

    值得注意的是其中有三个来自中国的项目:VMware中国团队为企业用户设计的 Registry Server开源项目Harbor,PingCap贡献的分布式事务键值数据库TiKV以及阿里自研的P2P文件分发系统Dragonfly。

    CNCF项目成熟度等级划分

    对于企业在复杂的基础架构之上如何推动云原生应用的更好落地,从而更好地适应环境与业务的发展,CNCF给出了路线图(Trail Map)用于对用户在整体上给出指导建议,共分成十个步骤(容器化;CI/CD;应用定义及编排;监控及分析;服务代理、发现和网格;网络、策略及安全;分布式数据库及存储;流与消息;镜像库与运行时;软件分发)进行实施,而在不同的步骤都可以结合CNCF全景图(Landscape)中列出的产品或服务进行选择。

    CNCF全景图则列举了和云原生相关的产品及服务的完整名单,这1381个项目共同构成了恢弘庞大的云原生世界。整个全景图按照功能分为29个模块,分别归属于9种大的类别(应用定义与开发、编排与管理、运行时、配置、平台、可观察性与分析、Serverless、会员和其它)。值得注意的是其中专门有一种分类是Cards from China,列举了来自中国的145个项目,其中不乏许多大家耳熟能详的知名项目,可惜的是数据并不完整。感兴趣的朋友可以自行研究。

    从CNCF的理念及野心来看,基于云原生的基础设施正在壮大和蚕食非云的市场,未来极有可能成为整个IT生态事实上的意见领袖和领导者。


    云原生涵盖的主要概念

    上面提到云原生的代表技术包括容器、服务网格(Service Mesh)、微服务、不可变基础设施和声明式API。另外一种比较主流的说法是云原生=微服务+DevOps+持续交付+容器化,广泛的见诸于各种文章和资料。

    在接下来的《云原生时代》系列文章中,我们将依照这些概念,分成DevOps与CI/CD;微服务、API管理与集成;容器与Docker;Kubernetes与容器编排之战四个部分全面介绍云原生各个组成部分。

    下一期内容为《云原生时代(二):DevOps与CI/CD》

     

    参考文档:

    本文的部分内容参考或者引用以下文章,在此表示感谢,如果有涉及知识产权的问题,请联系我及时修改。

    What is Cloud-Native? Is It Hype or The Future of Software Development? 

    A text interpretation of the cloud native (rpm)

    为什么你必须了解云原生?!

    腾讯大牛深入浅出详解云原生

    CNCF 官方大使张磊:什么是云原生?

    技术专栏 | 云原生应用之路

    展开全文
  • 什么是云原生?聊聊云原生的今生

    万次阅读 2020-03-02 10:46:49
    简介:什么是云原生,云原生是在一个怎么样的背景下被提出来的,云原生和传统所说的云计算概念有什么不同?聊聊云原生的今生之事。 云原生这词在这几年突然火了,在很多人还不了解她是什么的时候频频被她刷屏。...
  • 原生到底是什么?一文了解云原生四要素!

    千次阅读 多人点赞 2020-02-08 15:24:08
    所谓云原生,它不是一个产品,而是一套技术体系和一套方法论,而数字化转型是思想先行,从内到外的整体变革。更确切地说,它是一种文化,更是一种潮流,是云计算的一个必然导向。 随着虚拟化技术的成熟和分布式...
  • 把应用迁移到云上就是云原生架构吗?什么才是云原生架构?为什么要作云原生架构?本文告诉你,除了把应用搬到云上,要实现云原生,你还要做很多。
  • 原生基本介绍

    2021-07-29 10:56:45
    原生定义 云原生是一条最佳路径或者最佳实践。更详细的说,云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。 因此,云原生其实是一套...
  • 2020双11,天猫又创造了新的纪录:销售额达到历史新高4982亿、订单峰值达到创纪录的58.3万笔/秒。可以说,双11一直在推动着阿里云计算技术的创新和发展。...阿里云云原生应用平台负责人丁宇强调:云原生将..
  • “云原生”(Cloud Native)一词在 2019 年被技术界广泛使用,但是却没有关于这个词一个特别明确的定义。主要的困惑在于,“云原生”与您的应用程序部署到的环境几乎没有关系,该术语同样适用于私有云和公共云。该术语...
  • 原生思想 — 关键技术

    千次阅读 热门讨论 2020-12-24 12:39:59
    文章目录目录云原生的代表技术容器基于容器的不可变基础设施微服务Kubernetes声明式 API基于 Kubernetes 的云应用编排理论服务网格(Service Mesh) 云原生的代表技术 云原生的技术范畴包括了以下几个方面: 第一...
  • 关注「开源Linux」,选择“设为星标” 回复「学习」,有我为您特别筛选的学习资料~ 1带你了解云原生技术图谱如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景...
  • 原生开发环境初探

    千次阅读 2019-12-12 19:38:33
    在上一篇“云原生的不同解释及正确含义”里,我们讲到了云原生的引申含义,就是开发环境也是云环境,这样就能保证开发环境和生产环境的一致性,使最终的部署顺利进行。本文就通过具体的例子来探讨云原生的开发环境。...
  • 本文让我们一起来思考这些问题,看看企业IT架构的演进、云原生架构的发展、以及云原生架构如何助力数字化转型。 1 企业IT架构的演进 企业IT架构经历了几次比较大的技术演变,对企业应用、数据、技术的选型有着深远的...
  • 大家如果跟着我第一篇文章  微信小程序开发系列一:微信小程序的申请和开发...下一篇文章我会继续讲解index.js里的代码含义。 要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:
  • CNCF 官方大使张磊:什么是云原生

    千次阅读 2019-12-03 16:35:13
    从 2015 年 Google 牵头成立 CNCF 以来,云原生技术开始进入公众的视线并取得快速的发展,到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型云计算供应商都加入了云原生基金会CNCF,云原生技术也从原来的...
  • 7 月 25 日(周日),极客时间的「云原生开放日」邀请了腾讯云容器技术总监于广游、eBay 资深架构师孟凡杰来跟你聊聊他们的经验,另外还有资深技术猎头 Bendy PAN 来讲一讲大厂需要什么样的云原生技术人才。...
  • 原生时代(六): 机会与思考

    千次阅读 2020-06-18 17:44:58
    上文主要介绍了Kubernetes与容器编排之战,本文的最后一部分将系统性的总结云原生能带给我们什么样的未来,相关的创业和投资机会在哪里。 每一次IT产业架构的变革都会带来巨大的机遇和行业洗牌的挑战。过去的三四...
  • 原生落地实践的25个步骤

    千次阅读 2020-06-01 08:13:30
    其实我们在很多的技术大会上,看到的都是分层架构图,就像上一节我们分的六个层次一样,这容易给希望落地云原生的企业造成误解,因为大部分公司的云原生体系的建设都不是按层次来建设的,不会IaaS完全建设完毕,再...
  • 导读:云原生到底是什么?作者:阿里集团 阿里云智能事业群 云原生应用平台来源:大数据DT(ID:hzdashuju)云原生(Cloud Native)的概念,最早是由Pivotal于201...
  • 以容器、微服务、Serverless、服务网格等技术为核心的云原生(Cloud Native)技术,能够帮助企业实现业务应用与基础设施的解耦,云原生技术体系由于重新定义了信息产业的生态体系,因此被认为是成为了新一代云计算的...
  • 什么是云原生?聊聊云原生的今生 版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/alitech2017/article/details/104606956 云原生...
  • HTML5之原生拖拽

    千次阅读 2019-09-25 20:32:50
    <div id="div1"> <img id="drag1" src="/i/eg_dragdrop_w3school.gif"/> </div> <div id="div2"> </div> 上面暂时省略了拖拽相关的事件,我们将通过一步步为元素添加事件,来讲解这些事件具体的含义和用法。...
  • 这个单词来自于希腊语,含义是舵手或领航员。 K8s 是它的缩写,用“ 8 ”字替代了“ ubernete ”这 8 个字符。   K8s 并不是一件全新的发明。它是谷歌根据其内部使用的 Borg 改造成的一个通用容器编排调度器,于 ...
  • X、阿里云原生数据仓库AnalyticDB、阿里原生分布式数据库OceanBase,都很早就提出了“云原生”、“分布式”这些概念,听起来很玄乎,究竟这些名词,是什么含义?自己都很含糊,通过网络学习,做个普及。 1. 云原生 ...
  • 阿里云原生助力企业数字化转型 随着对云原生技术的探索、实践和积累,阿里云原生形成了业界“四个最”:阿里云拥有国内最丰富的云原生产品家族,最全面的云原生开源贡献,最大规模的云原生应用实践,最大的容器集群...
  • Linux总结

    千次阅读 多人点赞 2020-01-14 20:36:45
    2.3、Linux分类 Linux根据原生程度,分为两种: 内核版本: Linux不是一个操作系统,严格来讲,Linux只是一个操作系统中的内核。内核是什么?内核建立了计算机软件与硬件之间通讯的平台,内核提供系统服务,比如...
  • 前端面试题

    万次阅读 多人点赞 2019-08-08 11:49:01
    怎样添加、移除、移动、复制、创建和查找节点(原生JS,实在基础,没细写每一步) 61 有这样一个URL: http://item.taobao.com/item.htm?a=1&b=2&c=&d=xxx&e,请写一段JS程序提取URL中的各个GET参数(参数名和参数...
  • 原生|简述

    2020-09-12 11:15:12
    原生技术发展简史 2004年— 2007年,Google 已在内部大规模地使用像 Cgroups这样的容器技术; 2008年,Google将 Cgroups合并进入了Linux内核主干; 2013年,Docker项目正式发布。 2014年,Kubernetes项目也...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,884
精华内容 14,353
关键字:

原生的含义