关于后端:我该从哪些方向了解云原生领域

你好，我是王炜。明天咱们一起来看一看该从什么角度理解云原生畛域。

说起云原生畛域，我置信你首先想到的是赫赫有名的 Kubernetes（Kubernetes），Kubernetes 曾经成为容器调度的事实标准了。那你有没有想过，除了 Kubernetes 代表的容器调度方向以外，还有哪些值得咱们关注的方向呢？

在上一节课，我为你具体介绍了 CNCF 云原生基金会。CNCF 作为云原生开源我的项目托管和经营基金会，是咱们理解云原生倒退的最佳对象。这节课，咱们还是立足 CNCF，深刻云原生畛域多元化的方向及数量泛滥的外围产品。我会联合本人对这些产品的实际和总结，帮忙你全面理解云原生，让你将来可能更好地进行技术选型。

接下来，我将重点介绍云原生全景图：CNCF Landscape。

毫不夸大地说，理解了 CNCF Landscape，就算是对云原生畛域有了一个全局的意识。

CNCF Landscape

略微理解云原生畛域的同学可能会晓得，云原生相干的产品数量是十分宏大的。为了可能更好地收集、分类并展现它们，为云原生行业的从业者和研究者提供便当，CNCF Landscape 孕育而生。

CNCF Landscape 中文名叫做 云原生全景图。顾名思义，它为咱们提供了云原生畛域的全局视角，你能够了解为，它为数量宏大的云原生产品做了更加粗疏的垂直分类。同时，寰球任何开发者都能够通过合作的形式，将合乎云原生规范的我的项目提交到云原生全景图中。

如下图所示，这只是云原生全景图的一部分。

当你第一次关上云原生全景图时，我置信你会被这些宏大数量的云原生我的项目所震撼。

为了更好地读懂全景图，首先咱们须要对它进行简略的分类。

大体上看，咱们能够将全景图分为两大部分：

1. 垂直方向和产品；
2. 平台和服务商。

垂直方向和产品指的是云原生细分的方向以及这些方向所蕴含的产品。而平台和服务商指的是与 CNCF 单干的一些云厂商，典型的有 AWS、腾讯云或者阿里云等等。

接下来，咱们重点介绍垂直方向和产品这部分。

你能够对照着全景图，联合我上面给出的分类，依照从上到下，从左到右的程序来解读：

1. 数据库（Database）；
2. 数据流和音讯（Streaming & Messaging）；
3. 利用定义和镜像构建（Application Definition & Image Build）；
4. 继续集成和继续交付（Continuous Integration & Delivery）；
5. 调度和编排（Scheduling & Orchestration）；
6. 协调和服务发现（Coordination & Service Discovery）；
7. 近程调用（Remote Procedure Call）；
8. 服务代理（Service Proxy）；
9. API 网关（API Gateway）；
10. 服务网格（Service Mesh）；
11. 云原生存储（Cloud Native Storage）；
12. 容器运行时（Container Runtime）；
13. 云原生网络（Cloud Native Network）；
14. 自动化和配置（Automation & Configuration）；
15. 容器仓库（Container Registry）；
16. 平安与合规（Security & Compliance）；
17. 秘钥治理（Key Management）；
18. 监控（Monitoring）；
19. 日志（Logging）；
20. 分布式追踪（Tracing）；
21. 混沌工程（Chaos Engineering）；
22. 继续优化（Continuous Optimization）。

为了能让你对症下药，我把重点方向做了加粗。也就是说，在日常工作中，咱们大概率会接触并应用到的产品都在下面这 12 个垂直方向中。接下来，我就结合实际产品，对这 12 个垂直方向做一下具体的介绍。

利用定义和镜像构建

这个方向聚焦在定义云原生利用以及构建容器镜像上，例如利用编写、打包、测试、装置和降级。次要的产品有上面几类。

