精华内容
下载资源
问答
  • 云原生应用
    千次阅读 多人点赞
    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/
    拉勾:《云原生微服务架构实战精讲-成富》

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

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

    在这里插入图片描述

    更多相关内容
  • Kubernetes中文指南_云原生应用架构实践手册(201910).pdf
  • 基于Istio on Kubernetes云原生应用的最佳实践
  • 该文档非常详细的介绍了云原生应用的专业体系知识,涵盖了云原生应用设计,云原生架构原则,云原生应用平台,云原生中间件,云原生应用软件交付流程,这几部分的核心内容。
  • 2022阿里云原生应用交付与管理论坛资料汇总,共5份。 集群镜像重塑分布式应用交付 政采云私有化业务交付实践 Nacos2.0的k8s服务发现生态应用及规划 Open Cluster Management 开放模块化多集群管理平台 OpenKruise...
  • 2020QECon全球软件质量&效能大会,云原生工程质量中台专场郝树伟先生做的云原生应用全自动化渐进式交付的gitops实践分享报告的PPT文档,分享给大家!
  • 企业采用基于云原生的技术和管理方法,可以更好的把业务迁移到云平台,从而享受云的高效和按需资源能力,而容器云PaaS平台则是云原生应用重要的落地形态之一。企业在数字化转型中普遍面临IT系统架构缺乏弹性,
  • 迁移到云原生应用架构.pdf
  • 云原生从字面意思上来看可以分成云和原生两个部分。 云是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS,、PaaS和SaaS。 原生就是土生土长的意思,我们在开始设计应用的...
  • Rainbond 是云原生且易用的云原生应用管理平台,云原生应用交付的最佳实践,简单易用。专注于以应用为中心的理念。赋能企业搭建云原生开发云、云原生交付云。 对于企业: Rainbond 是开箱即用的云原生平台,借助 ...
  • 云原生应用开发原则与最佳实践指南.pdf
  • 云原生应用的设计理念已经被越来越多的开发者接受与认可,而Kubernetes做为云原生的标准接口实现,已经成为了整个stack的中心,云服务的能力可以通过CloudProvider、CRDController、Operator等等的方式从Kubernetes...
  • ;云原生定义;云原生代表技术;阿里云容器服务;高动态 高密度部署;公网域名;云原生资产安全托管 容器镜像安全扫描;云原生资产安全托管 容器镜像安全扫描;容器镜像服务企业版;20
  • 自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注...Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础设施分心,把更多的精力投入到业务逻辑上。
  • 通常,云原生应用程序构建为在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个部分,分别是云原生概述、云原生技术、云原生服务、云原生架构实践。本书兼顾理论、技术与实践,对从事相关行业的读者具有很好的学习指导意义。

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

    展开全文
  • 构建微服务云原生应用——介绍.pdf
  • 2.2.6 Golang大规模云原生应用管理实践@刘洋.pdf
  • 快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;快速交付云原生应用 包含原生kubernetes环境下应用的快速构建和发布;
  • 云原生应用的12要素

    2021-02-23 22:40:04
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生,而针对云原生应用开发的最佳实践原则,12-Factor脱颖而出,同时也带来了新的解读。12-Factor,...
  • 阿里巴巴新一代基于 Go 的云原生应用引擎实践.pdf
  • 构建微服务云原生应用——服务开发框架设计和实践.pdf
  • 2022云原生——云原生应用调研.pdf
  • 什么是 云原生应用

    千次阅读 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年6月15日,由中国信息通信研究院、中国通信标准化协会主办的“原生聚力,云数赋能”2022年云原生产业大会在线上召开。

    2022年6月15日,由中国信息通信研究院、中国通信标准化协会主办的“原生聚力,云数赋能”2022年云原生产业大会在线上召开。

    谐云凭借在云原生领域的创新技术和前瞻性实践,斩获多项荣誉。并作为云原生专家深度参与到「云原生金融行业论坛」及「云原生应用论坛」的主题演讲环节。

    ● 谐云为中石化打造的「天然气勘探开发工业应用基础底座」荣获“2022年度云原生应用优秀案例”。

    在这里插入图片描述

    ● 谐云为浦发银行搭建的「浦发容器安全平台」荣获“2022年度云原生安全优秀实践”。

    在这里插入图片描述

    连续三年上榜!

    至今,中国信通院已连续三年开展云原生优秀案例评选活动,而谐云凭优异成绩连续三年上榜。

    2022年度云原生应用优秀案例—携手中石化打造的「天然气勘探开发工业应用基础底座」
    2022年度云原生安全优秀实践—携手浦发银行搭建的「浦发容器安全平台」
    2021年度云原生应用优秀案例—携手上汽集团打造的「网络安全应急响应平台项目」
    2020年度云原生应用优秀案例—携手某在线服务公司搭建的「容器云PaaS平台」
    在这里插入图片描述
    在这里插入图片描述

    云原生优秀案例评选由专家评审团从云原生应用架构、技术创新点、应用效益等多维度全视角,通过严格的材料申报、专家初评、公开投票、复审答辩阶段进行综合评估,旨在了解国内企业对云原生理念和技术的应用实践情况,推广国内企业对云原生应用的宝贵经验。

    赋能石化能源领域

    此次荣获“2022年度云原生优秀案例”的「天然气勘探开发工业应用基础底座」,承载于K8s+Docker的云原生PaaS平台之上,结合了容器的标准化交付能力、容器云调度能力、负载均衡高可用能力、微服务的独立部署可治理能力,为企业实现在集成中台公共服务统一用户、统一权限在线配置、统一权限拦截管控等。同时,实现应用功能页、系统的快捷高效集成发布,大幅提升开发效率,减少业务开发周期。

    在这里插入图片描述

    天然气勘探开发工业应用基础底座平台架构图
    当前,平台已实现70余项云端赋能能力建设,沉淀工业组件260余个,聚合工业APP100余个,全面支撑工程管理、气田生产等业务域4大类14个业务系统的上云上平台以及组件化生态型应用建设,全面提升了客户信息系统的高可用能力及技术架构水平。

    银行业容器云部署

    此次荣获“2022年度云原生安全优秀实践”的「浦发容器安全平台」,是谐云基于原有安全防护体系的基础上,针对容器及其集群环境,从镜像构建、镜像仓库存储分发、容器创建运行等整个容器全生命周期进行安全防护。

    在这里插入图片描述

    HC-CSP 谐云容器安全平台架构图提供涵盖容器基础设施安全、镜像供应链安全、容器运行时防护、日志管理等一系列控制要求,形成在容器及其集群层面全面的安全防护能力,从而全面提升安全风险发现能力,提高安全事件实时处置水平,加快软件开发周期。

    展开全文
  • 2018 红帽论坛,超过500位客户亲临现场。演讲人 Alan Liu 高级解决方案架构师。
  • 下面将从云计算的发展历程引入云原生计算,请先看下图:云计算包含的内容十分繁杂,也有很多技术和公司牵强赴会说自己是云计算公司,说自己是做云的,实际上可能风马牛不相及。说白了,云计算就是一种配置资源的方式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,785
精华内容 41,514
关键字:

云原生应用

友情链接: 量水.rar