云原生是什么？如何准确理解云原生？

一、云原生概述

云原生的概念，由来自Pivotal的MattStine根据其多年的框架经验总结于2013年首次提出，被一直延续使用至今。这是他当时提出的几个主要特征:

• 面向微服务框架
• 自服务敏捷架构
• 基于API的协作
• 符合12因素应用
• 抗脆弱性

它的出现其实也得益于虚拟技术的发展，在社区中不断完善，并逐渐成为一种新兴的基础设施交付方案，在某种意义上重新定义了IT界软硬件资源的标准。2015年谷歌主导CNCF成立之后，给出了1.0的云原生定义主要是云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

目前CNCF给出了云原生应用的三大特征：

• 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离
• 动态管理：通过集中式的编排调度系统来动态的管理和调度。
• 面向微服务：明确服务间的依赖，互相解耦。

二、云原生之CNCF知识图谱

上图就可以看出，其实云原生涉及的技术领域众多，这上面就收集和其技术相关的工具、平台和项目，通过此图可快速了解和应用相关的技术，根据业务能力可对架构进行重组与建设。

三、云原生之核心技术

容器

容器(container)这一概念最早出现在Linux中出现的，又称LXC(Linux Container)，主要是通过Cgroups的资源管理能力和Namespace的资源隔离能力结合在一起实现进程级别的隔离。

K8s

全称是Kubernetes，由Google 基于 Borg 开源的容器编排调度系统，是一种基于容器技术的分布式架构领先方案。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等功能，用户不需要再过度的关注资源的管理问题，降低操作的复杂度，提高了大规模容器集群管理的便捷性。

微服务(Microservices)

微服务则是一种用于构建应用的架构方案，微服务架构有别于为传统的单体应用的是将应用拆分成多个核心功能，每个功能都被称为一个独立的服务，可以单独构建和部署，其中某个服务出现故障也不会影响其他的功能模块，这句体现了其针对特定服务发布，影响小，风险小等特点。

服务网格(Service Mesh)

服务网格指的是用于微服务应用的可配置基础架构层。在使用服务网格时通常会提供一个sidecar代理实例，主要处理 service 间的通信、监控、以及一些安全相关的考量，每个serivce里面都会有一个sidecar，同样也提供了服务发现、负载均衡、授权等功能。

无服务(Serverless)

根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。即开发人员无需关注底层的基础设施，只需要关注应用程序的业务本身就行，且该服务是可以自动扩展。

DevOps

早期的项目使用的是‘瀑布模型’进行软件交付，即一个阶段所有的完成工作之后再往下一个阶段，但这样的模式无法满足业务快速开发交付及变更需求的情况，于是后面就出现了敏捷开发这一概念，即一种快速应对需求变化软件开发能力，而DevOps就是基于敏捷开发将软件开发/测试人员/IT运维关联在一起，通过工具、组织等方式使开发、测试、发布流程自动化，软件发布频繁，高效。

云(Cloud)

常常听到的‘公有云’，‘私有云’，‘混合云’都是基于这个生态衍生出来的各种场景，不同的云搭建环境，所需资源亦有所不同，比如公有云是在互联网上发布的云计算服务，而私有云则是在公司内网发布的云计算服务，目前没有一种云计算类型可以解决所有场景出现的问题，怎么选择适合自己的场景则需要根据技术需求决定。

四、云原生之实践

1. 云原生中的DevOps

DevOps这一概念虽然比容器、微服务出现得早，却是随着他们的出现才得以快速的发展。实际上DevOps不单是一个实现自动化的工具链，更是通过构建企业文化的方式促进开发与运维之间的协作。下图可以看出，这样的运作模式已经颠覆了传统的工作模式，每个环节都不再独立分割开，而是用协作的方式生产更快、更高质量的生产软件。

2. 持续集成

持续集成（CONTINUOUS INTEGRATION，CI），其核心是新提交的代码与原代码正确的集成。开发人员多次、频繁的将代码提交到代码仓库中，在合并到指定分支之前，对新提交上来的内容进行编译、自动化检测(如：代码格式检测)的验证，这样的过程既保证了代码的完整性、安全性，为后面的工作提供了质量保证。

3. 持续交付

持续交付（CONTINUOUS DELIVERY，CD），其重点不在代码本身，而是可以交付的产品上。在发布到生产环境之前，对新增的代码进行测试(test) -> 模拟(staging) -> 生产(produciton)，即简化繁琐的发布流程，又保障新添加的代码在生产环境是可用的。

4. 持续部署

持续部署（CONTINUOUS DEPLOYMENT）通过自动化部署的方式频繁的交付产品，关注的重点在于自动化部署。从开发人员提交代码到编译、测试、部署整个流程都是通过自动化执行，这种方式加快了交付的速度，同时在发现问题时也缩短修复的时间。

CICD关注整个开发到交付的过程，中间的测试、模拟、自动部署等都是整条生产链上的所需要的每一步都是需要去关注的。而DevOps则更关注于各部门、不同岗位之间的协同过程，尤其是开发和运维之间的沟通壁垒。总的来说，DevOps是CICD思想的延伸，CICD是DevOps的基础核心，如果没有CICD自动化的工具和流程，DevOps是没有意义的。

五、云原生之总结

云原生之于国内，还是一个非常新的话题，云原生的覆盖面很广,已知和潜在的用处很大,全面及深入的理解需投入大量的人力及时间成本,不管是学习研究还是在实战中需要分而治之。总体来说体现出以下几个方面的优势：

• 快速迭代：利用云原生应用程序开发，多种技术、多种方案相互融合，为项目交付提供自动化和编排的快速迭代方案。
• 自动部署：云原生的方法对于传统的方法而言，直击代码质量低下、发布流程繁琐的痛点，通过其具备的自动化和组合功能，针对编译、测试、部署等过程建立良好流程基础，快速交付。
• 独立高效：云原生带来的微服务化框架，打破了传统的开发模式，对于一个应用来说，一个微服务就是一个可独立发布的应用；对于一个团队来说，为各个部门，不同岗位提供更多协同与沟通上的的思路。