纯小白也能看懂，十分钟帮你快速了解云原生概念

---

---

随着云原生相关技术的蓬勃发展，不管你是刚入职的小白，还是多年经验的老手，都在关注这种技术趋势。但相关内容太多，导致一些小白无从入手，也没有一个全局的概念。那就花10分钟看完本文，帮你快速了解云原生的起源和发展，并介绍一些技术现状

作者简介：战斧，从事金融IT行业，有着多年一线开发、架构经验；爱好广泛，乐于分享，致力于创作更多高质量内容
本文收录于 云原生，有需要者，可直接订阅专栏实时获取更新
高质量专栏 RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待

---

一、麻烦的一天

小明是一个小企业的程序猿，他觉得他的工作麻烦又枯燥。每天，他需要处理一大堆服务器和应用程序，手动部署和维护它们。这让他感觉像是在重复地做着无尽的琐碎工作。

每当有新的应用需要部署，或者把同一个应用部署在不同的服务器上时，小明都得花费大量时间来配置服务器、安装依赖和解决各种兼容性问题。今天这台机器mysql端口与众不同要重新配置，明天那台机器环境依赖发生冲突要解决冲突，有时候，一个小小的错误就可能导致整个应用无法正常运行，让他陷入绝望。

而且，每当服务器出现故障时，他必须赶紧跑去现场解决问题，有时候甚至要在深夜起床处理紧急事务。这让他感到心力交瘁，无法得到休息。

另外，应用程序的扩展也是一个头疼的问题。每当用户量激增时，他得手动调整服务器资源，希望能满足需求。但有时候，应用程序还是会因为资源不足而崩溃，让他倍感无奈。

二、魔法的种子

1. Docker

假设你是一位热爱烹饪的厨师，有一天你决定去朋友家里做一道特别的美食。然而，你们两个的厨房设备和材料不完全相同，你的厨房里有一些特殊的调味料和器具，而你朋友的厨房里则有一些其他的特色食材。

在传统情况下，为了做这道美食，你需要将所有的调味料和器具都带到朋友家，而且可能还需要重新学习适应朋友的厨房设备。这样做不仅麻烦，还浪费时间和精力。

但是，你可以将所有的调味料、食材和器具都装进一个精美的密封箱子中，在箱子里，你的食材和调味料都是独立的、封闭的，不会与其他东西混合，也不会受到外界的干扰。你可以轻松地将这个箱子带到朋友家，只需要在朋友的厨房里打开箱子，就可以开始烹饪了。

这样一来，你不需要在朋友家里携带大量的物品，也不需要适应不同的环境。你可以专注于烹饪美食，保持高效和一致的操作，而不用担心与朋友的厨房设备产生冲突。

而对于程序猿，不仅仅是小明，实际上小张、小李等无数程序猿也饱受煎熬。大家一致认为，程序猿的天职是写代码实现业务，现在却被繁琐的部署配置，故障解决搞得焦头烂额，真是天理不容。

于是Docker公司于2013年推出了Docker容器，该技术通过将应用程序及其所有依赖项（例如库、配置文件等）打包 在一个独立的运行环境中，形成一个封闭的容器。容器可以在任何支持容器引擎的环境中运行，而不受环境差异的影响，保证了应用程序在不同环境中运行的一致性。

2. Kubernetes

自从有了箱子之后，你感觉轻松了很多，各种不同的环境你都能烹饪出同样的美食。终于成为了酒店大厨，你现在甚至可以弄出一个箱子，然后参照着复制出10个箱子，这样你就可以同时炒10份了。但你很快又发现了问题，尽管开始时10份菜是一样的食材，但在炒菜的过程中，10份菜火候却没法保证完全一致，有的还是生的，有的却还没熟，而且此时如果又来了一批客人，需要你同时炒更多份菜，你还得抽身去复制箱子然后起锅烧油。这让你分身乏术，手忙脚乱。

最后，你选择请了个专业的厨师助手，它会自动根据你的需求，调整每个容器的火力和烹饪时间。当一道菜煮熟了，它会自动关掉相应的火力，而不会让食物过熟。当有更多的客人来访时，助手会自动为帮你复制箱子，并且起锅开始炒。