• Helm：它是 CNCF 这个类别中惟一的毕业我的项目。Helm 最后来源于 Deis 团队开发的 Kubernetes Place 我的项目，能够把它了解为 Kubernetes 的包管理工具。Kubernetes 利用包以 Helm Chart 为载体，提供了非常灵活的利用定义个性。同时，用户能够十分不便地查找、共享、装置和降级 Kubernetes 利用。Helm 经验了 V2 和 V3 两个大版本升级，目前是社区最沉闷的 Kubernetes 利用定义我的项目。Helm 有时候会和 Helmfile 我的项目一起应用，相似的利用定义我的项目还有 Kustomize。
• Buildpacks：CNCF 孵化我的项目。它是由 Heroku 在 2011 年发动并开发的镜像构建工具，它的特点是可能主动查看编程语言，无需编写 Dockerfile 即可构建镜像。
• KubeVela：CNCF 沙箱我的项目。KubeVela 基于 OAM（Open Application Model）标准实现，次要由阿里云开发，是一个利用交付和治理平台，反对多集群利用交付。
• Nocalhost：CNCF 沙箱我的项目，由腾讯云 CODING 团队开发，是一款 Kubernetes 环境的开发工具。它让咱们在批改代码后无需从新构建镜像即可查看编码成果，可能减速 Kubernetes 环境下的开发内循环。
• Telepresence：CNCF 沙箱我的项目。它会通过 VPN 的形式连贯 Kubernetes 集群和本地开发环境，不便开发者在本地进行编码和调试利用。

在我的项目实际上，利用定义环节最开始可能会应用 Kubernetes 原生的 Manifest 来部署利用，随着我的项目的倒退，例如咱们须要关注不同环境、多服务镜像版本、环境配置差别的时候，能够进一步将 Manifest 迁徙到 Kustomize 或者 Helm 上，为 Kubernetes 利用安装包提供更大的灵活性。

在镜像构建环节，Dockerfile 的构建形式依然是支流的抉择。

能够说，构建镜像是开发者在开发阶段等待时间最长的环节。要想在不用从新构建镜像的状况下就能查看编码成果，你还能够 尝试应用 Nocalhost 或 Telepresence。

继续集成和继续交付

这个方向聚焦在 Kubernetes 利用的构建和部署上，也就是咱们常说的 CI/CD。次要的产品有 ArgoCD、FluxCD、Tekton 和 Spinnaker。

• ArgoCD：CNCF 孵化我的项目。最后由 Applatix 公司创立和开发，是一个申明式的 GitOps 继续部署工具。ArgoCD 目前是这一畛域最沉闷的我的项目，也是在 Kubernetes 环境下构建 GitOps 工作流的首选工具。
• FluxCD：CNCF 孵化我的项目。和 ArgoCD 相似，也是一款 GitOps 工具，相比拟 ArgoCD，FluxCD 在能力上绝对单薄，比方在多租户和 Web UI 方面都略逊一筹。
• Tekton：CD 基金会托管我的项目，由 Google 开源。它的次要性能是基于 Kubernetes 实现 CI/CD 流水线，应用 Pod 来执行流水线的 Tasks，并通过 PVC 共享工作空间，设计理念十分不错。
• Spinnaker：CD 基金会托管我的项目。由
  Netflix 开源，次要面向多云和混合云的部署环境，配置和应用门槛较高。
  除却这些较新的产品，在继续集成环节，也不乏一些老牌的产品，诸如 Jenkins、GitLab CI 等。

云原生的呈现扭转了 CI/CD 零碎的格局，尤其是继续交付方向，ArgoCD 和 FluxCD 创始了以 GitOps 为根底的全新交付形式。对于大部分 Kubernetes 业务利用来说，继续集成次要的性能是自动化测试和构建镜像，继续部署次要的性能是将利用部署到 Kubernetes。这样的话，Tekton(CI) + ArgoCD(GitOps) 的搭配就是一个不错的抉择。

当部署环境波及多云以及混合的运行环境时，例如，Kubernetes 利用和 VM 利用共存时，能够思考应用 Spinnaker。

调度和编排

这个方向聚焦在容器调度和基础设施的编排上，例如跨集群调度和治理容器。次要的产品包含 Kubernetes 和 Crossplane。

