云原生（Cloud Native），是2013年由Pivotal公司率先提出的概念。而对于云原生的理解，也许我们问100个人，可能100个人对云原生的解释各不相同。 怎么定义“云原生”？ 我们看看CNCF（ Cloud Native Computing Foundation ）对云原生的官方定义： 云原生技术使组织能够在现代，动态环境（例如公共云，私有云和混合云）中构建和运行可伸缩应用程序。容器，服务网格，微服务，不变的基础结构和声明性API就是这种方法的例证。
这些技术使松散耦合的系统具有弹性，可管理性和可观察性。结合强大的自动化功能，它们使工程师可以频繁且可预测地以最小的工作量进行高影响力的更改 。
从定义中可以看出，云原生包括很多方面，诸如云基础架构服务、现代设计、容器化、服务支持、微服务、自动化等。 也就是说，“云原生”是一种利用云计算交付模型的优势来构建和运行应用程序的方法。“云原生”是关于如何创建和部署应用程序，而不是在哪里。云原生（CloudNative）是一个Cloud+Native的组合：Cloud表示应用程序位于云中，而不是传统的数据中心， 这意味着应用程序位于公共云中，而不是本地数据中心；Native：表示应用程序从设计之初即考虑到云的环境。
云原生充分利用了云服务的模型。没有云计算，也就没有云原生，云计算是云原生的基础。云原生 旨在在动态和虚拟化的云环境中蓬勃发展，广泛使用了平台即服务（PaaS）计算基础架构和托管服务。他们将基础架构视为一次性的，只需几分钟即可配置，并通过自动化按需调整大小、缩放、移动或销毁。
通常用DevOps基本概念中的服务模型“宠物和牛”来形象比较云和云原生。在这里云是宠物，而云原生是牛。
在宠物服务模式，每个宠物服务被赋予一个特别的名字，如小花，小明，老王等等。他们是“独特的，并且受到精心培养和照顾的人，当他们生病时，我们可以让他们恢复健康”。也可以通过增大它们的大小来扩展它们，当它们不可用时，每个人都会注意到。
宠物服务模式示例：如大型机，单独的服务器，负载平衡器和防火墙，数据库系统等。
在牛服务模型中，服务器被赋予像web01、web02、web03、web04和web05这样的标识号，这与牛被赋予贴在耳朵上的标识号的方式非常相似。每台服务器都“几乎完全相同”，而且“当一台服务器生病时，您可以用另一台服务器替换它”。您可以通过创建更多的对象来缩放这些对象，当其中一个不可用时，没有人会注意到。。
牛服务模式的示例：如Web服务器阵列，no-SQL集群，排队集群，搜索集群，缓存反向代理集群，以及tk各种多主数据存储和大数据集群解决方案等等。
也就是说，采用牛模型的云原生，包含不变的基础设施。服务器未修复或修改。如果一个失败或需要更新，它将被销毁，并提供一个新的-所有这些都是通过自动化完成的。而且随着基础设施的扩展，它们的运行机器无关。
云原生的微服务 在云原生系统中包含了微服务，微服务是一种用于构建现代应用程序的流行架构风格。微服务构建为通过共享结构交互的小型独立服务的分布式集合，具有以下特征： 在这里我们对比一下传统的单片应用程序和微服务两种方法的异同：
传统单片整体应用程序的整体结构由分层架构组成的，该架构在单个进程中执行。它通常消耗一个关系数据库。但是，微服务方法将功能分离到包含逻辑和数据的独立服务中。每个微服务都托管自己的数据存储。
据了解，微信已经公开了由数百个独立微服务组成的系统。这种架构风格使他们能够快速响应市场需求。可以即时更新复杂应用程序活动区域，并根据需要单独扩展这些区域。
云原生与本地应用程序 在云原生和本地应用程序之间，它们也是不同的。与企业的本地应用程序相比，本机云应用程序开发需要非常不同的架构。比如说在公司服务器上运行的本地应用程序，倾向于以传统语言编写，如C / C ++，C＃或另一种Visual Studio语言。而云原生应用程序更有可能以网络中心语言编写，这意味着HTML、CSS、Java、JavaScript、PHP、Python等等。 同时云原生的应用程序始终是可以保持最新。而本地应用程序需要更新，通常由订阅交付，并且在安装更新时需要停机。另外，云的松散耦合性质意味着应用程序不依赖于基础架构，这意味着它们是无状态的。云原生应用程序将其状态存储在数据库或其他外部实体中，因此实例可以来去去，并且该应用程序仍可以跟踪该应用程序在工作单元中的位置。
而大多数本地应用程序都是有状态的，这意味着它们将应用程序的状态存储在运行代码的基础架构上。因此，添加服务器资源时，该应用程序可能会损坏。
云原生的容器 在《Cloud Native Patterns》一书中，作者Cornelia Davis指出：“ 容器是云原生软件的强大支持者 。” Cloud Native Computing Foundation将微服务容器化作为其Cloud-Native Trail Map的第一步-作为企业开始其云原生之旅的指南。
对于容器，有专家将它理解为 一种计算单元和一种应用的包装形式。
作为一种计算单元，容器与线程、进程、虚拟机、物理机一样（如下图所示）。在连续尺度上，越往左隔离性、安全性和开销越低，越往右则越高。而容器则恰恰是介于进程和虚拟机之间的一种计算单元。
作为一种包装形式，它最大的特点就是实现了应用的独立和便携，容器本身包含了应用所有的依赖，这使得它可以再任意的基础设施上运行，不会因为系统版本、架构的问题，而导致各种意外。
另外， 容器提供可移植性，并确保跨环境的一致性 。通过将所有内容封装到单个程序包中，可以将微服务及其依赖项与基础架构隔离。
5G需要云原生吗？ 在通信中，云技术已开始被全世界的电信运营商所采用，云计算在4G核心，IMS / VoLTE等方面也已经实现，特别是越来越多地用于Cloud RAN。但这些解决方案还远没有达到足够的开放性和保持供应商中立性。而且最初的电信云主要将大型网络元素移植到大型虚拟化网络功能（VNF）中，这需要消耗非常多的云基础设施资源， 并且难以部署、扩展、升级和维护。
5G的规模带来了更多的设备和非常多样化的服务组合，传统云已经无法跟上， 需要更多的自动化，尤其是切片功能。而且由于低延迟，本地化可靠性和流量控制，云更需要向边缘移动 。下图是传统网络向云原生演进的基本步骤，包括了： 传统方案-虚拟化-云化-云原生。
此外，传统的基于VNF的云体系结构没有用于开发和基准化VNF的标准程序，这导致缺乏VNF的体系结构指南，并且缺乏跨供应商的VNF的标准协议或配置策略。由于这些挑战，每次都需要人工来配置，更新和测试VNF，这是服务提供商成功实现NFV的障碍之一。
因此， 随着5G商用规模越来越大，服务提供商需要提供更多的云服务， 因此必须将云重新架构为原生云，以便他们能够在快速启动新应用程序以及部署和运营新服务时获得突破性的业务敏捷性。
在当今竞争的电信市场，云原生是必需的吗？或许正如一个故事：
两个背包徒步旅行的朋友在一次野营冒险中。其中一个冲进帐篷，向他的朋友大喊，有一只熊奔向他们。这个朋友很快开始穿上他的跑鞋。当他开始系鞋带时，他震惊的问，如何才能跑得比熊快。
朋友说：“我不必比熊跑得快，我只需要比你跑得快。”
云原生比云跑的快！
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报 。