你不再需要手动管理每个锅，也不用担心忘记照顾其中的一道菜。你可以轻松地同时烹饪多道菜，而且每一道菜都能在适当的时候煮熟，保持美味和口感。你的得力厨师助手，让你的烹饪过程更加高效和愉快

在Docker推出仅仅一年以后，Google的工程师Brendan Burns、Joe Beda和Craig McLuckie 在2014年提出Kubernetes（K8s）这样一个开源容器集群管理系统，其作用是帮助用户管理包括容器的创建、配置和自动化部署等一系列工作，还能够提供高可用性、负载均衡、自动扩容和自动恢复。

需要注意的是，Google早在2000年就开始运行自己的容器技术，Kubernetes的出现是为了推广容器技术。Kubernetes本身不依赖于Docker，除了Docker外，Kubernetes还支持其他容器运行时，如rkt、CRI-O和Frakti，Kubernetes的容器运行时接口（CRI）定义了容器运行时与Kubernetes API的交互方式，因此如果有符合CRI规范的容器运行时，就可以在Kubernetes上使用它们来运行容器

这里我们可以说句题外话，K8s目前已经成了事实上的行业标准，而且其可以踢开Docker选用其他容器，尽管由于Docker曾经的垄断地位和巨大名气，现在很多人依旧选择Docker，但其在市场上的占有率却有所下降

---

三、渐入佳境

1. 技术与术语

随着K8s的推广，一种软件开发和运维的理念，逐渐发展和完善起来。这就是我们所说的云原生：云原生是一种基于云计算的应用程序开发和部署方法，它依托于云计算与云架构；会使用容器化、微服务架构和自动化管理技术来实现高效、弹性、可伸缩和可靠的云部署。当然，这云计算伴随着不少技术和术语，让我为你进行一些常用技术的解释：

容器化技术

容器化技术是将应用程序及其依赖的组件、库等打包到一个可移植的容器中，并提供统一的运行环境，从而实现跨平台和快速部署的技术。目前常用的容器化技术有 Docker、LXC等。
Pod
Pod是Kubernetes中最基本的调度单位。可以类比成进程，一个进程中可以只有一个线程，也能有多个共用资源的线程。一个Pod则代表着集群中运行的一个进程，一个Pod中可以装一个容器(建议)，也可以同时封装几个紧密耦合互相协作的容器，它们之间共享资源，相互协作成为一个service单位。

DevOps

包含 development和 operations，即开发和运维两个单词的组合。是一种将开发和运维融合起来的方法论和实践（最初是这样，但现在这个词的语义越来越大，从需求-设计-开发-测试-上线-运维整条线路，能缩短周期，提高稳定的方法都可以算在里面），目的是提高软件开发和部署的速度、质量和可靠性，其一般手段有：

• 持续集成和持续交付
  这其实也是个老概念，持续集成和持续交付（CI/CD），代表着一种软件开发流程。在以往，开发人员写完代码需要手动打包编译，然后交给测试团队，测试团队拿到包要先部署，然后开始测试。发现问题后又需要改代码打包编译，如此反复。其实很多内容可以不用人工操作，现在我们可以自动化构建、测试、部署和交付应用程序，只需做好设定，如定时触发，其就会源源不断的执行 扫描检测-编译-打包-部署乃至自动化测试等操作，如果出现故障，会及时进行邮件通知。
  
• 自动化运维
  利用软件技术实现运维工作自动化和标准化。它将重复性、繁琐的运维工作通过自动化程序进行处理，以提高工作效率和服务质量。比如自动化部署、自动化监控、自动化备份等

弹性伸缩

弹性伸缩是指根据应用负载和资源消耗情况，自动调整云原生应用的资源配额和容器数量等资源分配策略，以满足应用的性能需求和业务变化，比如我们可以设置当CPU使用率超过90%时，自动增加一个Pod实例。当CPU使用率低于50%时，自动减少一个Pod实例。

Sidecar

Sidecar的字面意思为边车，就像下图这样，摩托车附带个车斗。