• Kubernetes：CNCF 毕业我的项目。Kubernetes 的前生是 Google 的 Borg 零碎，次要用于外部的集群调度。Kubernetes 最后的版本在 2014 年开源，通过 8 年的倒退，曾经成为了容器编排的事实标准。能够说，Kubernetes 和 Docker 凭借一己之力为云计算带来了新的机会和增长。
• Nomad：由 Hashicorp 开源，被誉为“没有复杂性的 Kubernetes”。它与云平台无关，次要针对容器和非容器利用，同时与 Hashicorp 的其余工具互补，例如 Consul、Vault 等，它的成熟度和社区活跃度相比拟 Kubernetes 较弱。
• Docker-compose：Docker 开发的容器编排我的项目，它次要面向多个 Docker 容器的利用，容许用户通过 docker-compose.yaml 模板文件来定义一组相关联的容器。Compose 常常被用于一键拉起本地环境的能力，受到开发者的青睐。
• Terraform：由 Hashicorp 开源，创始了基础设施即代码 (Infrastructure as code) 的理念，并提供了申明式的基础设施治理能力。这个我的项目并不在全景图里，但它是基础设施编排畛域最风行的我的项目。
• Crossplane：CNCF 孵化我的项目。由 Upbound 公司开发的云原生基础设施管制立体，能够简略地把它了解为 Kubernetes 版的 Terraform，次要是以 CRD 申明式来治理基础设施。

除了 Kubernetes 以外，容器调度方向其实还有十分多的我的项目，例如 Docker Swarm、Mesos 等，因为 Kubernetes 曾经成为了生产级容器调度的事实标准，所以社区认为没有必要再保护它们了。

在基础设施编排方向上，Terraform 是一个十分不错的抉择。当然，基于雷同理念的 Crossplane 是后起之秀，它能够通过申明 CRD 的形式来治理基础设施，目前在社区也比拟沉闷。

API 网关

这个方向聚焦在基于 Kubernetes 的 API 网关上，次要的产品有上面几类。

• Emissary-ingress：CNCF 托管我的项目。由 Ambassador 公司开发，它是一个 Kubernetes API 网关，并且能作为 Kubernetes Ingress 应用，外部基于 Envoy 代理实现。
• Ingress-nginx：Kubernetes 版的 Nginx。尽管这个我的项目不在云原生全景图中，但它是 Kubernetes Ingress 方向最沉闷的我的项目，也是咱们在 Kubernetes 最常常应用的组件。
• Traefik：一款现代化的 HTTP 反向代理和负载均衡器，反对部署在多样的基础设施中，例如 Docker、Swarm、Kubernetes、Consul、Rancher 等。
• Kong：老牌的开源网关产品，基于 Openresty 开发，功能强大。
• Apisix：Apache 的托管我的项目，由国内团队开发，目前处于疾速倒退阶段。

提到网关，咱们最相熟的莫过于 Nginx 我的项目，它在 Kubernetes 平台也有相应的实现，也是最常见的 Ingress-nginx 我的项目。

Kubernetes 通过 Ingress 来对立治理内部服务拜访的 API 对象。Ingress 能够是多种实现形式，例如 Ingress-nginx、Emissary-ingress、Traefik-ingress 等，其中，Ingress-nginx 和 Traefik-ingress 是我的项目中比拟罕用的 API 网关。

服务网格

服务网格是一个比拟新的方向，次要用于大规模微服务架构下的流量治理，尤其是货色流量治理（也就是微服务和微服务之间的流量治理）。次要产品包含 Istio 和 Linkerd2。

• Istio：CNCF 孵化我的项目。最后由 Google 创建并在 2017 年开源，应用 Envoy 作为代理。大家最相熟的莫过于它的 Sidecar 机制。Istio 经验了从微服务架构回归到单体架构的转变，是目前最风行的服务网格我的项目。
• Linkerd2：CNCF 毕业我的项目，由 Buoyant 公司推出的下一代轻量级服务网格。与 Linkerd 不同的是，它专门针对 Kubernetes 环境。和 Istio 一样，Linkerd2 也可能以 Sidecar 的形式劫持 Pod 的流量，并通过申明式的形式治理集群内的货色和南北流量。

服务网格可能以无侵入的形式为服务调用提供可察看性、流量治理和安全性等方面的反对。在咱们最关注的流量治理方面，服务网格能够无侵入实现服务熔断和降级、金丝雀和灰度公布、拜访速率管制、加密以及端到端的身份验证。

