云原生到底是什么
云原生是一个组合词，即 Cloud Native。
Pivotal（已被 VMware 收买）官网的 What is cloud native? 一文中提到 云原生是一种构建和运行应用程序的办法，云原生开发交融了 DevOps、继续交付、微服务和容器的概念在外面。
CNCF（云原生计算基金会）在 cncf/toc 给出了云原生 V1.0 的定义：
云原生技术有利于各组织在私有云、公有云和混合云等新型动静环境中，构建和运行可弹性扩大的利用。云原生的代表技术包含容器、服务网格、微服务、不可变基础设施和申明式 API。
这些技术可能构建容错性好、易于治理和便于察看的松耦合零碎。联合牢靠的自动化伎俩，云原生技术使工程师可能轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。
联合官网的定义，我集体对云原生简洁的了解就是：云原生并不是某种具体技术，而是一类思维的汇合，用来帮忙疾速构建和运行应用程序，其中既涵盖着一整套技术体系（容器、服务网格、微服务、不可变基础设施和申明式 API），也蕴含着利用开发的治理要点（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 的两个核心理念是 CI（继续集成）和 CD（继续交付 / 部署）。
本文对 DevOps 不做探讨，举荐一个微软的教程能够去看看。
更多分享
欢送关注我的微信公众号【寻寻觅觅的 Gopher】，专一分享 Go, 云原生等相干常识