人尽皆知的云原生，到底是大势所趋还是过度炒作？

大家好，欢迎来到IT知识分享网。

当今云原生可谓是如火如荼，起码在互联网领域它是人尽皆知，那么云原生到底是时代的大势所趋还是过度炒作概念呢？相信当你看完这篇文章，心里会有答案。

传统云平台 VS 云原生

要知道，在云原生之前，IT/互联网领域中也是存在着云平台的，即基于虚拟化的传统云平台，典型的有 Openstack 等。在传统方式下，如果说一个企业生产应用，需要部署 100 台应用实例，那么它就得准备 100 个虚拟机，然后再将代码部署上去，最后为应用构建高可用的方案。这样无论生产还是运维耗费精力无疑都是巨大的。

了解过云原生的都知道，有一个核心概念容器，而传统云平台与云原生之间必须要关注的少不了容器与虚拟机之间的区别。

虚拟机即在宿主机/物理机的基础上装一个操作系统，操作系统之上部署 Hypervisor，由它再带起一个个承担应用的子系统。从这个层面来看它是很复杂的，如果系统出现了某些问题，我们需要去检测宿主机、虚拟机乃至 Hypervisor。

而且虚拟机是模拟完整的操作系统，这当然也包括了硬件驱动等等，资源需求很大，一个物理机可以开放的虚拟机是有限的。当我们要部署一个应用时，需要考虑该应用在并发高峰时可能需要需要多少资源，创建虚拟机时按照资源的最大需求进行设定，以防止虚拟机无法支撑应用。但在大部分时间内应用的资源需求并不会一直处于高峰，这就造成了资源利用率很低。

除此之外传统云平台其他各方面的缺陷也相当明显，诸如：

• 业务代码与基础架构割裂
• 虚拟机构建和业务代码相互分离
• 基础架构后期维护风险大
• 基础架构无法感知业务状态，升级维护困难
• 缺少自动化
• 需要自己构建应用的高可用方案
• 扩容缩容难
• 故障转移难

可见传统的云平台无论对于任何的操作、变更都是非常困难的，需要耗费大量的成本和人力。

而云原生正是为解决此问题而生，它鼓励在公有云、私有云、混合云等动态环境中构建和运行规模化应用，可以说云原生是一种思想，是技术和企业管理方法的总结。从技术层面来看：

• 应用程序从设计之初就在为上云而做好了准备
• 云平台基于自动化体系

云原生包含的核心技术栈有应用容器化封装、服务网格、不可变基础架构、声明式 API 等。这些技术不仅提升了系统适应性、可管理性、可观察性，使开发者可以以最小成本进行频繁和可预测的系统变更，而且还可以提升部署维护速度和效率，助力业务的快速成长。

此外，在使用云原生之后，运维工程师和开发工程师也不会再那么界限清晰，因为大家面向的都是同样的 API。

传统下的企业开发、测试、运维都是相互割裂的状态，云原生则将企业开发和运维部门很好地结合起来。所提倡的DevOps理念打破了开发、测试、运维部门之间的隔阂，让整体的应用交付变得更快速。从技术角度看，DevOps 涵盖了应用的开发、编译、构建、测试、打包、发布的自动化流程，并包含了很多 DevOps 工具链。

云原生核心项目概览

云原生很复杂，它本身是一个很大的生态，包含着几十个甚至上百个项目。

这其中最重要的就是 Kubernetes，它主要的作用是集群管理(node)和作业调度(pod)，作业调度之后， k8s 通过CSI、CNI、CRI将应用以容器的方式运行起来。

那么对外暴露什么样的服务？别人如何访问该服务呢？k8s 本身是通过 kube-proxy 去做东西向的流量的负载均衡和服务发现的， 他还包含了 CoreDNS 也就是集群内的域名服务器以及 Istio等集群服务管理软件。

而 k8s 中产生的数据则专存于分布式数据库etcd中。

云原生技术演进

云原生本身其实是为微服务而服务的，在应用架构上的演进由最开始的单体应用，到分层架构，到 SOA，再到当前流行的微服务。

每一个微服务都是一个独立的部署单元，比如说这几个微服务由这个团队负责，那几个微服务由那个团队负责，团队只需关注自己负责的业务即可，不会受全局的影响。微服务也有着启动速度快、资源需求小、部署灵活等诸多优点。

此外云原生也不断在朝着应用规模化、计算边缘化、部署多样化、应用复杂化的趋势发展。

• 应用规模化：从概念验证到大规模生产应用
• 计算边缘化：以数据中心为主的云计算到面向边缘节点的边缘计算
• 部署多样化：私有云和公有云混合的多云和混合云
• 应用复杂化：简单的无状态应用到复杂的有状态应用管理

还有更重要的局部技术革新，如基于 XDP 和 eBPF 实现的网络加速和应用隔离、基于 WebAssembly 实现的个性化 proxy plugin、不断增强的安全保证手段等等。

相较于传统云平台，云原生有着得天独厚的诸多优势。毫不夸张的说，云原生是这个时代的产物，也必将会引领一个新的时代。

那么你心目中的云原生是什么样的呢？