比拟这两个我的项目，Istio 目前比拟风行，然而数据面采纳的是 Envoy 代理，在大规模场景下可能会有性能问题。Linkerd2 也有较好的发展趋势，数据面采纳由 Rust 开发的轻量级 Linkerd2-proxy，在大规模场景以及性能方面比拟有劣势。在应用门槛和复杂性上，Linkerd2 绝对简略，更有劣势。

云原生存储

这一方向聚焦在 Kubernetes 的存储解决方案，也就是提供长久卷的存储能力上。次要的产品有 Rook、Longhorn 和 Velero。

• Ceph：Linux 基金会我的项目。它是一个对立的分布式存储系统，以其高性能、可靠性和可扩大著称，在通过了多年的倒退后，目前曾经被宽泛应用，并且泛滥云厂商也提供了反对。
• Rook：CNCF 毕业我的项目。Rook 是一个开源的云原生存储的编排零碎，专一在 Kubernetes 上运行 Ceph 分布式存储系统，它能够提供文件、数据块以及对象存储。
• Longhorn：CNCF 孵化我的项目，最后由 Rancher Labs 开发，除了提供云原生长久化存储反对外，还提供了灾备和恢复能力。
• Velero：由 VMWare 开源的我的项目。Velero 能够为 Kubernetes 集群提供资源以及长久卷的备份和复原，通常在备份和迁徙 Kubernetes 场景下应用。

云原生存储是通过容器存储接口（CSI）来实现的。它提供了一个规范 API，不同的我的项目只有实现这些 API 就能够为 Kubernetes 提供长久卷能力反对。

云原生存储方向我的项目如 Rook、Longhorn 等多用在私有化场景中，对于一些私有化的 Kubernetes，往往须要自建存储服务，以便在 Kubernetes 集群内应用 StorageClass、PV 和 PVC。

而对于应用云厂商托管 Kubernetes 集群的状况，集群的长久化存储基本上会实现由自家云提供的云存储服务，咱们只须要间接应用它们即可。

对于集群备份、迁徙以及长久卷的备份和复原场景，咱们能够抉择 Velero 我的项目。因为它反对应用 Minio 作为备份存储服务，极大简化了 Kubernetes 的备份和复原过程。

容器运行时

容器运行时是 Kubernetes 执行容器化动作的软件，次要的产品有上面四个。

• Containerd：CNCF 毕业我的项目。Containerd 最后是 Docker Engine 中的组件，起初被独立进去。创立 Containerd 的指标是提供工业级的容器运行时规范，通过 CRI 插件实现 Kubernetes 容器运行接口（蕴含容器的全生命周期、拉取和推送镜像等）。目前简直所有 Kubernetes PaaS 平台都反对该运行时。
• CRI-O：CNCF 孵化我的项目。CRI-O 是一个轻量级的容器运行时，也能够作为 Containerd 的替代品应用。相较于 Containerd，CRI-O 能够提供更欠缺的 OCI Hooks，例如 Prestart、Poststart、Poststop 等。
• Kata-Containers：Kata container 是一个轻量级虚拟机的容器运行时。它能够借助轻量级虚拟机的专用内核，实现容器平安和隔离性，在提供平安能力的同时，依然具备较高的性能。
• gVisor：和 Kata container 相似，是一个平安、隔离的容器运行时。

对于终端用户来说，咱们在大部分场景下无需关注容器运行时，因为它们在下层提供的能力基本上是统一的。例如，Containerd 是目前比拟罕用的容器运行时，也是许多云厂商默认的运行时。在 Kubernetes 1.20 版本过后，社区曾经不再举荐应用 Docker 作为运行时了。

不过，如果咱们对容器运行时有特殊要求。例如，强调容器之间的隔离性和安全性，特地是对一些心愿像用 VM 那样应用 Pod 的团队而言，Kata-Container 或 gVisor 是一个不错的抉择。

容器仓库

这个方向聚焦在为镜像提供推送、存储和下载性能。次要的产品有 Harbor 和 Dragonfly2。

