什么是云原生？

开源字节

于 2024-07-31 14:42:12 发布

阅读量712

点赞数 9

文章标签：云原生

本文链接：https://blog.csdn.net/qq_35634154/article/details/140822621

版权

自进入云计算时代后，大量的新概念、新技术如雨后春笋般的涌现出来，从早期的openstack、IAAS平台，到中期的容器技术、微服务架构，再到现在的servicemesh服务网格技术、serverless无服务器架构、云原生技术，可谓在云计算的时代，我们从未停下前进的步伐。而今天要给大家带来的便是云原生技术。

那么什么是云原生呢？我们将名词拆成两部分—云、原生，这些是相对于本地应用来的，云是相对于本地而言的，传统的应用都是运行在本地机房的服务器上，而云的应用则是运行在云端（如IAAS、PAAS、SAAS）。

原生就是亲生的、土生土长的意思，即应用一诞生就是基于云的，可以直接在云平台上运行或非常轻松的迁移到云平台。

我们可以这么来定义云原生：一套新的技术体系、一种新的工作方法论、云计算发生的必然导向。

云原生应用要运行在云平台，那么就必须要有云的特点，比如弹性伸缩、分布式、快速部署、快速迭代、高效、持续。这可不止是简单的把原先在物理服务器上的应用迁移到虚拟机里，不止是基础设施和运行平台在云上，应用架构、应用开发方式、应用部署方式、应用维护方式全都要做出改变。

云原生的四大核心要素便是微服务技术、DevOps、持续交付、容器化。微服务技术使得应用原子化，所有的应用都可以独立的部署、迭代。DevOps使得应用可以快速编译、自动化测试、部署、发布、回滚，让开发和运维一体化。持续交付让应用可以频繁发布、快速交付、快速反馈、降低发布风险。容器使得应用整体开发以容器为基础，形成代码组件复用、资源隔离。接下来我们就好好的侃侃这几门技术。

微服务

微服务的定义是独立部署的、原子的、自治的业务组件，业务组件彼此之间通过消息中间件进行交互，业务组件可以按需独立伸缩、容错、故障恢复。

微服务架构的演变可从早期的单体式架构、中期的SOA架构、后期的微服务架构来看。客户提出一个需求时，早期的做法是直接往现有的代码包里加东西，客户来一个需求，程序员们就写一串代码在里面，来十个写十串，来一百个写100串，反正就是不断的加，最后我们的应用就变成了一个巨无霸应用，要往里面再加东西很难，要保证全面测试无误很难，要保证按期上线很难，要保证线上出现了问题快速解决也很难，因为牵一发而动全身，即使是技术精湛的程序员也不敢轻易的下手做了。

新的解决方案是SOA架构（ServiceOrientedArchitecture面向服务的架构），即将业务服务化、抽象化，将整个业务拆分成不同的服务，服务与服务之间通过相互依赖提供一系列的功能，通过网络调用。常用的实现方式是使用ESB（EnterpriseServiceBus企业服务总线）来把各个服务节点，集成不同系统、不同协议的服务，通过ESB将消息进行转化，实现不同的服务互相交互。这个方案很大程度上解决了巨无霸应用的问题，但是对于ESB的维护成本却比较高。

云计算时代的到来推动应用“高内聚，低耦合”，高内聚就是熟悉同一块业务的人、提供用一个服务的模块聚合在一起，低耦合就是应用与应用之间没有紧密强依赖关系，而高内聚低耦合的最佳实践便是微服务架构。通过将服务拆分成单独的服务，小型团队可专注于自己的功能开发上线，运维团队也可根据服务的调用情况弹性扩缩容，符合云计算时代的特色，确定是云原生的特性之一了。

DevOps

DevOps的定义是研发运维一体化，通过自动化流程使得软件过程更加快捷和可靠。它不是一个产品，而是一种新的团队工作方式、新的技术理念。

一个软件从0到1的最终交付包含如下阶段：市场规划、产品规划、编码设计、编译构建、部署测试、发布上线、后期维护。

早期的时候全由一个人完成了，这个人一般都是CEO了，他根据对市场的洞察感知有了好的idea，自己开发编码，编译打包，进行测试之后在云厂商上买一两台服务器部署上应用就对外发布了，这就是瀑布式开发模型，确认好需求后就进入开发阶段，直到完成上线。

而随着使用人群的增加，应用的整体维护开始变得艰难，因为CEO对外要去扩展业务、对内要继续开发、继续维护应用，一个人实在干不过来了。

