什么是云原生应用？

在云计算开始蓬勃发展的六七年前，人们一直在努力解决的一个重要问题是：“如果我想在公共云、私有云或混合云中运行我的应用程序，它们需要是什么样的？”

当时对这个问题有很多种解答。

一个流行的比喻来自当时在微软工作的 Bill Baker 的一次演讲。他将 传统应用程序“宠物”与云应用程序“牲畜”进行了对比。 在第一种情况下，你给你的宠物命名，并在它们生病时照顾它们恢复健康。在后一种情况下，你给它们编号，如果其中一个出了问题，你就吃汉堡，然后换一个新的。

这个比喻并不完美——而且可能有点文化上的不敏感——但它确实抓住了长寿命的独特实例与大量基本上可丢弃的实例之间的本质区别。

还有其他尝试来编纂这种区别。“十二要素应用”是构建软件即服务应用程序的明确方法。从更商业的角度来看，行业分析师 Gartner 使用 模式 1 和模式 2 来区分传统 IT（侧重于稳定性、健壮性、成本效益和垂直扩展等属性）与云原生 IT（强调适应性和敏捷性）。

这些仍然是有用的观点。许多现代、动态和横向扩展的工作负载在公共云和私有云（如 OpenStack）中作为虚拟机运行。它们的开发和运营显然遵循与传统纵向扩展、在“大型机”服务器上长期运行的应用程序不同的理念。

然而，云原生通常意味着更具体的东西，尤其是在应用程序架构和设计模式的背景下。它是容器化基础设施和使用细粒度 API 驱动的服务（又名 微服务）组成的应用程序的交集。这种结合是偶然的。像 Netflix 这样的公司正在推广微服务理念，将其作为有效利用云计算的一种方式。容器，首先是通过早期的平台即服务产品实现的，然后作为更广泛、标准化的生态系统的一部分，成为打包、部署和管理这些微服务的绝佳方式。

顺便说一句，不要太纠结于微服务这个术语。重要的是应用程序的整体敏捷性和可维护性。通过使用持续集成和持续交付的 DevOps 流程交付，这往往会导致模块化和松散耦合的服务，这些服务的依赖关系是明确定义的。

但是，如果对于应用程序的性质和团队的规模来说没有意义，则并非所有内容都需要分解为仅通过公开的、稳定的 API 进行通信的单功能服务。

容器本身可以维护服务之间的资源和安全隔离。它们提供了一种快速且资源高效的方式来根据需要启动额外的服务，并在需求下降且不再需要它们时将其停用。从开发人员的角度来看，容器也是一个很棒的生产力工具，因为它们将内容打包为一系列层，并且可以在需要补丁时快速且一致地更新。

在过去几年中，容器的最大变化可能是用于管理它们的工具的数量和成熟度的增加。 Kubernetes 是最著名的；它自动化了 Linux 容器操作，并消除了部署和扩展容器化应用程序中涉及的许多手动流程。

然而，当涉及到容器生态系统中的开源项目时，Kubernetes 只是一个开始。还有像 Prometheus 这样的监控工具，像 Jaeger 这样的分布式跟踪工具。Istio 服务网格连接、管理和保护微服务。另一个发展中的领域是函数即服务（通常称为 无服务器），它执行函数（即，执行某些操作的代码）以响应事件（某种触发器）；主要驱动因素是进一步简化程序员创建新服务的方式。

许多，甚至大多数工作负载都可以在云中或多个云的混合组合中运行。但是“云原生”应用程序的想法是，在云革命开始大约十年后，我们对如何充分利用新型基础设施有了一些可靠的想法。反过来，我们也在不断改进这些基础设施技术，以便为应用程序开发人员提供他们需要的工具。这才是云原生的真正含义。灵活、可扩展、可重用的应用程序，使用可用的最佳容器和云技术。