• Harbor：CNCF 毕业我的项目。由 VMware 中国团队开发并开源，也是第一个合乎 OCI 规范的镜像仓库。Harbor 提供企业级公有镜像仓库存储服务，蕴含一系列企业级性能，例如平安、身份验证和治理等，是容器仓库畛域最沉闷的我的项目，也是大多数企业在容器仓库上的技术选型。
• Dragonfly2：CNCF 孵化我的项目，最后由阿里巴巴开发并开源。和 Harbor 不同，Dragonfly 次要解决的是大规模场景下的镜像散发，它是基于 P2P 技术开发的，能够和 Harbor 搭配应用。

容器仓库实质上是一组 Web API 接口，它容许容器运行时推送、查找和下载容器镜像。

当然，除了抉择开源我的项目以外，各大云厂商往往也会有本人商业化的容器仓库产品。例如 GitHub Package、Google Container Registry、AWS ECR 等。这些商业化的产品往往还可能提供例如 CDN 散发和减速、平安等企业级性能。

对于用量不大的团队而言，商业化产品不须要付出保护老本，只须要为存储和流量付费即可，性价比较高。当然，在用量比拟大的业务场景下，自建镜像仓库老本的确更低。

监控

该方向聚焦在为 Kubernetes 提供监控指标采集、查问和可视化服务上，次要的产品有 Prometheus、Thanos 和 Grafana。

• Prometheus：CNCF 毕业我的项目。在国内通常称为普罗米修斯，其灵感来源于 Google 的 Borgmon。通过近 10 年的倒退，已简直成为了云原生监控的事实标准，它的社区十分沉闷。
• Thanos：CNCF 孵化我的项目。该我的项目次要是为 Prometheus 提供高可用的解决方案，例如，反对多样的后端存储系统、数据压缩、晋升查问速度等。
• Grafana：用于数据查问和可视化的开源工具。在搭建 Kubernetes 的监控零碎时，它通常会和 Prometheus 一起应用，用来系统地提供查问数据和仪表盘的能力。Grafana 社区十分沉闷，是可视化工具畛域最风行的工具。

在云原生监控方向，Prometheus + Grafana 曾经成为十分风行的开源技术选型计划。要疾速搭建它们绝对容易，但要长期应用的话，这个计划对运维要求还是比拟高的，尤其是要面对 Prometheus 的大规模集群和长久化的后端存储方面的挑战。

例如，在大规模的长久化方面，咱们常常会把它们和时序数据库 InfluxDB 一起应用，这就会产生额定的运维工作。另外在大规模的监控场景下，Prometheus 也非常容易产生性能瓶颈，这就对 Prometheus 的高可用提出了更大的挑战。

装置 Prometheus 后，它会主动抓取 Kubernetes 和 Pod 在零碎级的指标数据。如果你心愿采集业务指标，就须要在业务代码中集成相应的 SDK，并且输入合乎 Metric 标准的指标数据，提供给 Prometheus 来抓取指标。

当然，如果你不想本人保护开源技术栈，也能够抉择其余的商业化产品，例如驰名的 Datadog。

日志

日志方向次要聚焦在为 Kubernetes 利用提供日志采集、存储和剖析性能，次要产品有 Fluentd 和 Loki。

• Fluentd：CNCF 毕业我的项目。它是一个开源的日志采集工具，赫赫有名的 EFK 日志技术栈中，F 指的就是 Fluentd。Fluentd 十分轻量而且性能优越，所以在社区十分受欢迎。
• Loki：来自 Grafana Labs。它能够提供轻量级的日志采集解决方案，次要蕴含三个组件：Promtail、Loki 和 Grafana。Promtail 是一个轻量的日志采集 Agent，Loki 提供日志存储和查问服务，Grafana 则用于展现查问数据。Loki 以其高可用和轻量的特点倒退迅速，十分受社区的欢送，是目前十分不错的日志技术选型。

总的来说，日志方向有不少开源的技术选型，例如咱们常见的 EFK 技术栈。EFK 由 Elasticsearch、Fluentd 和 Kibana 组成，其中，Elasticsearch 次要负责存储日志和查问剖析，Fluentd 作为 Agent 负责采集日志信息并将日志发送到 Elasticsearch 中存储，Kibana 则作为展现查问后果的 UI 界面。

在一些中小型的利用场景中，Loki 是一个更风行的抉择。特地是对于曾经采纳 Prometheus 作为监控的团队来说，Prometheus + Loki + Grafana 能够一次性解决监控和日志问题。

