对云原生的理解和思考

当前的IT圈，离不开人工智能、大数据、隐私计算、数据要素、云原生、容器等概念，本文就“云原生”这一概念的内容展开叙述，希望能让你更加了解这一概念。

一、云原生到底是什么？

现在的IT圈子，无论是客户端、渠道端还是友商之间的技术探讨，都离不开AI人工智能、大数据、隐私计算、数据要素、云原生、容器等概念，仿佛不谈这些话题，就跟不上了社会发展的脚步，今天，我想谈谈我对“云原生”这个概念的理解，也是自己对知识的一个总结。

云原生顾名思义“就像是从云里面自动生长出来的东西”，所我认为以云原生就是一种思想或者理念。这种理念产生的背景是什么那？我们可以回顾一下云计算的发展历程。互联网从1960年开始兴起，1990年开始进入普通家庭，2000年开始逐步引入中国，门户网站/腾讯/阿里巴巴/网易/百度等相继成立，随着互联网的高速发展，互联网用户规模不断扩大，企业为了维持用户的高速增长，需要购买大量的服务器资源，传统的IOE架构，投资巨大且资源浪费严重，没有什么企业能够承受如此巨大的开支，因此在这样的背景之下，google在2006年搜索引擎大会上首次提出了“云计算”的概念，相继的各大互联网公司将“云计算”纳入到重点研究建设的方向，云计算技术开始进入了快车道发展，而且技术已经变的非常成熟。

我们发现，过去部署应用软件是部署在IOE架构上，现在部署在云计算架构上，而且部署效率、运维效率以及安全性、可靠性也更加高了，企业客户减少了硬件成本、人工成本、维护成本等的投入。但是，大家有么有发现一个问题，我们只是改变了承载应用的基础设施，且没有改变应用本身，所以我们不仅会问一个问题：跑在传统架构的应用和运行在云里面的应用是不是完全适配的？云的一些技术优势特性能否对应用有一些利好？过去我们应用开发都是基于IOE架构开发的，我们能不能基于云的架构去开发应用？如果按照云架构去开发应用，那么和基于传统架构的软件开发又有什么区别那？

正是这些疑问的提出，“云原生“的理念就出现了，就是“你开发的应用软件能不能天然的适配云、更好的利用云能力，就像从云里面自主生长出来的一样。”所以云原生他面相的对象是“应用软件”，过去十几年我们呢推动了底层基础架构的变化，未来的几十年我们将推动软件应用的变化，真正做到云-应用-业务的一体化。

二、云原生的架构是什么？

既然云原生面相的对象是“软件应用”，那么我们就需要对软件进行分析，他由什么成分构成，软件大致上可以分为3个部分：功能性部分（代码）、非功能性部分（代码）和第三方的部分（代码）。功能性部分是软件应用的核心，是客户真实需要的业务功能和逻辑，而非功能性部分，例如运维代码、可靠性代理、安全性代码等，以及第三方部分，例如第三方软件的调用、API数据调用等，都是非核心的功能性代码，他们只是更好的辅助核心功能代码能够正常稳定的运行，正如下图左侧部分的描述。

云原生架构如右图所示，未来的软件开发只需要聚焦在最核心的功能性代码上，而不用去关注哪些非功能性代码部分，将非功能性的代码全部交给云平台去实现，例如可靠性、安全性、视图化、第三方调用等等，这样既提升了软件开发的效率，也会大幅度提升软件质量（只聚焦业务本身）。理想往往是美好的，但真正落地的时候总是困难重重，下文探讨为实现云原生架构，无数工程师们做的努力。

三、实现云原生的技术路线是什么？

前文提到，要让软件应用只聚焦业务功能部分，其他的你不用考虑，这就大大简化了应用开发的复杂度和难度，有两条路径：

其一还是按照原来的开发思想，将无数功能紧耦合最终形成一个大的软件应用，然后部署在云计算环境中；还有一条路径就是目前主流的思想，就是软件设计要尽可能的解耦合，要以模块化的方式交付，从而提高可重复利用性。

很显然第二条路径才是最优的解，让软件功能模块化，后面基于客户的需求任意组装，既可以减少开发成本，又可以提高部署效率，还能提升软件质量等。但是路径二面临一个比较大的问题，如果采用功能模块化的形式开发软件，面临如下困难的问题：软件功能模块如何部署？是单独部署还是组装好部署？如果是组装好一个大的软件后部署，就和传统软件部署没有太多差异（只是剔除了一些非功能性的代码），依然面临一个模块出问题影响整个软件运行、一个小升级涉及到整个软件的下线、可能面临重新配置环境、二次上线安全检查等一系列的后置动作，在运营上并没有提升多大的效率。