慢慢的团队里有了产品经理、开发人员、测试人员、运维人员的划分，由产品经理负责需求的规划、产品交互设计，研发人员负责编码、构建包，测试人员负责功能测试和自动化测试、上线发布，运维人员负责维护线上服务的正常运行、扩容缩容，这就是敏捷开发模型，在开发过程阶段测试介入，快速验证修改问题直到基本无误后上线部署。这一切所带来的问题是整体的交付周期变长了，团队之间沟通合作成本变高了，因此DevOps应运而生。它将整个软件开发测试运维过程变为一体化，每完成一个小的需求点便测试上线部署，快速验证需求，捕获用户，占领市场。

因此DevOps的出现是一种组织架构的变革，一种开发模式的变化，团队人员在需求规划、代码设计、编译构建、测试部署、上线发布、后期维护的过程全程参与，每个人都对整体的方案了解清晰，可制定合适的系统架构、技术架构、运维部署方案。

云计算时代的到来带来了虚拟化、容器、微服务等新的技术理念，强调的是服务的拆分、精细化的分工，奠定了DevOps落地的基础条件，只有当服务拆分的原子化了，整个团队密切合作的成本才会降低，才能实现云上应用的快速迭代，符合云计算时代的特色，确定是云原生的特性之二了。

持续交付

持续交付的定义就是一直在交付，敏捷开发和DevOps要求随时都有一个合适的版本部署在生产环节上，频繁发布、快速部署、快速验证，所以必须要持续交付。

持续交付出现的情况是需求迟迟不能确定从而缩短了开发时间，需求不能确定所带来的问题是在确定的过程中整个市场或用户已经发生了变化，开发出来的内容早已不符合当下用户的需求了。为了快速的验证需求，往往在生产环境上会部署多个版本，从而也产生了不同的发布部署方式，比如灰度发布、蓝绿发布。

所谓灰度发布便是当新的需求开发完成后，将线上的版本只升级部分服务，让一部分用户继续使用老版本，一部分使用新版本，如果用户对新版本没有意见，再迁移到新版本来，整个过程是运维人员从负载均衡上去掉灰度服务器，待服务升级成功后再加入负载均衡服务器列表，这时候有少量用户访问业务时流量到新版本，如果这小部分用户使用没有反对，逐渐扩大灰度范围，最后升级剩余服务器。

所谓蓝绿发布则是将应用从逻辑上分为A、B两组，升级时将A从负载均衡组里删除，进行新版本的部署，同时B组仍然继续提供服务。当A组升级完成后，负载均衡重新接入A组，再把B组从负载列表摘除，进行新版本的部署。A组重新提供服务。最后B组升级完成，负载均衡重新接入B组。此时AB组版本都升级完成，并且都对外提供服务。保障整个过程对用户无影响，出现问题及时回退上一个版本。

通过灰度发布和蓝绿发布的方式，可以快速的验证用户需求，频繁的发布，根据用户情况规划产品演变方向，实现了云计算时代的快速迭代，符合云计算时代的特色，确定是云原生的特性之三了。

容器化

容器技术的定义就是一个单独的应用程序进程、运行资源的高度隔离。早期的时候应用全运行在物理机上，这导致资源分配不均匀，即使是一个小的应用也要耗费同样的计算存储资源，中期的时候有了虚拟化技术将物理机划分为多个虚拟机，这样在一台物理服务器上可以运行多个虚拟服务器，实现了资源利用率的较大提升，而云计算时代的到来，带来了微服务、DevOps、持续集成持续交付等内容，要求应用要原子化、快速的开发迭代、快速的上线部署，划分为虚拟机的方式不能保障应用在每个环境（Dev、Test、Pre、Prod）都一致，容易引起应用因环境的问题而产生Bug，容器的出现极好的解决了这个问题。

在容器出现之后，整个的流程变成了研发人员在将代码开发完成后，会将代码、相关运行环境构建镜像，测试人员在宿主机上下载服务的镜像，使用容器启动镜像后即可运行服务进行测试；测试无误后运维人员申请机器，拉取服务器的镜像，在一台或多台宿主机上可以同时运行多个容器，对用户提供服务。在这个过程中每个服务都在独立的容器里运行，每台机器上都运行着相互不关联的容器，所有容器共享宿主机的cpu、磁盘、网络、内存等，即实现了进程隔离（每个服务独立运行）、文件系统隔离（容器目录修改不影响主机目录）、资源隔离（CPU内存磁盘网络资源独立）。

使用容器，研发团队可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性，实现了云计算时代的资源最大化利用，符合云计算时代的特色，确定是云原生的特性之四了。