分布式追踪

该方向致力于为 Kubernetes 利用提供分布式调用链追踪能力。次要产品有 Jaeger、Skywalking 和 Grafana Tempo。

• Jaeger：CNCF 毕业我的项目。基于 Google Dapper 论文，由 Uber 公司创立并开源。Jaeger 的次要性能是为微服务提供分布式调用链的追踪，次要特点是高扩展性、反对多种后端存储系统、现代化的 UI 界面，同时兼容 OpenTelemetry 和 Zipkin 协定。Jaeger 社区十分沉闷，是一个十分不错的技术选型。
• Skywalking：由国内团队开发并开源的分布式系统 APM 和追踪工具，局部语言能够实现无侵入地采集指标和追踪分布式调用链。Skywalking 的性能体现优异，在反对云原生方面也体现良好，受到了社区的欢送，尤其是它现代化的 Web UI 界面，体验十分不错。
• Grafana Tempo：由 Grafana Labs 带来的开源分布式追踪计划，其特点是易于应用、反对大规模后端以及老本可控。它可能与 Grafana、Prometheus 和 Loki 深度集成，反对 Jaeger、Zipkin、OpenCensus 和 OpenTelemetry 协定，目前社区较为沉闷。

分布式追踪方向有很多优良的开源产品，如果想要实现多语言和端到端的分布式追踪，Jaeger 是一个十分不错的抉择，但它的代价是须要集成绝对应的 SDK，对业务有肯定的侵入性。

如果后端语言比拟繁多，尤其是应用了 Java 技术栈，举荐应用 Skywalking 作为 APM 和分布式追踪工具，它对业务基本上没有侵入性。

混沌工程

该方向聚焦在为 Kubernetes 利用提供混沌工程试验平台，次要的产品为 Chaos-Mesh 和 Chaosblade。

• Chaos-Mesh：CNCF 孵化我的项目。Chaos-Mesh 是由国内 PingCap 公司开发并开源的混沌工程平台，它次要由 Operator 和 Dashboard 组成，提供了敌对的混沌试验操作界面。Chaos-Mesh 的社区较为沉闷，在混沌工程方向是一个十分不错的技术选型。
• Chaosblade：CNCF 沙箱我的项目。由阿里巴巴开源的一款混沌工程试验工具，反对通过 CLI 和 HTTP 进行调用，能够十分不便地注入混沌试验。

混沌工程最早由 Netflix 提出，通过多年的倒退，曾经成为很多大型分布式应用测验稳定性的试验工具。它可能向零碎中随机注入一些常见的故障，例如 CPU 和内存压力测试、IO 故障、网络提早等，目标是以被动的形式找到微服务零碎中较为单薄的中央，进行定向优化。

在下面列出的这两个我的项目中，Chaos-Mesh 为咱们提供了 UI 操作界面，对于刚接触混沌工程的同学来说是上手混沌工程不错的抉择。

如何将本人的我的项目退出到 Landscape？

后面提到，CNCF Landscape 反对以合作的形式将本人的我的项目提交到全景图中。具体的合作是通过 GitHub 仓库来进行的。你能够向这个仓库提交 Pull Request，把你的我的项目信息合并到全景图中，特地要留神在提交时抉择一个适宜的分类。

当提交被 CNCF Review 并合并后，你就能够在 Landscape 网站看到本人的我的项目了。

总结

在明天的分享中，我给你提供了一个理解云原生畛域的角度：CNCF Landscape。云原生畛域的垂直方向十分多，在刚开始学习的时候，往往很难抓住重点方向。

正因为如此，我特意把你大概率会在工作中接触到的方向做了标注，你能够先专一在这 12 个方向上，有针对性地学习。在将来的工作中，当你须要在某个云原生方向搭建开源技术栈时，心愿这篇文章可能帮到你。

最初，还有一点要再强调一下。在做技术选型决策的时候，请务必从 团队须要什么、将来的可维护性以及业务扩展性 三个维度来综合评估，有时候并不存在最好的技术选型，你更须要关注的是，哪些技术会更适宜你们团队的现状和将来。

文章起源：极客工夫《云原生架构与 GitOps 实战》