如果是单功能模块部署那么功能模式间如何通信达到完整应用的效果？单模块功能部署在哪里？如果部署在虚拟机上，应用功能模块一般很小，给他配置的单个虚拟机资源会不会造成浪费？剥离出来的非功能性代码如何植入到云平台上，例如运维能力，原来是登陆系统直接对应用作运维，现在是放到云计算平台上，如何运维？怎么运维？等等一系列的问题。

还好有无数优秀的工程师，Docker技术应运而生（当然前期有很多的铺垫技术的诞生）。Docker在2004-2007年就在google大规模的部署和应用，于2013年gitHub上正式立项，google、redhat、aws、alibaba等开始大规模的应用Docker技术。Docker是比传统云计算虚拟机更加轻量化、小型的虚拟机。这就存在了让模块化功能存在的技术底座，也就是大家经常说的微服务。

只需要再解决如何让这些微服务组成一个完整的服务（软件应用）、如何运维这些微服务组件（装了功能模块的容器，可能涉及到几千/几万/几十万个微服务才能构建一个完整的应用系统服务，管理难度可想非常复杂）、如何确保这些微服务的可靠性、安全性、可视化等，那么就可以成功实现云原生架构了。因此2014年，Kubernetes（K8s）项目也正式发布，它的核心功能就是管理这些容器、微服务组件等，次年，CNCF（云原生基金会）成立，K8s成为第一个CNCF项目，定义各种标准和规范，打造围绕云原生架构一整套的生态体系，至此，各大云计算厂家开始进入了云原生时代！

正如阿里巴巴在《阿里云原生白皮书》序言中所言：云计算的下一站，就是云原生；IT架构的下一站，就是云原生架构。

四、Docker是如何实现更轻量化的虚拟机

前面讲到，Docker是更加轻量化的虚拟机，这才给功能模块提供了一个理想的基础环境，那么docker为什么这么轻量级那，看下面的架构对比：

VM为了模拟硬件资源，是有独立的操作系统Guest OS，所以它也拥有独立的操作系统资源、文件系统资源等，另外，Hypervisor层（无论KVM/XEN）为保障更好的隔离效果，消耗的资源也比较大，因此VM架构整体对底层硬件资源消耗还是比较大的。而docker容器是直接在原生的Linux主机上（host os必须是linux）加了一层container engine层，向上对容器进行运行和管理，向下对Cgroup和namespace进行操作，他对资源的消耗相对比较小。上层的每个容器就是一个只包含一个进程（可以包括多个子进程）的应用，他没有独立的操作系统，只有独立的文件系统，因此资源占用非常的小。所以我们可以把容器这样理解：容器=1个进程=1个应用功能模块。

Docker是如何实现没有操作系统就可以实现资源的调用、隔离和管控的，核心就是依托Linux系统中cgroups、namespace和chroot三个核心的能力。chroot实现了进程间的资源隔离，每个进程可以享有独立的文件系统、namespace提供了资源视图隔离，只能够看到部分进程（其他进程看不到）、cgroups实现对进程的资源管控。因此，基于linux的这三大能力，容器技术才得以发展起来，天然的可以支持云原生的架构。

当然只有docker容器还不够，一个docker就是一个功能模块，如何管理、、调度、组合这些模块，以达到应用级的要求那，这就是下一章节要讲的kubernetes的主要功能。

五、Kubernetes（K8s）的架构和核心能力

一个、十个容器好管理，但是成千上万甚至几十万个容器怎么管理，就必须要借助专业的工具了，这就是几乎和docker同时出生的K8s要做的事情。K8s核心功能包括容器的编排、健康检查、水平伸缩（负载均衡）、自动发布与回滚等功能，同时通过pod、deployment实现对复杂功能的组合，最终实现构建大型业务应用的能力。

上图是K8s的架构，典型的server-client的二层架构，master是中央控制中心，会与node进行连接和通信。所有user侧的指令都会通过master下发给最终的节点执行。下面这张图是master的内部架构，核心就是包括4个部分：API server、controller、scheduler和etcd。

API server：用来处理API服务的，K8s中所有组件的通信必须通过API server，组件与组件间不会直接建立通信连接。

