公众号关注 「奇妙的 Linux 世界」

设为「星标」，每天带你玩转 Linux ！

CNCF：全称Cloud Native Computing Foundation（云原生计算基金会），成立于 2015 年 12 月 11 日，是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展。

成立CNCF这个组织的初衷或者愿景，简单说：

推动云原生计算可持续发展；

帮助云原生技术开发人员快速地构建出色的产品；

CNCF Landscape最重要的产出包括一个路线图和一个全景图。路线图（Trail Map）是CNCF对云原生用户使用开源项目以及云原生技术的推荐过程。在路线图的每个步骤中，用户都可以选择供应商支持的产品或自己动手使用开源项目。

整个路线图分成了十个步骤，每个步骤都是用户或平台开发者将云原生技术在实际环境中落地时，需要循序渐进思考和处理的问题：

容器化。目前最流行的容器化技术是 Docker，你可以将任意大小的应用程序和依赖项，甚至在模拟器上运行的一些程序，都进行容器化。随着时间的推移，你还可以对应用程序进行分割，并将未来的功能编写为微服务。

CI/CD（持续集成和持续发布）。创建 CI/CD 环境，从而使源代码上的任意修改，都能够自动通过容器进行编译、测试，并被部署到预生产甚至生产环境中。

应用编排（Kubernetes）。Kubernetes 是目前市场上应用编排领域被最广泛应用的工具，Helm Charts 可以用来帮助应用开发和发布者用于升级 Kubernetes 上运行的应用。

监控和分析。在这一步中，用户需要为平台选择监控、日志以及跟踪的相关工具，例如将Prometheus用于监控、Fluentd用于日志、Jaeger用于整个应用调用链的跟踪。

服务代理、发现和治理。CoreDNS、Envoy 和 LInkerd 可以分别用于服务发现和服务治理，提供服务的健康检查、请求路由、和负载均衡等功能。

网络。Calico、Flannel 以及 Weave Net 等软件用于提供更灵活的网络功能。

分布式数据库和存储。分布式数据库可以提供更好的弹性和伸缩性能，但同时需要专业的容器存储予以支持。

流和消息处理。当应用需要比JSON-REST这个模式更高的性能时，可以考虑使用 gRPC 或者 NATS。gRPC 是一个通用的 RPC（远程调用）框架（类似各种框架中的RPC调用），NATS 是一个发布/订阅和负载均衡的消息队列系统。

容器镜像库和运行环境。Harbor 是目前最受欢迎的容器镜像库，同时，你也可以选择使用不同的容器运行环境用于运行容器程序。

软件发布。最后可以借助 Notary 等软件用于软件的安全发布。

CNCF Landscape路线图从实践步骤上帮助用户梳理了整个云原生应用的最佳流程。然而整个实践过程中的每个环节，用户都需要了解有哪些具体的软件和产品选择，这就是CNCF Landscape全景图发挥作用的地方了(https://landscape.cncf.io/)。

这张全景图试图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持。

云原生（cloud native）是一种基于云的基础之上的软件架构思想,以及基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

云原生从字面意思上来看可以分成云和原生两个部分。

云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了 IaaS,、PaaS 和 SaaS。

原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。

如何开发出适合于在云环境里面部署的程序呢？其实主要是需要遵循几个开发原则：

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。

微服务解决的是我们软件开发中一直追求的低耦合+高内聚，与微服务对应的是我们传统的单体应用。微服务还建议使用RESTful API通信。

无服务器架构并不是说，未来不再需要服务器，而是不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上。例如一些函数的代码片段，平台自动根据负载按需部署和启动，以及自动伸缩代码逻辑来满足业务处理的需求。

DevOps（Development和Operations的组合词）即开发、运维一体化。涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。

维基百科对DevOps的定义比较拗口。其实往简化里讲DevOps是提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

从另外一个维度，广义上来说，DevOps不仅需要打通开发运维之间的部门墙，我们认为DevOps更多的需要从应用的全生命周期考虑，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。

Service Mesh是近年兴起的一个话题，在容器微服务的基础上，通过 Service Mesh 可以让用户更精细、更智能的去管理服务之间的通讯。Service Mesh 社区的旗舰项目Istio，当前的热度正在迅速的飙升。

云是云原生的基础，没有云也就没有云原生。没有对云正确地理解，也不可能对云原生有正确的打开方式。对于非技术人员来说，至少要理解云的多种不同的服务模型，比方IaaS、PaaS、SaaS 以及各种服务模型的应用场景和价值。

因此我们也可以简单地把云原生理解为：云原生 = 容器化(docker+k8s) + 微服务（Microservices）+ 无服务（Serverless） + DevOps + Service Mesh(服务网格) + 云（Cloud）

我们不难发现，云原生是一个很宽泛的概念，想要开发一个支持云原生的应用并不难，可能就是简单的实现可基于容器部署、使用Kubernetes进行编排与调度，集成CI/CD工具以及Prometheus监控工具等。

但是，想要构建一个真正云原生的系统，要求我们考虑到系统的方方面面，我们不仅要掌握简单的开发技能，还要在SDN、SDS、分布式调度甚至计算机基础架构等诸多领域有所了解，要能够根据场景制定出最合适的架构方案。各方面的综合能力的提升才能在云原生时代构建出云原生就绪的应用或系统。

本文转载自：「 博客园 」，原文：https://url.hi-linux.com/fzsNs/ ，版权归原作者所有。欢迎投稿，投稿邮箱: [email protected]。

最近，我们建立了一个技术交流微信群。目前群里已加入了不少行业内的大神，有兴趣的同学可以加入和我们一起交流技术，在 「奇妙的 Linux 世界」 公众号直接回复 「加群」 邀请你入群。

你可能还喜欢

点击下方图片即可阅读

Docker 已全面拥抱 Containerd，离用上 Kubernetes 1.24 还会远吗？

点击上方图片，『美团|饿了么』大额外卖红包天天免费领

更多有趣的互联网新鲜事，关注「奇妙的互联网」视频号全了解！