很多小伙伴刚一开始看到“云原生“三个字时都会有点懵，当然彼时的我也不例外。在这篇文章中，我将从”云原生是个啥“，”云原生和我有啥关系“，“云原生的未来”这三个方面来展现我眼中的云原生，希望对你有所帮助。
云原生是个啥
在说云原生之前，不得不先来谈谈云计算和微服务。云计算是一种托管在远程数据中心的服务，在今天已经相当普遍了。云计算由亚马逊在 2006 年首先推出，主打的卖点就是云的高弹性，高容错，免（少）运维，比自建机房更便宜等优点。随后各大云厂商如 Google，微软，阿里巴巴等迅速跟进，建立了 Iaas，Paas，Saas 等对云基础设施不同抽象层次的服务体系，在 08 到 16 年掀起了一波上云的浪潮。
在这波浪潮推动的同时，微服务由于其易于扩展，开发敏捷，人效利用高等优点也大行其道。但是在浪潮过后，已经上云的企业又发现一些棘手的问题：
云服务绑定云厂商，无法比较平滑迁移到另一个云厂商
云服务器的利用率普遍偏低，在某些情况下的成本算下来比自建机房还要高
云服务确实具备弹性和容错性，但随着微服务的盛行，基于机器粒度的弹性和容错性满足不了大部分用户的需求
……
众多企业在用云过程都或多或少碰到了这些问题。而云原生就是这样一套技术体系以及理念，能够使得上述提到的问题迎刃而解。那到底云原生是怎么解决的呢？
云原生的很多技术都考虑到了应用（服务）这个粒度，这与传统云计算的 Iaas 这个层次对机器的粒度的抽象相比都要更小一些。以云原生的集大成者 Kubernetes（k8s）为例，简单讲讲它是怎么解决迁移难，利用率低，弹性和容错性难用这么几个关键点的。
首先 k8s 定义了 Node（就是一台服务器）与 Pod（就是一个服务的副本）这两种资源，Pod 可以申请 CPU，内存等计算资源，k8s 会根据申请的 CPU 和内存将 Pod 按照一定策略调度到某一个 Node。我们可以调整这其中的策略来使得 Node 可以承载更多的 Pod，以提高服务器整体的使用率。一般为了高可用我们的服务都是以多副本（Pod）部署的，对外提供相同的服务。同一个服务的 Pod 可以打散部署到不同的 Node 上，这样就算一个 Node 出现故障挂掉，那也只是这个 Node 上的 Pod 无法提供服务，其他 Node 上的 Pod 仍然可以对外提供服务，与此同时 k8s 还会在其他 Node 上拉起因为 Node 故障而挂掉的 Pod。这样高可用就能得到很好的保障。
当然，最重要的莫过于：kubernetes 是开源的，与厂商无关。只要我们的服务运行在 k8s 上，理论上就能够在不同的云厂商之间进行迁移。 可以这么说，在过去十年，云原生就是趁着微服务的东风，才一跃成为炙手可热的技术之一。因此，云原生和微服务是密不可分的。
再来回答到上一小节末的问题，云原生是怎么解决的呢->粒度的减小，减小到什么程度呢->与微服务体系中的服务相匹配。
云原生和我有啥关系
可能写到这你还是对云原生有一些疑惑，最大的疑惑可能莫过于：对于“我”而言，云原生和我有啥关系？为了回答这个问题，我们可以让这个“我”来扮演多个角色。
如果“我”是企业老板/技术负责人，那我首先应该想到的是云原生能够提供“看得到”的价值。那首当其冲的就是使用云原生技术能够有效提高机器负载，降低机器成本，这一天然的优势特别符合近两年来的“降本增效”的浪潮。其次基于服务粒度的弹性和容错性也进一步增强了服务的健壮性，减少了事故的发生。从人效上看，基于云原生的 CI/CD 流提升了敏捷开发的效率，加快了业务迭代的速度，从而提供了人效。因此云原生作为基础设施，能产生很多看得到的价值，这与以往基础设施很难体现出价值形成了鲜明的对比。
如果“我”是普通的开发者，那我首先想到的是其技术价值。在常见的开发调试->部署上线->线上调整这个应用生命周期中，云原生主要涉及到“部署上线“和“线上调整”这两个步骤。在规模稍大的公司中，通常会分为业务开发和平台开发，业务开发专注于业务开发与迭代以满足客户需求，而平台开发则专注于内部研发平台的开发迭代以满足业务开发的需求。因此部署上线和线上调整一般都会都会划归到平台研发中。那是不是业务开发就和云原生没关系了？从某些意义上是的，但从技术发展的角度看，云原生作为基础设施层的技术，融合了很多设计艺术，涉及到很多高可用，高并发的场景设计。因此当你学习云原生的一些技术时，你会自然而然地将一些优雅的设计熟稔于心。此外，熟悉云原生的大致框架有助于对整个应用的生命周期有完整的理解，反过来也有助于你在开发应用时能够更好地利用底层的基础资源。
云原生的未来
上文中说道，云原生乘着微服务的东风，度过了“黄金十年“。那在下一个十年，云原生又该何去何从？
要回答这个问题，我们可以先来看看云原生的优势。关于云原生的优势，上文也提到了不少，在这里我可以总结成一句话：云原生技术能够使应用更好地利用云资源，更好地对外提供服务。对这句话再解读一下，我们的应用是需要消耗云资源并向外提供服务的，而云原生技术抽象了计算资源，能够让应用按需地使用云资源，从而使得应用对外提供服务这一过程便捷了不少。需要注意的是，以上的总结以及解读中的“应用“特指消耗 CPU，内存，存储的“传统应用“。那与传统应用相对应的是什么呢？答案就是 AI。从去年大火的 ChatGPT 到今年的百模大战，AI 发展的速度超过了绝大多数人的想象。与传统应用相比，AI 应用的生命周期更长，且模型的训练，微调，推理都离不开当今时代的“黄金“——GPU，而云原生领域的技术对 AI 的支持还远没有传统应用的完善。诸如 mlops，GPU 的调度分配，分布式训练等随着 AI 发展而涌现的 topic 会越来越多，相信云原生+人工智能的脚步也会越来越快。
至此，云原生的未来也很确定了，CNAI（Cloud Native Artificial Intelligence）将会成为云原生下一个十年的主航道。
写在最后：
想了很久第一篇博客要写些什么，前前后后想了一周，最后还是敲定了一个比较大的 title，希望对你有所帮助。文章内容如有错误，请老师们评论区勘误 😁😁。后续将会持续更新云原生，LLM 等领域的内容。