在云原生领域，Sidecar是指一种类似的模式，用于将一些辅助服务（例如日志收集、监控和调试）部署在与主要应用程序部署同一容器，或Pod中的辅助容器中，这种设计还是符合Sidecar的形象的。通常，Sidecar容器与主应用程序容器共享相同的网络和存储卷，它们可以通过共享文件系统来进行通信和协作。这种模式可以使应用程序容器保持单一职责（Single Responsibility Principle），便于管理和维护

服务网格

服务网格（Service Mesh）是指将网络功能划分为一些小的、独立的组件，以点对点通信和 API 网关等方式实现服务间通信和控制的技术方案。比如有一个电商系统，其中包含了商品服务、订单服务和支付服务三个微服务，这三个服务需要相互通信，以往每个微服务都需要通过自己的代码来实现服务发现、负载均衡、故障处理等功能。现在这些与业务无关的内容都下沉到基础设施层了。

如图，其中绿色方块为应用服务，蓝色方块为 Sidecar Proxy，应用服务之间通过 Sidecar Proxy 进行通信，而服务网格就是由应用程序中的与每个微服务配对的网络代理和一组任务管理流程共同组成

2. 组件与框架

随着云原生的逐渐发展，很多组件和框架也顺势发展起来，我们现在就快速浏览下：

Docker

前面也介绍过，是开源的容器化技术，它可以将应用程序及其依赖项打包成一个独立的、移植性强的容器。我们可以轻松将其镜像推送至库（公共或私有），然后在其他的位置拉取下来，帮助用户加速应用程序的交付和部署过程

Kubernetes

前面已经提过了，Kubernetes是最流行的容器编排管理平台，可用于管理多个容器化的应用程序。主要功能包括
自动化部署、扩展和管理容器化应用程序，还可以实现滚动升级和回滚、负载均衡、服务发现、容器存储等，不难发现其具有 自动化和自我修复能力、可扩展性和高可用性等

Helm

Kubernetes的包管理工具，用于部署、升级和管理Kubernetes应用程序，如同Helm可以帮助用户管理应用程序的依赖项、配置和变量，并提供了图表和模板等功能

Istio

是一款开源的服务网格，分为控制平面，与数据平面两部分。用于管理服务之间的流量、策略和安全。Istio可以自动化地添加负载均衡、流量控制、故障恢复、度量、监控和日志记录等功能，从而提高应用程序的可靠性和安全性

Prometheus

普罗米修斯，开源的应用程序监控和告警系统，可以帮助用户监控应用程序的状态和性能。Prometheus提供了一个灵活的查询语言和可视化界面，可以使用它来监控系统资源的使用情况、诊断应用程序问题、识别瓶颈和优化性能

Jaeger

开源的分布式跟踪系统，最初由Uber公司开发并开源。主要用于分布式系统中的可视化监控、调试和故障排除。其主要包括以下几个结构：

1. Agent：负责接收来自应用程序的跟踪数据，并发送给Collector
2. Collector：收集来自Agent的跟踪数据，将其存储到后端存储系统，如Elasticsearch、Cassandra
3. UI：提供一个易于使用的操作界面，包括搜索、过滤、排序
4. Query：负责查询存储在后端存储系统中的跟踪数据，并返回一个可视化的跟踪图表
   

Envoy

一个开源的高性能、可扩展的边缘和服务代理，用于处理现代的微服务架构，它提供了负载平衡、流量管理、安全性、观察和监控等功能。可以支持各种通信协议和格式，如HTTP、gRPC、TCP

四、前路漫漫

尽管云原生发展非常蓬勃，但是毫无疑问，其现在也面临着许多挑战。目前来说，可以总结出四大点：

1. 复杂：云原生涉及多个组件和工具，需要深入的技术知识和经验才能正确实现和管理
2. 安全：相较于传统的架构，由于云原生环境的复杂性和开放性，安全威胁和漏洞可能会增加
3. 成本：实施和管理云原生环境需要大量的人力、物力和财力。小企业可能只能考虑租用现有云提供商的服务
4. 标准：云原生是一个相对较新的技术，尚未存在普遍接受的标准，互操作性和可移植性仍存在问题