精华内容
下载资源
问答
  • 2022-06-12 20:53:14

    微服务架构只是一种软件架构风格,并不限制所采用的实现技术,开发团队可以自由选择最合适的技术来实现。微服务架构实现最大的挑战是它的复杂度,这些复杂度是微服务架构本身天然所具备的,是每个微服务架构应用绕不开的难题。在实现微服务架构时,开发团队当然希望把全部的精力放在实现业务逻辑上,而不是应对微服务架构自身的复杂度,这就意味着,需要选择能够帮助应对这些复杂性的平台和工具。云原生(Cloud Native)应用就是微服务架构的最佳实现方式。

    云原生应用的概念

    顾名思义,云原生应用的概念由云和原生两个部分组成,云在这里指的是云平台,也就是平台即服务(Platform as a Service,PaaS);原生应用指的是专门针对云平台而设计和实现的,充分利用了云平台的特性。应用的微服务可以专注于实现业务逻辑,而把微服务架构的复杂度交给云平台来解决。

    起初CNCF(云原生计算基金会)认为云原生系统需包含的属性:

    1. 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
    2. 自动化管理:统一调度和管理中心,从根本上提高系统和资源利用率,同时降低运维成本。
    3. 面向微服务:通过松耦合方式,提升应用程序的整体敏捷性和可维护性。

    随着近几年来云原生生态的不断壮大,所有主流云计算供应商都加入了该基金会,且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF 基金会中的会员以及容纳的项目越来越多,该定义已经限制了云原生生态的发展,CNCF 为云原生进行了重新定位。
    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器服务网格微服务不可变基础设施声明式 API

    • 容器技术(container) :容器技术真正核心的创新是容器镜像(docker image),镜像是一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境,包括代码、依赖库、工具、资源文件和元信息等,打包成一种操作系统发行版无关的不可变更软件包。容器技术和云原生好比一对螺旋体,容器技术催生了云原生思潮,云原生生态推动了容器技术发展。容器镜像打包了整个容器运行依赖的环境,以避免依赖运行容器的服务器的操作系统,从而实现“build once, run anywhere”。容器镜像一旦构建完成,就变成read only,成为不可变基础设施的一份子。在容器技术的基础上,容器编排技术(主流方案:K8S)为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等功能,用户不需要再过度的关注资源的管理问题,降低操作的复杂度,提高了大规模容器集群管理的便捷性。
    • 微服务(Microservices) :微服务架构中,服务是一个单一的、可独立部署的软件组件,它实现了一些有用的功能,服务的API封装了其内部实现,与单体架构不同,开发人员无法绕过服务的API直接访问服务内部的方法和数据,因此,微服务架构强制实现了应用程序的模块化。微服务架构的最核心特性是服务之间的松耦合性。
    • 服务网格 :服务网格是用于处理服务间通信的专用基础设施层,负责在微服务间进行可靠地请求传递。服务网格通常通过一组轻量级网络代理来实现,这些代理与应用程序代码一起部署,而不需要感知应用程序本身。
    • 不可变基础设施:一个工作负载(比如容器、虚拟机等)一旦部署以后就不会被修改。当需要更新,修复或修改某些内容的时候,只需要将新的、经过验证的工作负载替换旧的即可。
    • 声明式API:声明式API是一种比命令式API更高级的接口设计方式,简单来说,命令式API提供给用户怎么做的能力,而声明式API给用户提供了做什么的能力。
    • DevOps:DevOps就是基于敏捷开发将软件开发/测试人员/IT运维关联在一起,通过工具、组织等方式使开发、测试、发布流程自动化,软件发布频繁,高效。DevOps的核心是CICD。
      • 持续集成(CONTINUOUS INTEGRATION,CI)其核心是新提交的代码与原代码正确的集成。开发人员多次、频繁的将代码提交到代码仓库中,在合并到指定分支之前,对新提交上来的内容进行编译、自动化检测(如:代码格式检测)的验证,这样的过程既保证了代码的完整性、安全性,为后面的工作提供了质量保证。
      • 持续交付(CONTINUOUS DELIVERY,CD),其重点不在代码本身,而是可以交付的产品上。在发布到生产环境之前,对新增的代码进行测试(test) -> 模拟(staging) -> 生产(produciton),即简化繁琐的发布流程,又保障新添加的代码在生产环境是可用的。
      • 持续部署(CONTINUOUS DEPLOYMENT)通过自动化部署的方式频繁的交付产品,关注的重点在于自动化部署。从开发人员提交代码到编译、测试、部署整个流程都是通过自动化执行,这种方式加快了交付的速度,同时在发现问题时也缩短修复的时间。

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

    云原生应用的特征

    与其他应用相比,总结起来,云原生应用有如下 15 个特征。

    单一代码库

    云原生应用必须有单一的代码库,并在版本管理系统中进行追踪。
    对于微服务架构的应用来说,每个应用由多个服务组成,这些服务应该由单一的代码库进行管理,这保证了构建版本的稳定性。

    • 如果一个改动涉及到多个服务,则这个改动应该在一次代码提交中完成对所有相关服务的修改;
    • 如果服务的代码分散在多个代码库中,则一个改动会被分成多个代码提交,每个代码提交都会触发一次持续集成流程,产生对应服务的构建版本,这些服务的构建版本只包含了部分改动,是不完整的。

    API 优先

    **云原生应用应该采用 API 优先的设计策略。**微服务架构的应用使用公开 API 来作为服务的对外接口,API 屏蔽了服务的内部实现细节。API 优先的设计策略指的是在设计阶段,应该首先设计 API 并确定 API 的细节。API 的设计过程需要多个团队的参与,包括 API 的实现者和可能的使用者,这些团队在充分讨论中最终完成 API 的定义。API 可以使用 OpenAPI 规范描述,从该规范中可以生成 API 文档和进行测试的模拟服务器。

    1. API 优先的策略保证了 API 的稳定性,同时可以减少不必要的后期修改。
    2. API 优先的另外一个好处是可以提高开发效率。不同的团队可以并行工作,从而提高效率。

    依赖管理

    云原生应用应该管理自己的依赖,Java 开发人员对依赖管理应该并不陌生,常用的 Java 构建工具 Maven 和 Gradle 都提供了依赖管理的支持。在开发过程中,只需要利用构建工具的支持即可;在管理依赖时,则需要区分应用自带的依赖和运行环境提供的依赖。云原生应用通常会包含全部所需的依赖,尤其是以容器形式运行的应用,典型的例子是微服务的 REST API。云原生应用会自带嵌入式的 Tomcat 这样的服务器来提供 HTTP 服务。

    设计、构建、发布和运行

    云原生应用应该有完整的设计、构建、发布和运行流程,如下图所示。
    在这里插入图片描述

    代码、配置和凭据

    代码、配置和凭据是云原生应用开发中创建的三种不同类型的实体。

    • 代码包括源代码和相关资源文件;
    • 配置是与部署环境相关的配置信息,通常以 XML、YAML、JSON 或属性文件的形式出现,配置中包含的信息包括第三方服务的连接方式、数据库连接信息和应用自身的配置属性等;
    • 凭据指的是密码、私钥和 API 密钥等敏感信息。

    代码和配置的区别在于,代码不会随着部署环境而变化,而配置则相反。在实践中,应该尽可能把配置从应用中分离出来,进行外部化管理,构建出来的二进制工件中不包含任何配置信息,实际的配置值在部署时根据环境来确定。在运行时,一般使用环境变量来传递配置值,还可以使用类似 Spring Cloud Config 这样的专门配置服务器来管理配置值。凭据都应该从源代码仓库中删除。

    日志

    日志是应用开发中不可或缺的部分。与传统应用不同的是,云原生应用并不需要对日志的输出方式进行很多配置,只是简单地把日志写到标准输出流(stdout)和标准错误流(stderr)。
    日志的收集和处理由云平台上的其他服务来提供,这把应用开发人员从日志管理相关的任务中解放出来。
    云平台上的日志管理服务非常多,开源的典型实现包括 ELK 技术栈(ElasticSearch + LogStash + Kibana)和 Fluentd。

    随时可丢弃

    **云原生应用的生命周期可能是短暂的,随时可能被终止。**云平台可能会随时启动和停止应用的实例,这就要求云原生应用的启动和停止速度都要非常快。

    支撑服务

    云原生应用的运行离不开支撑服务。支撑服务是一个宽泛的概念,包括数据库、消息中间件、缓存、用户认证和授权、存储等。连接这些支撑服务的配置信息应该被抽离出来,在运行时根据部署环境提供实际值。

    环境等同

    **云原生应用的不同部署环境应该是等同的。**开发、测试和生产环境之间不应该有差异,环境的等同性保证了云原生应用可以快速的进行部署,这一特征与构建工件的不变性是相辅相成的,两者缺一不可。有了这两个特征之后,每一个唯一版本的构建工件可以被依次部署到不同的环境,在测试环境上经过测试的版本,可以直接部署到生产环境。我们可以确定应用在生产环境上的行为与测试环境中一样。

    管理任务

    云原生应用运行中可能会需要执行一些管理任务,比如生成报表或者执行一次性的数据查询等,这些任务通常并不属于业务流程的一部分,更多的是为了管理和运维的需要。这些任务在执行中会用到云原生应用所依赖的支撑服务,对于这些任务,应该创建独立的应用,并在同样的云平台上运行。对于定期执行的任务,可以充分利用云平台的支持,比如,Kubernetes 提供了对定时任务(CronJob)的支持。

    端口绑定

    云原生应用在运行时并不负责管理实际的端口绑定,而是由云平台统一管理。比如,一个基于 Spring Boot 的微服务应用通常在 8080 端口运行 HTTP 服务,当应用运行在云平台上时,这个端口只是虚拟机或容器内的端口,并不是外部用户或其他服务访问时的实际端口。云平台对网络进行统一管理,负责分配实际的端口,云平台同时提供了相应的机制来发现访问服务的实际地址和端口。

    无状态进程

    **云原生应用应该是无状态的。**所有的状态信息都应该从应用中抽离出来,并保存在支撑服务中,比如数据库中。正因为应用是无状态的,才可以由云平台快速的启动和停止,并进行垂直或水平扩展。

    并发性

    云原生应用使用水平扩展来并发运行多个实例,使用负载均衡来把请求分配到某个实例进行处理。

    遥测数据

    云原生应用需要收集一系列遥测数据,包括应用性能指标、运行状态和日志等,这些遥测数据,对于云平台和应用来说同等重要。
    云平台可以用性能指标来进行自动水平扩展,比如,Kubernetes 支持 Pod 的自动水平扩展,当 CPU 的利用率超过预定的阈值时,会自动启动新的 Pod 来处理请求。

    认证和授权

    云原生应用应该是安全的,安全应该在应用的设计阶段就充分考虑。在实现中,可以使用基于角色的访问控制(RBAC)来保护 API,已经有大量的开源框架来帮助实现认证和授权。

    总结

    在理想情况下,云原生应用应该具备上述全部 15 个特征,但是在实际的开发中,不一定能够做到。开发团队可以根据需要,选择对应用最重要的特征来实现。

    参考:
    https://lib.jimmysong.io/cloud-native-handbook/intro/what-is-cloud-native/
    拉勾:《云原生微服务架构实战精讲-成富》

    本文内容到此结束了,
    如有收获欢迎点赞👍收藏💖关注✔️,您的鼓励是我最大的动力。
    如有错误❌疑问💬欢迎各位大佬指出。
    主页共饮一杯无的博客汇总👨‍💻

    保持热爱,奔赴下一场山海。🏃🏃🏃

    在这里插入图片描述

    更多相关内容
  • 云原生技术发展简史 首先从第一个问题进行分享,那就是“为什么要开设云原生技术公开课?”云原生、CNCF都是目前非常热门的关键词,但是这些技术并不是非常新鲜的内容。 2004年— 2007年,Google 已在内部大规模地...

    云原生技术发展简史

    首先从第一个问题进行分享,那就是“为什么要开设云原生技术公开课?”云原生、CNCF 都是目前非常热门的关键词,但是这些技术并不是非常新鲜的内容。

    • 2004 年— 2007 年,Google 已在内部大规模地使用像 Cgroups 这样的容器技术;
    • 2008 年,Google 将 Cgroups 合并进入了 Linux 内核主干;
    • 2013 年,Docker 项目正式发布。
    • 2014 年,Kubernetes 项目也正式发布。这样的原因也非常容易理解,因为有了容器和 Docker 之后,就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器,这就是 Kubernetes 项目的初衷。在 Google 和 Redhat 发布了 Kubernetes 之后,这个项目的发展速度非常之快。
    • 2015 年,由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了 CNCF 云原生基金会。CNCF 成立之初,就有 22 个创始会员,而且 Kubernetes 也成为了 CNCF 托管的第一个开源项目。在这之后,CNCF 的发展速度非常迅猛;
    • 2017 年,CNCF 达到 170 个成员和 14 个基金项目;
    • 2018 年,CNCF 成立三周年有了 195 个成员,19 个基金会项目和 11 个孵化项目,如此之快的发展速度在整个云计算领域都是非常罕见的。

    云原生技术生态现状

    因此,如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF 有一张云原生全景图(https://github.com/cncf/landscape),在这个全景图里已经有 200 多个项目和产品了,这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景,加以思考就会发现,我们今天所讨论的云原生其实主要谈论了以下几点:

    1. 云原生基金会 —— CNCF;
    2. 云原生技术社区,比如像 CNCF 目前正式托管的 20 多个项目共同构成了现代云计算生态的基石,其中像 Kubernetes 这样的项目已经成为了世界第四活跃的开源项目;
    3. 除了前面两点之外,现在全球各大公有云厂商都已经支持了 Kubernetes。此外,还有 100 多家技术创业公司也在持续地进行投入。现在阿里巴巴也在谈全面上云,而且上云就要上云原生,这也是各大技术公司拥抱云原生的一个例子。

    我们正处于时代的关键节点

    2019 年正是云原生时代的关键节点,为什么这么说?我们这里就为大家简单梳理一下。

    从 2013 年 Docker 项目发布开始说起,Docker 项目的发布使得全操作系统语义的沙盒技术唾手可得,使得用户能够更好地、更完整地打包自己的应用,使得开发者可以轻而易举的获得了一个应用的最小可运行单位,而不需要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。

    2014 年的时候,Kubernetes 项目发布,其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”,并且提出了“容器设计模式”的思想。而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目,其实背后的原因也比较容易理解:Borg/Omega 这样的系统太复杂了,是没办法提供给 Google 之外的人使用,但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到,这也是开源 Kubernetes 的重要背景。

    这样到了 2015 年到 2016 年,就到了容器编排“三国争霸”的时代,当时 Docker、Swarm、Mesos、Kubernetes 都在容器编排领域展开角逐,他们竞争的原因其实也比较容易理解, 那就是 Docker 或者容器本身的价值虽然大,但是如果想要让其产生商业价值或者说对云的价值,那么就一定需要在编排上面占据一个有利的位置。

    Swarm 和 Mesos 的特点,那就是各自只在生态和技术方面比较强,其中,Swarm 更偏向于生态,而 Mesos 技术更强一些。相比之下, Kubernetes 则兼具了两者优势,最终在 2017 年“三国争霸”的局面中得以胜出,成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务,并且 Swarm 项目逐渐停止维护。

    到了 2018 年的时候,云原生技术理念开始逐渐萌芽,这是因为此时 Kubernetes 以及容器都成为了云厂商的既定标准,以“云”为核心的软件研发思想逐步形成。

    而到了 2019 年,情况似乎又将发生一些变化。

    2019 年——云原生技术普及元年

    为什么说 2019 年很可能是一个关键节点呢?我们认为 2019 年是云原生技术的普及元年。

    首先大家可以看到,在 2019 年,阿里巴巴宣布要全面上云,而且“上云就要上云原生”。我们还可以看到,以“云”为核心的软件研发思想,正逐步成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课,大量的工作岗位正在涌现出来。

    这种背景下,“会 Kubernetes”已经远远不够了,“懂 Kubernetes”、“会云原生架构”的重要性正日益凸显出来。 从 2019 年开始,云原生技术将会大规模普及,这也是为什么大家都要在这个时间点上学习和投资云原生技术的重要原因。

    二、“云原生技术公开课”是一门怎样的课程?

    基于上面所提到的技术趋势,所以阿里巴巴和 CNCF 联合开设了云原生技术公开课。

    那么这样的公开课到底在讲什么内容呢?

    公开课教学大纲

    第一期云原生公开课的教学大纲,主要以应用容器和 Kubernetes 为核心,在后面几期将会陆续上线 Service Mesh、Serverless 等相关课程。

    在第一期公开课中,我们首先将课程分为两部分——基础知识部分和进阶知识部分,总共有 17 个知识点。

    • 首先,我们希望通过第一部分的课程讲解帮助大家夯实基础。然后,对于更高阶的内容展开更深入的代码级别的剖析。希望通过这样循序渐进的方式帮助大家学习云原生技术;
    • 其次,在每个课程后面我们的讲师都会设置对应的课后自测考试题,这些考试题实际上是对本节课程最有效的归纳,我们希望能够通过课后评测的方式来帮助大家总结知识点,打造出属于自己的云原生知识体系;
    • 最后,我们的讲师在每个知识点的背后都设计了云端实践,所谓“实践出真知”,学习计算机相关的知识还是需要上手来实际地进行操作才可以。 因此在云端实践部分,讲师会提供详细的实践步骤供大家课后自我联系。并且在这个环节,阿里云还会赠送了定量的阿里云代金券帮助大家更好地在云上进行实践。

    以上三个部分就构成了阿里云和 CNCF 联合推出的云原生技术公开课的教学内容。

    公开课授课计划(第一期)

    在授课计划方面,初步这样安排:第一堂课在 2019 年 4 月的第三周上线,此后将会每周更新一课,对于部分比较重要的知识点将会每周更新两次,总共 25 个课时。每个知识点后面都提供了课后自测和云端实践。

    对于讲师阵容而言,也是本次公开课最引以为傲的部分。我们的公开课将会主要由 CNCF 社区资深成员与项目维护者为大家讲解,很多课程讲师都是阿里云容器平台团队的专家级工程师。同时,我们也会邀请云原生社区的资深专家和外部讲师为大家讲解部分内容。因此在课程进行过程中,我们会不定期地安排大咖直播、课程答疑和落地实践案例。

    我们希望将这些内容都集成在一起,为大家呈现一个中国最完整、最权威、最具有影响力的云原生技术公开课。

    课程预备知识

    大家可能存在这样的疑惑,就是想要学习云原生基础知识之前需要哪些预备知识呢?其实大致需要三部分预备知识:

    1. Linux 操作系统知识:主要是一些通识性的基础,最好具有一定的在 Linux 下开发的经验;
    2. 计算机和程序设计的基础:这一点到入门工程师或者高年级本科生水平就足够了;
    3. 容器的使用基础:希望大家具有容器的简单使用经验,比如 docker run 以及 docker build 等,最好有一定 Docker 化应用开发的经验。当然,我们在课程中也会讲解相关的基础知识。

    三、什么是“云原生”?云原生该怎么落地?

    在介绍完课程之后,我们再来详细的聊一聊“云原生”:什么是“云原生”?云原生该怎么落地?这两个问题也是整个课程的核心内容。

    云原生的定义

    很多人都会问“到底什么是云原生?”

    实际上,云原生是一条最佳路径或者最佳实践。更详细的说,云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

    因此,云原生其实是一套指导进行软件架构设计的思想。按照这样的思想而设计出来的软件:首先,天然就“生在云上,长在云上”;其次,能够最大化地发挥云的能力,使得我们开发的软件和“云”能够天然地集成在一起,发挥出“云”的最大价值。

    所以,云原生的最大价值和愿景,就是认为未来的软件,会从诞生起就生长在云上,并且遵循一种新的软件开发、发布和运维模式,从而使得软件能够最大化地发挥云的能力。说到了这里,大家可以思考一下为什么容器技术具有革命性?

    其实,容器技术和集装箱技术的革命性非常类似,即:容器技术使得应用具有了一种“自包含”的定义方式。所以,这样的应用才能以敏捷的、以可扩展可复制的方式发布在云上,发挥出云的能力。这也就是容器技术对云发挥出的革命性影响所在,所以说,容器技术正是云原生技术的核心底盘。

    云原生的技术范畴

    云原生的技术范畴包括了以下几个方面:

    • 第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
    • 第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分,包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。
    • 第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试,也就是混沌工程的概念。
    • 第四部分就是云原生的底层技术,比如容器运行时、云原生存储技术、云原生网络技术等。
    • 第五部分是云原生工具集,在前面的这些核心技术点之上,还有很多配套的生态或者周边的工具需要使用,比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
    • 最后则是 Serverless。Serverless 是一种 PaaS 的特殊形态,它定义了一种更为“极端抽象”的应用编写方式,包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS,其最为典型的特点就是按实际使用计费(Pay as you go),因此 Serverless 计费也是重要的知识和概念。

    云原生思想的两个理论

    在了解完云原生的技术范畴之后你就会发现,其所包含的技术内容还是很多的,但是这些内容的技术本质却是类似的。云原生技术的本质是两个理论基础。

    • 第一个理论基础是:不可变基础设施。这一点目前是通过容器镜像来实现的,其含义就是应用的基础设施应该是不可变的,是一个自包含、自描述可以完全在不同环境中迁移的东西;
    • 第二个理论基础就是:云应用编排理论。当前的实现方式就是 Google 所提出来的“容器设计模式”,这也是本系列课程中的 Kubernetes 部分所需主要讲解的内容。

    基础设施向云演进的过程

    首先为大家介绍一下“不可变基础设施”的概念。其实,应用所依赖的基础设施也在经历一个向云演进的过程,举例而言,对于传统的应用基础设施而言,其实往往是可变的。

    大家可能经常会干这样一件事情,比如需要发布或者更新一个软件,那么流程大致是这样的,先通过 SSH 连到服务器,然后手动升级或者降级软件包,逐个调整服务器上的配置文件,并且将新代码直接都部署到现有服务器上。因此,这套基础设施会不断地被调整和修改。

    但是在云上,对“云”友好的应用基础设施是不可变的。

    这种场景下的上述更新过程会这么做:一旦应用部署完成之后,那么这套应用基础设施就不会再修改了。如果需要更新,那么需要现更改公共镜像来构建新服务直接替换旧服务。而我们之所以能够实现直接替换,就是因为容器提供了自包含的环境(包含应用运行所需的所有依赖)。所以对于应用而言,完全不需要关心容器发生了什么变化,只需要把容器镜像本身修改掉就可以了。因此,对于云友好的基础设施是随时可以替换和更换的,这就是因为容器具有敏捷和一致性的能力,也就是云时代的应用基础设施。

    所以,总结而言,云时代的基础设施就像是可以替代的“牲口”,可以随时替换;而传统的基础设施则是独一无二的“宠物”,需要细心呵护,这就体现出了云时代不可变基础设施的优点。

    基础设施向云演进的意义

    所以,像这样的基础设施向“不可变”演进的过程,为我们提供了两个非常重要的优点。

    • 1、基础设施的一致性和可靠性。同样一个镜像,无论是在美国打开,在中国打开,还是在印度打开都是一样的。并且其中的 OS 环境对于应用而言都是一致的。而对于应用而言,它就不需要关心容器跑在哪里,这就是基础设施一致性非常重要的一个特征。
    • 2、这样的镜像本身就是自包含的,其包含了应用运行所需要的所有依赖,因此也可以漂移到云上的任何一个位置。

    此外,云原生的基础设施还提供了简单、可预测的部署和运维能力。由于现在有了镜像,应用还是自描述的,通过镜像运行起来的整个容器其实可以像 Kubernetes 的 Operator 技术一样将其做成自运维的,所以整个应用本身都是自包含的行为,使得其能够迁移到云上任何一个位置。这也使得整个流程的自动化变得非常容易。

    应用本身也可以更好地扩容,从 1 个实例变成 100 个实例,进而变成 1 万个实例,这个过程对于容器化后的应用没有任何特殊的。最后,我们这时也能够通过不可变的基础设施来地快速周围的管控系统和支撑组件。因为,这些组件本身也是容器化的,是符合不可变基础设施这样一套理论的组件。

    以上就是不可变基础设施为用户带来的最大的优点。

    云原生关键技术点

    当我们回过头来看云原生关键技术点或者说它所依赖的技术理论的时候,可以看到主要有这样的四个方向:

    1. 如何构建自包含、可定制的应用镜像;
    2. 能不能实现应用快速部署与隔离能力;
    3. 应用基础设施创建和销毁的自动化管理;
    4. 可复制的管控系统和支撑组件。

    这四个云原生关键技术点是落地实现云原生技术的四个主要途径,而这四个技术点也是本门课程的 17 个技术点所主要讲述的核心知识。

    Pivotal 是云原生应用的提出者,并推出了Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。

    云原生的概念历经了许多个版本的迭代,到了2015年Google主导成立了云原生计算基金会(CNCF),对云原生的定义为:

    云原生(Cloud Native)技技术帮助企业和机构在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API。
    这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术可以使开发者轻松地对系统进行频 繁并可预测的重大变更 。

    干货!看云原生时代阿里云的四个“最”

    云原生已经成为 IT 领域最热的词之一。到底有多火,大家感受一下:

    2015 年在旧金山召开的首届 KubeCon 只有 200 余参会者,而今年第二次在中国举办的KubeCon迎来了3000+现场观众,遍布全球的线上关注开者则更是不计其数。Gartner最近发布报告表示云原生时代已来,在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。

    作为云原生技术与应用的领先企业,阿里云在今年的 KubeCon + CloudNativeCon 大会上为全球企业和开发者分享了26场行业趋势和技术演讲。

    阿里云智能容器平台负责人丁宇指出:

    云原生正在重塑整个软件生命周期,容器、Kuberentes、云原生成为云时代的三个重要标准。阿里云将继续加大云原生技术栈产品体系的研发,并持续回馈开源社区,与生态合作伙伴一起,共同推动云原生标准制定以及应用的落地。

    9年技术沉淀,阿里云云原生的四个“最”

    阿里巴巴是国内最早布局云原生技术的公司之一,丁宇在 26 日的主题演讲中表示:“早在 2011年,阿里巴巴就率先开始了容器化进程,开启了中国公司将云原生技术体系在电商、金融、制造等领域中大规模应用的先河。”

    历经9年技术沉淀,阿里云成为国内唯一进入 Gartner《公有云容器服务竞争格局》报告的企业。

    今年 3 月,阿里云智能总裁张建锋表示,未来 1-2 年内,阿里巴巴要实现 100% 的业务跑在公共云之上,并且继续大力投入云原生技术的研发

    最丰富的云原生产品家族

    经过 9 年的内部技术实践,阿里云已拥有国内最丰富的云原生产品家族,覆盖八大类别 20 余款产品,涵盖底层基础设施、数据智能、分布式应用等,可以满足不同行业场景的需求。

    目前阿里巴巴集团内部电商、城市大脑等核心业务已经大规模使用云原生技术,去年双 11,阿里云完成了 10 分钟 1000 台以上服务器的快速部署,容器部署规模达到百万级,两年内实现全部上云,是全球最大规模的云原生应用实践。

    最全面的云原生开源贡献

    阿里云一直致力于回馈社区、积极拥抱开源,是国内在云原生领域的开源贡献最全面的科技公司,涵盖编排调度、作业管理、无服务器框架等:

    ● 主导维护 etcd、containerd、dragonfly 等多个 CNCF 明星项目的发展,已有超过 10 个项目进入 CNCFlandscape;

    ● 项目建设层面:积极建设 Kubernetes 项目,贡献量位居全球前 10;

    ● 开源生态支持:加入 CNCF、OCI、CDF 等基金会,成为多个基金会的顶级会员,共建开源生态。

    今年 1 月,阿里云资深技术专家李响成为首个入选全球顶级开源社区 CNCF 技术监督委员会的中国工程师,致力于推动云原生技术的落地。

    最大的容器集群和客户群体

    除了支持集团内部应用规模化运维,阿里云云原生技术还向全社会输出。阿里云 ACK(容器服务)遍布全球 18 个 region,拥有国内最大公共云容器集群以及客户群体。

    边缘容器、云原生应用管理与交付体系

    大会期间,阿里云重磅发布边缘容器(ACK@Edge)和云原生应用管理与交付体系,进一步扩大云原生应用场景,并提升企业的云上应用开发效率。

    丁宇认为:“随着 5G 和物联网时代的到来,传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求。将云计算的能力下沉到边缘侧、设备侧,并通过中心进行统一交付、运维、管控,将是云计算的重要发展趋势。”

    边缘容器可实现云、边、端一体化的应用分发,支持不同系统架构和网络状况下,应用的分发和生命周期管理,并且针对边缘及设备进行如访问协议、同步机制、安全机制的种种优化。 该产品采用了自研高性能 Terway 网络插件,能将弹性网卡 ENI 分配给容器实例,使容器实例和 ECS 使用同一个网络平面,性能较传统的 overlay 容器网络高出 20%

    云原生应用管理与交付体系涵盖国内首个开放云原生应用中心 Cloud Native App Hub、云原生应用自动化引擎 OpenKruise 等服务。

    其中,OpenKruise 开源项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践,同时解决了 Kubernetes 之上应用的自动化管理问题。OpenKruise 后续会继续覆盖部署、升级、弹性扩缩容、QoS 调节、健康检查,迁移修复等更多 K8s 自动化能力。

    广泛的云原生应用实践

    全链路压测、极速弹性扩缩容以及云原生的全栈技术已广泛服务于互联网、金融、零售、制造、政务等领域企业和机构,大幅降低了应用开发的门槛,让企业轻松享受云的技术红利。

    例如,企业可以通过云原生架构简化云上预演及实战,提升应对流量高峰的效率及可靠性,使用阿里云 ACK 可在容器应用层面实现业务高弹性,还可以通过 PolarDB 实现数据库的横向纵向扩缩容,通过 PTS 性能测试服务模拟真实业务流量进行全链路压力测试。

    奥组委通过容器服务 ACK,在欧洲助力奥运 OCS 频道敏捷开发高效运维;西门子使用阿里云 ACK,实现开放式物联网操作系统 MindSphere 微服务架构、DevOps 以及系统的高可用;迅雷使用容器混合云方案,完成云下及云上混合部署和调度,在享受极致弹性的同时降低成本。

    坚持探索与落地并重,阿里巴巴云原生之路全景揭秘

    本文根据 2019年6月26日 KubeCon China 大会上李响 Keynote 演讲稿整理。
    演讲人简介:李响,CNCF TOC Member (CNCF技术监督委员会成员),阿里云资深技术专家,etcd 项目作者,曾就职于 CoreOS,现负责阿里巴巴大规模容器编排与调度引擎的相关技术工作。

    为什么要做云原生?云原生究竟能带来什么价值?从最初的独自摸索到如今拥抱开源回馈社区,阿里巴巴走过了怎样的云原生旅程?又有哪些技术心得?今天,将全部分享出来。

    多年沉淀,坚持探索与落地并重


    阿里巴巴从 2011 年开始通过容器实践云原生技术体系,在整个业界都还没有任何范例可供参考的大背境下,逐渐摸索出了一套比肩全球一线技术公司并且服务于整个阿里集团的容器化基础设施架构。这个探索历程虽然孤独,但却被始终如一的坚持至今。这正是在这个孤注一掷的技术探索与奋进的过程中,阿里巴巴的技术团队完整的经历了云原生技术浪潮里的所有关键节点,不仅成为了这次技术革命的重要见证者,也逐渐成为中国云原生技术体系当之无愧的推动者与引领者之一。

    阿里的体量大、业务复杂,推动云原生要找到合适的切入点。在双十一成本压力的推动下,资源成本与效率优化成了阿里云原生的起点。

    阿里从容器入手,研究低成本虚拟化与调度技术:提供灵活、标准的部署单元;将静态资源分配更换为动态按需调度,进一步提升部署效率,解决资源碎片化问题,提高部署密度;通过存储网络虚拟化和存储计算分离等技术,增强任务的可迁移性,进一步提高了资源的可靠性,降低了资源成本。

    在资源成本的推动下,阿里完成了全面容器化,资源分配也被高效调度平台接管。阿里的云原生并未止步于此。提高研发效率与加快迭代周期是推动阿里业务增强的秘密武器。阿里希望通过云原生让开发者效率更高。

    为了降低应用部署难度,提高部署自动化程度,阿里开始采用 Kubernetes 作为容器编排平台,并且持续推动 Kubernetes 的性能与可扩展性。具体 Kubernetes,阿里持续对研发、部署流程进行改进。为了构建更云原生化的 CI/CD,进一步做到标准化和自动化,从研发到上线流程,阿里引入了诸如 Helm 的应用标准化管理,也尝试了 GitOps 这样的部署流程,还推动了 PaaS 层的面向终态自动化改造。于此同时,阿里也开始探索服务网格,致力于进一步提高服务治理的普适性与标准性,降低开发者采用门槛,进一步推动微服务在多语言和多环境下的普及。

    今年,阿里也展开了全站上云。经过云原生的探索与改造,阿里基础架构体系是现代化和标准化的。利用容器技术,应用与宿主机运行时完成了解耦;利用 Kubernetes 对 Pod 与 Volume 等的抽象,完成了对多种资源实现的统一化;通过智能调度与 PaaS 平台,让自动迁移应用,修复不稳定因素成为了可能,阿里通过云原生技术大大降低了上云的难度。

    在这个提高资源和人员效率的过程中,阿里巴巴的整个基础设施也变得更加开放,连通开源生态,在交流互动中不断吸收和贡献好的理念、技术、思想。如今,阿里云不仅支撑着中国最大的云原生应用双 11,而且拥有国内最大的公共云集群和镜像仓库。作为唯一入选 Gartner 的公有云容器服务竞争格局的厂商,阿里云也积累了最为丰富和宝贵的客户实践。

    追求极致,优化扩展性和规模性

    弹性和规模性,这是支撑阿里巴巴各种类型的复杂场景以及流量高峰的关键因素。

    经过不断打磨,阿里巴巴在 Kubernetes 规模与性能上取得了显著的成果:将存储object 的数量提升 25倍,支持的节点数从 5000 提升到上万,在端到端调度延迟从5s 变为 100ms 等等。其中有不少工作在阿里巴巴和社区中共同开展,而这些研发成果都已经贡献给社区,我们期望其他企业及开发者也可以享受阿里巴巴规模所带来的技术红利。

    阿里巴巴持续优化性能,可以分为以下四个维度:工作负载追踪、性能分析、定制化调度、大规模镜像分发。首先对工作负载调度有完整的追踪、重放机制,其次将所有性能问题的进行细致分析,逐一攻克技术瓶颈。Kubernetes 本身的可定制性很强,阿里巴巴针对自身业务场景沉淀了定制化的调度能力和镜像分发系统。开源Dragonfly 项目脱胎于双十一,具备极强的镜像分发能力。数十个超级集群,每个超级集群具有数万节点,数百万的容器。

    阿里巴巴落地 Kubernetes 可以分为三个阶段:首先通过 Kubernetes 提供资源供给,但是不过多干扰运维流程,这系统容器是富容器,将镜像标准化与轻量级虚拟化能力带给了上面的 PaaS 平台。第二步,通过 Kubernetes controller 的形式改造PaaS 平台的运维流程,给 PaaS 带来更强的面向终态的自动化能力。最后把运行环境等传统重模式改成原生容器与 pod 的轻量模式,同时将 PaaS 能力完全移交给Kubernetes controller,从而形成一个完全云原生的架构体系。

    如何解决云原生的关键难点

    阿里巴巴云原生的探索,起步于自研容器和调度系统,到如今拥抱开源的标准化技术。对于当下开发者的建议是:如果想构建云原生架构,建议直接从 Kubernetes 入手即可。一方面,Kubernetes 为平台建设者而生,已经成为云原生生态的中流砥柱,它不仅向下屏蔽了底层细节,而且向上支撑各种周边业务生态;另一方面,更重要的是社区中有着越来越多围绕 Kubernetes 构建的开源项目,比如Service Mesh、Kubeflow。

    那么作为过来人,阿里有哪些“避坑指南”呢?

    原生技术架构演进中最为艰难的挑战,其实来自于 Kubernetes 本身的管理。因为 Kubernetes 相对年轻,其自身的运维管理系统生态尚不完善。对于阿里而言,数以万计的集群管理至关重要,我们探索并总结了四个方法:Kubernetes on Kubernetes,利用 K8s 来管理 K8s 自身;节点发布回滚策略,按规则要求灰度发布;将环境进行镜像切分,分为模拟环境和生产环境;并且在监控侧下足功夫,将Kubernetes 变得更白盒化和透明化,及早发现问题、预防问题、解决问题。

    另外一个关键技术问题是 Kubernetes 的多租户管理。相比于 namespace 扩展性差和命名冲突等限制,可以在 Kubernetes 之上建立虚拟集群。在提高扩展性的同时,能够做到 API 层面的强隔离,通过 syncer 链接虚拟集群和真实集群,在 node 添加 agent,达到更好的多租管理和更好的利用。

    此次 KubeCon 大会上,阿里云重磅公布了两个项目:Cloud Native App Hub —— 面向所有开发者的 Kubernetes 应用管理中心,OpenKruise —— 源自全球顶级互联网场景的 Kubernetes 自动化开源项目集。

    OpenKruise 开源地址:https://github.com/openkruise/kruise
    Cloud Native App Hub:https://developer.aliyun.com/hub

    云原生应用中心(Cloud Native App Hub),可以简单理解为 Helm 应用中国镜像站,方便用户获得应用资源,并大大简化了 Kubernetes 部署安装一个应用的步骤;OpenKruise/Kruise 项目致力于成为“云原生应用自动化引擎”,解决大规模应用场景下的诸多运维痛点。这次沙龙首秀,开发者们体验了从云原生应用中心快速下载应用,并通过带状态pod 原地升级、sidecar 容器注入、节点镜像预热等三个场景,实际体验了 Kruise 强大的自动化运维能力。

    值得一提的是,OpenKruise 项目源自于阿里巴巴经济体过去多年的大规模应用部署、发布与管理的最佳实践;源于容器平台团队对集团应用规模化运维,规模化建站的能力;源于阿里云 Kubernetes 服务数千客户的需求沉淀。从不同维度解决了 Kubernetes 之上应用的自动化问题,包括部署、升级、弹性扩缩容、QoS 调节、健康检查,迁移修复等等。

    最后,给大家来个云原生的干货:

    9 年云原生实践全景揭秘|《阿里巴巴云原生实践 15 讲》正式开放下载

    展开全文
  • 云原生是什么?细数云原生的5大特征00 云原生是什么?01 轻、快、不变的基础设施02 弹性服务编排03 开发运营一体化04 微服务架构05 无服务模型 来源:大数据DT 导读:随着公有云和私有云的广泛部署,云计算基础...

    来源:大数据DT

    导读:随着公有云和私有云的广泛部署,云计算基础设施成为企业部署新业务的首选。可以说,云计算已进入下半场,各大云计算服务商的厮杀日益激烈,新的概念也层出不穷。

    近年来,云原生计算(Cloud Native Computing)越来越多地出现在人们的视野中,可以说云原生是云计算时代的下半场,或许我们可以称之为云计算2.0。云原生的出现是云计算不断与具体业务场景融合,与开发运营一体化碰撞的结果,是一场由业务驱动的对云端基础设施、编排体系的重构。

    00 云原生是什么?

    近年来,云计算模式逐渐被业界认可和接受。在国内,包括政府、金融、通信、能源在内的众多领域的大型机构和企业,以及中小企业,均对其托管业务的基础设施进行了不同程度的云化。

    但它们大多数利用开源或商业的IaaS系统构建云计算平台,只是简单地将传统物理主机、平台或应用转为虚拟化形态。这种方式所带来的好处是整体资源的利用更加合理,且集约式的运营会降低成本,提升整体运营效率和成熟度。但总体而言,这样的上云实践只是“形”上的改变,还远没有达到“神”上的变化。

    在云计算的下半场,应该充分利用云计算弹性、敏捷、资源池和服务化等特性,解决业务在开发、运行整个生命周期中遇到的问题。毕竟,业务中出现的问题才是真正的问题。

    比如,传统应用有升级缓慢、架构臃肿、无法快速迭代等问题,于是云原生的概念应运而生。笔者认为云原生就是云计算的下半场,谁赢得云原生的赛道,谁才真正赢得了云计算。

    谈到云原生,不能不提始终推动云原生发展的CNCF(Cloud Native Computing Foundation,云原生计算基金会)。CNCF是一个孵化、运营云原生生态的中立组织。截止到2020年,CNCF共有371个开源项目、1402个项目和组织,可以说是一个覆盖面相当广的云计算组织。

    CNCF对云原生的见解是:

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

    云原生提倡应用的敏捷、可靠、高弹性、易扩展以及持续更新 。在云原生应用和服务平台的构建过程中,近年兴起的容器技术凭借其高弹性、敏捷的特性以及活跃、强大的社区支持,成为云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端应用的设计、开发和运行,从而重构云上业务模式。

    不同于以虚拟化为基础的传统云计算系统,云原生系统一般有如下特征。

    01 轻、快、不变的基础设施

    在云原生环境中,支撑基础设施通常是容器技术。容器生命周期极短,大部分是以秒或分钟为单位,占用的资源也比虚拟化小得多,所以容器的最大特点就是轻和快。

    而正是因为容器有轻和快的特点,在实践中通常不会在容器中安装或更新应用,而是更新更为持久化的镜像,通过编排系统下载新镜像并启动相应的容器,并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变的基础设施(immutable infrastructure)。从不变的基础设施就能看出,云原生的运营与传统虚拟机运营方式截然不同。
    在这里插入图片描述

    02 弹性服务编排

    云原生的焦点是业务,而非基础设施,而业务的最核心之处是业务管理和控制,如服务暴露、负载均衡、应用更新、应用扩容、灰度发布等。服务编排(orchestration) 提供了分布式的计算、存储和网络资源管理功能,可以按需、弹性地控制服务的位置、容量、版本,监控并保证业务的可访问性。

    服务编排对应用层隐藏了底层基础设施的细节,但又提供了强大的业务支撑能力,以及让业务正常运行的容错、扩容、升级的能力,使开发者可以聚焦业务本身的逻辑。

    03 开发运营一体化

    开发运营一体化(DevOps) 是一组将软件开发和IT运营相结合的实践,目标在于缩短软件开发周期,并提供高质量软件的持续交付。虽然DevOps不等同于敏捷开发,但它是敏捷开发的有益补充,很多DevOps的开发理念(如自动化构建和测试、持续集成和持续交付等)来自敏捷开发。

    与敏捷开发不同的是,DevOps更多的是在消除开发和运营侧的隔阂,聚焦于加速软件部署。

    当前,很多云原生应用的业务逻辑需要及时调整,功能需要快速丰富和完善,云端软件快速迭代,云应用开发后需要快速交付部署,因而开发运营一体化深深地融入云原生应用整个生命周期中。
    在这里插入图片描述

    04 微服务架构

    传统Web应用通常为单体应用系统,如使用WebSphere、WebLogic或.Net Framework等,从前端到中间件再到后端,各个组件一般集中式地部署在服务器上。

    后来随着Web Service标准的推出,应用以标准的服务交付,应用间通过远程服务调用(RPC)进行交互,形成了面向服务的架构(Service-Oriented Architecture,SOA),极大提升了应用组件的标准化程度和系统集成效率。

    在云原生应用设计中,应用体量更小,因而传统单体应用的功能被拆解成大量独立、细粒度的服务。

    微服务架构使得每个服务聚焦在自己的功能上,做到小而精,然后通过应用编排组装,进而实现等价于传统单体应用的复杂功能。其优点是后续业务修改时可复用现有的微服务,而不需要关心其内部实现,可最大限度地减少重构开销

    05 无服务模型

    无服务(Serverless) 是一种基于代码和计算任务执行的云计算抽象模型,与之相对的是基于服务器(虚拟机、容器)的计算模式。

    无服务在公有云和私有云上都有相应的服务,如AWS Lambda、阿里云的函数计算、Kubernetes的Kubeless、Apache OpenWhisk等。无服务聚焦在函数计算,隐藏了底层复杂的实现方式,使开发者能够聚焦于业务本身。
    在这里插入图片描述

    小结

    总体而言,云原生真正以云的模式管理和部署资源,用户看到的将不是一个个IT系统/虚拟主机,而是一个个业务单元,开发者只需要聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现,而容器、编排、服务网格均是实现云原生的支撑技术

    展开全文
  • Rainbond 是云原生且易用的云原生应用管理平台,云原生应用交付的最佳实践,简单易用。专注于以应用为中心的理念。赋能企业搭建云原生开发云、云原生交付云。 对于企业: Rainbond 是开箱即用的云原生平台,借助 ...
  • 盘点云原生的5大特征

    2021-11-09 00:09:10
    导读:随着公有云和私有云的广泛部署,云计算基础设施成为企业部署新业务的首选。可以说,云计算已进入下半场,各大云计算服务商的厮杀日益激烈,新的概念也层出不穷。近年来,云原生计算(Cloud ...

    导读:随着公有云和私有云的广泛部署,云计算基础设施成为企业部署新业务的首选。可以说,云计算已进入下半场,各大云计算服务商的厮杀日益激烈,新的概念也层出不穷。

    近年来,云原生计算(Cloud Native Computing)越来越多地出现在人们的视野中,可以说云原生是云计算时代的下半场,或许我们可以称之为云计算2.0。云原生的出现是云计算不断与具体业务场景融合,与开发运营一体化碰撞的结果,是一场由业务驱动的对云端基础设施、编排体系的重构。

    作者:刘文懋 江国龙 浦明 阮博男 叶晓虎

    来源:大数据DT(ID:hzdashuju)

    aa7a4ca9187512a38e26a942d0f79c88.png

    近年来,云计算模式逐渐被业界认可和接受。在国内,包括政府、金融、通信、能源在内的众多领域的大型机构和企业,以及中小企业,均对其托管业务的基础设施进行了不同程度的云化。

    但它们大多数利用开源或商业的IaaS系统构建云计算平台,只是简单地将传统物理主机、平台或应用转为虚拟化形态。这种方式所带来的好处是整体资源的利用更加合理,且集约式的运营会降低成本,提升整体运营效率和成熟度。但总体而言,这样的上云实践只是“形”上的改变,还远没有达到“神”上的变化。

    在云计算的下半场,应该充分利用云计算弹性、敏捷、资源池和服务化等特性,解决业务在开发、运行整个生命周期中遇到的问题。毕竟,业务中出现的问题才是真正的问题。

    比如,传统应用有升级缓慢、架构臃肿、无法快速迭代等问题,于是云原生的概念应运而生。笔者认为云原生就是云计算的下半场,谁赢得云原生的赛道,谁才真正赢得了云计算。

    谈到云原生,不能不提始终推动云原生发展的CNCF(Cloud Native Computing Foundation,云原生计算基金会)。CNCF是一个孵化、运营云原生生态的中立组织。截止到2020年,CNCF共有371个开源项目、1402个项目和组织,可以说是一个覆盖面相当广的云计算组织。

    CNCF对云原生的见解是:

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

    云原生提倡应用的敏捷、可靠、高弹性、易扩展以及持续更新。在云原生应用和服务平台的构建过程中,近年兴起的容器技术凭借其高弹性、敏捷的特性以及活跃、强大的社区支持,成为云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端应用的设计、开发和运行,从而重构云上业务模式。

    不同于以虚拟化为基础的传统云计算系统,云原生系统一般有如下特征。

    01 轻、快、不变的基础设施

    在云原生环境中,支撑基础设施通常是容器技术。容器生命周期极短,大部分是以秒或分钟为单位,占用的资源也比虚拟化小得多,所以容器的最大特点就是轻和快。

    而正是因为容器有轻和快的特点,在实践中通常不会在容器中安装或更新应用,而是更新更为持久化的镜像,通过编排系统下载新镜像并启动相应的容器,并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变的基础设施(immutable infrastructure)。从不变的基础设施就能看出,云原生的运营与传统虚拟机运营方式截然不同。

    e55d6927f7016af9c2bce2a3e368bf60.png

    02 弹性服务编排

    云原生的焦点是业务,而非基础设施,而业务的最核心之处是业务管理和控制,如服务暴露、负载均衡、应用更新、应用扩容、灰度发布等。服务编排(orchestration)提供了分布式的计算、存储和网络资源管理功能,可以按需、弹性地控制服务的位置、容量、版本,监控并保证业务的可访问性。

    服务编排对应用层隐藏了底层基础设施的细节,但又提供了强大的业务支撑能力,以及让业务正常运行的容错、扩容、升级的能力,使开发者可以聚焦业务本身的逻辑。

    03 开发运营一体化

    开发运营一体化(DevOps)是一组将软件开发和IT运营相结合的实践,目标在于缩短软件开发周期,并提供高质量软件的持续交付。虽然DevOps不等同于敏捷开发,但它是敏捷开发的有益补充,很多DevOps的开发理念(如自动化构建和测试、持续集成和持续交付等)来自敏捷开发。

    与敏捷开发不同的是,DevOps更多的是在消除开发和运营侧的隔阂,聚焦于加速软件部署。

    当前,很多云原生应用的业务逻辑需要及时调整,功能需要快速丰富和完善,云端软件快速迭代,云应用开发后需要快速交付部署,因而开发运营一体化深深地融入云原生应用整个生命周期中。

    654fde0f52a38539143dd8d161df4565.png

    04 微服务架构

    传统Web应用通常为单体应用系统,如使用WebSphere、WebLogic或.Net Framework等,从前端到中间件再到后端,各个组件一般集中式地部署在服务器上。

    后来随着Web Service标准的推出,应用以标准的服务交付,应用间通过远程服务调用(RPC)进行交互,形成了面向服务的架构(Service-Oriented Architecture,SOA),极大提升了应用组件的标准化程度和系统集成效率。

    在云原生应用设计中,应用体量更小,因而传统单体应用的功能被拆解成大量独立、细粒度的服务。

    微服务架构使得每个服务聚焦在自己的功能上,做到小而精,然后通过应用编排组装,进而实现等价于传统单体应用的复杂功能。其优点是后续业务修改时可复用现有的微服务,而不需要关心其内部实现,可最大限度地减少重构开销。

    05 无服务模型

    无服务(Serverless)是一种基于代码和计算任务执行的云计算抽象模型,与之相对的是基于服务器(虚拟机、容器)的计算模式。

    无服务在公有云和私有云上都有相应的服务,如AWS Lambda、阿里云的函数计算、Kubernetes的Kubeless、Apache OpenWhisk等。无服务聚焦在函数计算,隐藏了底层复杂的实现方式,使开发者能够聚焦于业务本身。

    9af352a8826938699296f5f3ac31f5bd.png

    总体而言,云原生真正以云的模式管理和部署资源,用户看到的将不是一个个IT系统/虚拟主机,而是一个个业务单元,开发者只需要聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现,而容器、编排、服务网格均是实现云原生的支撑技术。

    关于作者:刘文懋,绿盟科技集团首席安全专家、创新中心与星云实验室负责人,计算机学会(CCF)理事,中国网络空间安全人才教育论坛人才标准认证工作组专家,中国网络空间新兴技术安全创新论坛理事,云安全联盟(CSA)云安全服务管理工作组联合主席。曾发表著作《软件定义安全:SDN/NFV新型网络的安全揭秘》。

    江国龙,资深研究员和架构师,主要研究方向包括虚拟化网络安全、云计算系统安全、云原生安全、5G/边缘计算安全等。作为核心人员,参与编写了多份云安全相关白皮书、技术报告、技术标准。积极活跃于云原生安全社区,热衷于技术探索和分享。

    浦明,绿盟科技集团星云实验室资深安全研究员,在云原生应用安全及安全创新领域有丰富的实战经验,长期从事Kubernetes、微服务、服务网格安全的研究。在绿盟科技任职期间,参与过安全应用商店、安全编排与自动化响应(SOAR)平台、容器安全、安全产品云原生化的架构设计和研发工作。

    阮博男,绿盟科技集团星云实验室安全研究员,主要研究方向为云和虚拟化安全,积极探索Linux、云、虚拟化及前沿安全攻防技术。曾作为核心人员参与绿盟科技的SOAR、容器安全、云原生入侵检测等项目和产品。

    叶晓虎,绿盟科技集团首席技术官,先后担任国家火炬计划课题负责人、北京市下一代网络安全软件与系统工程技术研究中心主任、海淀区重大科技成果产业化负责人等。在信息安全管理、安全架构和技术方面有将近20年的经验,并且作为安全专家多次参与国家级重大事件网络安全保障工作。

    本文摘编自《云原生安全:攻防实践与体系构建》,经出版方授权发布。(ISBN:9787111691839)

    64b370e3070bca39af86893c54557fdc.png

    《云原生安全:攻防实践与体系构建》

    点击上图了解及购买

    转载请联系微信:DoctorData

    推荐语:本书介绍了云原生的容器基础设施、K8S编排系统和常见云原生应用体系;在介绍安全体系前先深入分析了前述架构各个层面的安全风险,并给出攻击实践,后续计划开放靶场环境,有很好的可操作性和说服力;在介绍安全体系时,首先从高层分析新型基础设施防护的思路切换,然后分为两个维度介绍相关的安全机制,清晰地拆解了复杂的安全技术栈,让读者很容易理解DevOps安全和云原生安全两者如何融合。

    21ebab4828bc55e27e2c428ad4364762.gif

    刷刷视频👇

    干货直达👇

    更多精彩👇

    在公众号对话框输入以下关键词

    查看更多优质内容!

    读书 | 书单 | 干货 讲明白 | 神操作 | 手把手

    大数据 | 云计算 | 数据库 | Python | 爬虫 | 可视化

    AI | 人工智能 | 机器学习 | 深度学习 | NLP

    5G | 中台 | 用户画像 数学 | 算法 数字孪生

    据统计,99%的大咖都关注了这个公众号

    👇

    展开全文
  • Docker 和 云原生 一、概念介绍 1.1 Docker Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的 Linux或Windows操作系统的机器上,也可以实现虚拟...
  • 什么是 云原生应用

    千次阅读 2021-02-02 09:28:35
    云原生意味着应用程序原生就被设计为在云上以最佳方式运行。 云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥云计算的优势。这些应用特点是可以实现快速和频繁的构建、发布、部署,...
  • 阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇表示,如果用三个词来形容我们希望达到的效果,就是连接、合作、赋能。
  • 因为现在有很多的机会让我们接触到公有云(阿里云/腾讯云等)或是私有云,那我们对于应用的管理方式是不是也应该有一种当下的方式,我们就称其为云原生的方式。因为云技术在不断发展的情况下,逐渐成熟,也促进很多...
  • 一文搞懂云原生架构

    多人点赞 热门讨论 2022-05-26 15:36:58
    在当今瞬息万变的大数据信息世界中,云原生架构不再是可选的,而是必需的。...建议在正确的领域实施正确的自动化,充分利用托管服务,整合 DevOps 最佳实践,并应用最佳的云原生应用程序架构模式。
  • 未来的应用都将应该生在上,长在上,应用上云成为不可逆转的发展趋势。
  • 本书首先梳理了云原生技术理念特点以及与传统架构的对比,然后分析了深度学习、区块链、边缘计算和传统行业的互联网化应用等典型应用场景的特征,旨在从架构、研发流程等角度为企业或组织从传统单体架构过渡到云原生...
  • 云原生技术应用产生了新的云安全需求,CISO 要在竞争激烈的云原生市场中确保业务安全。传统的防火墙、反病毒、服务器监控、终端检测响应和SIEM等安全产品,与云原生的适配性较好,容易部署上云。但工作负载安全、...
  • 为了能够给大家尽可能说出云原生是个什么东西,我读了很多很多文章,拜访了很多名家,包括业界的知名大佬、年薪千万的骨灰级专家、名下数十万记学生的成功学大师,真是生怕自己才疏学浅耽误了大家,所以我希望大家能...
  • 这不仅有助于增强我们的.NET社区,而且可以提高全球.NET开发人员的云原生应用程序开发技能。 非常感谢你 :thumbs_up: 查看我的或在招呼! 产品特点 简单的库。 没有框架。 一点抽象。 使用“技术选择启用和启用...
  • 在MEC全球应用开发者大会的“MEC开放论坛”上,阿里云高级技术专家周哲进行了《阿里边缘云原生应用实践》主题分享,站在技术视角对边缘云原生的技术概念、应用场景、阿里云边缘云原生实践案例等多方面进行解读。...
  • 都在说云原生?到底什么是云原生

    千次阅读 多人点赞 2022-04-10 13:03:43
    原来这就是云原生,还以为是有多么的高大上,还好还好,看完也不是那么难理解
  • 什么是云原生云原生(Cloud Native)是由 Pivotal 的Matt Stine在2013年提出的一个概念,...云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务(IaaS)、平台即服务(Pa...
  • 云原生应用的核心要素

    千次阅读 2020-03-26 00:17:00
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生,而针对云原生应用开发的最佳实践原则,12-Factor脱颖而出,同时也带来了新的解读。 12-Factor...
  • 云计算是信息技术发展和服务模式创新的集中体现,是信息化发展的重要变革和必然...云原生以其高效稳定、快速响应的特点极大地释放了云计算效能,成为企业数字业务应用创新的原动力,有效推动了国民经济的高质量发展。
  • 云原生应用的12要素

    万次阅读 2018-03-12 21:33:40
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生,而针对云原生应用开发的最佳实践原则,12-Factor脱颖而出,同时也带来了新的解读。 12-Factor...
  • 云原生的入门知识

    2022-06-02 15:58:42
    近年来,随着云计算概念和技术的普及,云原生一词也越来越热门,无论是应用还是安全,凡是和云相关的,都要在云后面加上原生二字,好像不提云原生,在技术上就落后了一大截。那到底什么是云原生云原生是怎么产生的...
  • 云原生数据库介绍

    千次阅读 2022-01-22 22:46:29
    文章目录数据库系统发展行业趋势:云原生+分布式云原生概念数据库在云原生时代面临的挑战云原生数据库具有的主要技术特点1. 分层架构2. 资源解耦与池化3. 弹性伸缩能力4. 高可用与数据一致性5. 多租户与资源隔离6. ...
  • 第1章 云原生Cloud Native的字面解读 第2章 云原生诞生的背景 2.1 云原生的诞生源于互联网业务发展的需求: 2.2 业务运营企业面临的挑战: 2.3 应对上述问题的技术和软件工程措施 第3章 技术人员为什么要了解...
  • 这也就是今天为大家推荐的《gRPC与云原生应用开发:以 Go 和 Java 为例》。 卡山·因德拉西里 丹尼什·库鲁普 著 张卫滨 译 在介绍这本书之前,我们先来聊聊 gRPC 是怎样的一个存在,以及为什么值得选择它。 2015 年...
  • 云原生应用概念解析

    千次阅读 2020-03-26 00:35:07
    什么是云原生云原生(Cloud Native)是由 Pivotal 的Matt Stine在2013年提出的一个概念,是他...云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务(IaaS)、平台即服务...
  • 文章目录前言 前言 ...本文整理自华为社区【内容共创】活动第14期。 查看活动详情:https://bbs.huaweicloud.com/blogs/336904 相关任务详情:任务16.企业核心业务未来架构演进路线及华为方案
  • 云原生应用开发框架Quarkus介绍 1. 概述 Quarkus 是一个为 Java 虚拟机(JVM)和原生编译而设计的全堆栈Kubernetes云原生Java框架,用于专门针对容器优化的Java开发框架,并使其成为 serverless、cloud和Kubernetes...
  • 【阿里云·云原生架构·白皮书】 对白皮书的一些总结和解读。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,770
精华内容 9,508
关键字:

云原生应用的特点