云原生(Cloud Native)是最近技术圈一个比较火的名词，相信大家或多或少都听说过。不过对于大多数普通研发朋友来说，"云原生"这个词多少可能还是有些陌生，以至于刚开始听到这个词时可能还会一脸懵逼的问"这到底是一个什么技术，我用过吗？"这样的问题。
其实这并不奇怪，因为对于绝大多数普通开发者来说，我们大部分时间都是在别人构建的基础设施里专注于业务代码的开发，而很少关心业务应用运行所依赖的基础设施环境，但这恰恰也是构建云原生应用的核心意义所在。在今天的文章中，就和大家聊一聊关于云原生的话题！
网上有一个结论：所谓云原生，它不是一个产品，而是一套技术体系和一套方法论，而数字化转型是思想先行，从内到外的整体变革。更确切地说，它是一种文化，更是一种潮流，是云计算的一个必然导向。
本人现在工作中负责云原生服务管理平台的研发（主要管理各类云原生基础设施，平台服务和第三方托管应用），但即便如此，常被问起云原生是什么时，我也很难简洁的向人表述清楚，导致自我也经常问一遍，云原生究竟是什么，我又在做什么。
如果你也有同样的疑惑，可以看一下我录制的这套云原生视频，受限于个人的浅薄认知，可能讲解内容会存在一定问题，还请大家包涵：
https://www.bilibili.com/video/BV1234y1e7HC
一、云原生究竟是什么
云原生是一个组合词，即 Cloud Native 。
随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型，它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。
在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。随着云化技术的不断进展，云原生的概念也应运而生。
1.1、云原生概念的诞生
云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。
顾名思义，云原生是面向“云”而设计的应用，因此技术部分依赖于传统云计算的3层概念，基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS），例如，敏捷的不可变基础设施交付类似于IaaS，用来提供计算网络存储等基础资源，这些资源是可编程且不可变的，直接通过API可以对外提供服务；有些应用通过PaaS服务本来就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即SaaS能力，用户直接面对的就是原生的应用。
云并非把原先在物理服务器上跑的东西放到虚拟机里跑，真正的云化不仅是基础设施和平台的事情，应用也要做出改变，改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术都要做出改变，真正的发挥云的弹性、动态调度、自动伸缩……一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多，如容器技术、微服务、可持续交付、DevOps等。
而云原生应用最大的特点就是可以迅速部署新业务。在企业里，提供新的应用程序环境及部署软件新版本通常所需时间以日、周甚至以月计算。这种速度严重限制了软件发布所能承受的风险，因为犯错及改错也需要花费同样的时间成本，竞争优势就会由此产生。
1.2、云原生计算基金会（CNCF）
CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多企业与机构，包括亚马逊、微软、思科等巨头。
目前CNCF所托管的应用已达14个，下图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。
Cloud Native Landscape新版
Pivotal （已被 VMware 收购）官网的 What is cloud native? 一文中提到云原生是一种构建和运行应用程序的方法，云原生开发融合了 DevOps、持续交付、微服务和容器的概念在里面。
CNCF （云原生计算基金会）在 cncf/toc给出了云原生 V1.0 的定义：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
结合官方的定义，我个人对云原生简洁的理解就是：云原生并不是某种具体技术，而是一类思想的集合，用来帮助快速构建和运行应用程序，其中既涵盖着一整套技术体系（容器、服务网格、微服务、不可变基础设施和声明式 API），也包含着应用开发的管理要点（DevOps、持续交付、康威定律）。只要符合这类思想的应用就可以称为云原生应用。
二、云原生技术体系
CNCF(云原生计算基金会)认为云原生系统需包含的属性：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
自动化管理：统一调度和管理中心，从根本上提高系统和资源利用率，同时降低运维成本。
面向微服务：通过松耦合方式，提升应用程序的整体敏捷性和可维护性。
正因为如此，你可以专注于创新，解决业务问题，而不是把时间花在“静态、不灵活的传统架构”存在的许多技术问题。
云原生的四要素：持续交付、DevOps、微服务、容器
云原生的一整套技术体系其实是紧密联系的，这得从软件架构的逐步演进说起。
即 单体 -> 微服务 -> 基于 k8s 上的微服务 -> 服务网格
单体架构，将所有的功能集成在一个工程里，项目发展早期，应用的开发相对简单，即使需要对应用进行大规模更改也很容易，测试、部署，包括横向扩展都不是件难事，运行多个实例后，一个负载均衡器就可以搞定。
随着时间推移，一个成功的应用必然变得越来越臃肿，代码库随之膨胀，团队管理成本不断提高，即俗话说的陷入单体地狱。面对单体地狱，开发者难以理解代码全部，开发速度变缓慢，部署周期变长，而且横向扩展也会遇到挑战，因为应用不同模块对资源的需求是互相冲突的，有些可能需要的是更大内存，有些可能需要的是高性能 CPU，作为单体应用，就必须都满足这些需求。
当出现一个问题，自然会有针对该问题的解决方案，云原生技术体系之一的微服务架构就是针对单体地狱的解决方案。既然单体应用是将全部功能都集成在一个工程里去编译部署，那现在只要把各个功能拆分出来（通常是根据业务能力或者根据子域（子域围绕 DDD 来组织服务）分解），将每个拆分的模块作为一个单独的服务，独立部署（服务之间通常通过 REST+JSON 或 gRPC+ProtoBuf 进行通信），这一个个的服务共同提供整个应用的功能不就好了吗。
但微服务也不是银弹，引入微服务架构后，分布式系统也带来了各种复杂性，诸如配置中心，服务发现，网关，负载均衡等业务无关的基础设施层面都需要开发者一一自行在业务层面实现。
比如一个常见的微服务架构解决方案（图源凤凰架构），就需要开发者自行引入各种组件:
项目开发完成后终归要到部署流程的，早期的传统做法是把应用程序直接部署到服务器上，但服务器的系统、环境变量等是会不断变化的，甚至安装了新的应用，还会引起和其他应用的冲突，导致应用本身需要跟着用户系统环境的改变而做出改变。为了解决这个问题，不可变基础设施的口号就喊响了。第一阶段是将服务部署为虚拟机，将作为虚拟机镜像打包的服务部署到生产环境中，每一个服务实例都是一个虚拟机。但大家都知道，虚拟机太笨重了，为了减少开销，第二阶段，将服务部署为容器，将作为容器镜像打包的服务部署到生产环境中，每一个服务实例都是一个容器。
不可变基础设施：任何基础设施的实例一旦创建之后变为只读状态，如需要修改或升级，需要使用新的实例替换旧的。容器镜像就是一种不可变基础设施的具体实现。
现在容器已然成为了微服务的好搭档，服务实例隔离，资源也可以方便控制，但成千上百的容器，管理起来太麻烦了，于是，容器编排工具又出来了，Kubernetes 目前基本统一了容器编排的市场，实现了容器集群的自动化部署、扩缩容和维护等功能。但 Kubernetes 可不只局限于容器编排，还记得上文的微服务架构中需要开发者自行在应用层面解决业务无关的基础设施层面的一系列问题吗，现在 Kubernetes 就可以解决大部分问题，如图（图源凤凰架构）：
Kubernetes 的编码方式其实就是一种声明式 API（指通过向工具描述自己想要让事物达到的目标状态，然后由这个工具自己内部去计算如何令这个事物达到目标状态）。
到这里，我已经提到了云原生技术体系中容器、服务网格、微服务、不可变基础设施和声明式 API 里面的四种了。还剩下一个服务网格，缓口气，继续。
其实你应该已经可以发现，一步步发展下来，都是为了把 业务和基础设施解耦 ，让开发者可以快速开发自己的业务，无需关心底层基础设施。服务网格也是想干这事的，希望将更多业务无关的功能下沉到基础设施，号称微服务 2.0 。
服务网格核心在于将客户端 SDK 剥离，以 Proxy 组件方式独立进程运行，每个服务都额外部署这个 Proxy 组件，所有出站入站的流量都通过该组件进行处理和转发。这个组件被称为 Sidecar（边车应用）。
Sidecar 只负责网络通信。还需要有个组件来统一管理所有 Sidecar 的配置。在服务网格中，负责配置管理的部分叫控制平面（control plane），负责网络通信的部分叫数据平面（data plane）。数据平面和控制平面一起构成了服务网格的基本架构。
听说再更进一步就是无服务（Serverless）了。
三、云原生管理要点
DevOps（Development 和 Operations 的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
如果你想要深入了解DevOps的各项技术点，可以看一下B站的这套教程：
https://www.bilibili.com/video/BV1DL4y1c7jU
DevOps 的两个核心理念是 CI（持续集成）和 CD（持续交付/部署）。
本文对 DevOps 不做探讨，大家可以去看看。
四、总结
综上所述，云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分，需要以全局地眼光看待问题，脱离任何一个元素，对于企业来说都是“管中窥豹”、“一叶障目”，只有加以整合才能见到云原生的全局风貌。
面对业态各异的业务上云以及碎片化的物联网解决方案部署，利用云原生思维和模式，构建基于云原生的物联网平台以及解决方案，势必将加速企业，甚至整个社会的数字化转型。