Controller：是控制器，用于对容器集群进行一些状态管理，例如健康检查、水平伸缩（负载均衡）、容器恢复、应用发布与回滚等。

Scheduler：调度器，就是对容器进行调度管理。例如用户创建一个容器，scheduler会给予该容器对内存、cpu等要求的大小来给他分配一个node运行。

etcd：分布式的存储系统，用来存储API server过程中的信息和数据。

下图是Node节点的内部架构图，node是真正运行负载的，每个业务负载都会以pod形式运行（一组容器组合，或者理解为一组非常紧密的进程组合，逻辑单位非真实存在），他的核心组件是kubelet，以及其他四个组件container runtime、storage plugin、netwoek plugin和kube-proxy。

Kubelet组件：真正node上最核心的组件，它通过 API Server 接收到所需要 Pod 运行的状态，然后提交到我们下面画的这个 Container Runtime 组件中。

Container runtime组件：核心组件，是负责在主机上创建、运行和管理容器的软件组件

storage plugin和netwoek plugin组件：对容器进行网络和存储管理，这个不是k8s管理，而是用户/云厂商自己去操作。

Kube-proxy组件：通过该组件，构建k8s整个集群通信网络。

讲到这里，我们知道了，软件功能模块既有了基础环境（docker）也有了集群管理工具Kubenetes，现在还需要解决一个重要问题，那就是pod（也就是一组容器，在K8s中最小调度单位）节点间如何通信的问题以及集群和pod节点如何通信的问题，这样才能够实现如下两个能力：内部多pod组合（也就是employmet）才能实现完整的业务软件应用，以及外部用户如何访问这些应用。要实现成功的访问，肯定要组件通信网络，这就是CNI和cube-proxy要解决的事情：

a、CNI容器网络接口：他的核心功能就是创建pod IP，实现容器间的通信，这样就可以组合更加复杂的应用功能软件。目前存在的网络接口方案有多种：flannel、calico、openvswitch、weave、ipvlan等。每一种接口方案用到的技术原理有些差异，这里简单介绍常用的几种：

1）Flannel 是最常用的 k8s 网络插件之一，它使用了虚拟网络技术来实现容器之间的通信，支持多种网络后端，如 VXLAN、UDP 和 Host-GW；

2）Calico 是一种基于 BGP 的网络插件，它使用路由表来路由容器之间的流量，支持多种网络拓扑结构，并提供了安全性和网络策略功能；

3）Canal 是一个组合了 Flannel 和 Calico 的网络插件，它使用 Flannel 来提供容器之间的通信，同时使用 Calico 来提供网络策略和安全性功能；

4）Weave Net 是一种轻量级的网络插件，它使用虚拟网络技术来为容器提供 IP 地址，并支持多种网络后端，如 VXLAN、UDP 和 TCP/IP，同时还提供了网络策略和安全性功能。

b、Cube-proxy代理：他的核心功能就是将clusterIP（外部用户可以访问的真实IP）映射到pod ip上（内部虚拟IP）上，外部用户通过LoadBalance-nodeport-clusterIP或者直接通过暴露nodeport-clusterIP来完成成整个业务应用的访问。

六、总结：云原生从概念到落地

截止到现在，我们讲完了容器技术是如何一步步实现云原生架构的：

首先，通过chroot、cgroup和namespace功能，实现了进程级的资源隔离、管控和视图。这样为功能模块提供了合适的运行环境

其次，通过kubenetes容器编排和管理工具，利用master/node实技术架构，现了大规模容器的管理和编排

最后，通过CNI网络插件工具，实现了pod间（容器组）之间的通信，实现了软件的复杂功能，当然为了更好的管理pod，人们又推出了deployment组件，更好的管理pod应用，例如回滚、灰度发布（升级更新）等操作。

七、展望：全新的办公新业态

云原生架构，本质上就是一种面相“云“的软件开发思想，恰好容器技术从现在来看，是比较好的实现路径。“用户上云”一定是确定性的事情，所以“业务上云”也是确定性的事情。采用全新的“云原生”应用开发理念是实现业务快速上云的一个比较好的方式，未来软件开发人员要成为一个既懂业务开发又懂云原生技术的复合型人才，云原生将重构整个软件开发产业，向效率更高、质量更好、成本更低的方向不断演进。

云原生技术重构了软件业态，5G/6G甚至7G的产生保障了用户到云的访问通路，零信任技术实现了端到云的安全连接。所以未来的办公场景将真正实现随时随地、安全自主、快速高效。

​Read More