云原生应用是专门从头开始设计的，能够充分利用云技术的弹性和分布式特性。为了更好地了解什么是云原生应用，建议您先了解非云原生应用，即传统的单体式应用。

单体式应用是作为单个单元运行的，通常每个应用都有其自定义构建的操作系统、中间件和语言栈。大多数脚本和流程也是专为构建、测试和部署用途而构建的。总体而言，这种应用架构会产生紧密的依赖关系，这样，随着系统规模不断扩大，更改、测试、部署和运行系统的难度也会更大。这些最初简单的设计和部署很快就会变得复杂，且难以发展，运行起来也有难度。

相比之下，由于云原生应用充分利用了现代基础设施的动态分布式特性，可以实现更高的速度、敏捷性、可伸缩性、可靠性和成本效益。

通过使用一些技术和方法（即 DevOps、持续交付和持续集成、容器、微服务和声明式 API），云原生应用通常被分解为多个独立的服务。这使得相关团队可以独立地部署和扩缩各个组件，因此他们可以在不中断任何服务的情况下不间断地进行更新、修复问题和交付新功能。

云原生架构基于以下五个核心要素：

微服务：几乎所有云架构都基于微服务，微服务的关键优势在于可组合性，即将应用分解为一组更小的轻量级服务，而这些服务可通过应用编程接口 (API) 轻松组合并相互连接。例如，一个电子商务应用可能由购物车专用服务、付款服务以及用于与库存管理后端通信的服务组合而成。可组合性还使团队能够切换和重组组件，以满足新的业务要求，而不会中断应用的其他部分。

容器和编排：容器是轻量级的可执行组件，包含在任何环境中运行代码所需的所有元素（包括应用源代码和依赖项）。容器提供工作负载可移植性，支持“一次构建、随处运行”的代码，使开发和部署过程大大简化。由于它们可以独立部署，因此还有助于避免各种语言、库和框架之间的磨合。这种可移植性和灵活性使得容器成为构建微服务架构的理想选择。   

此外，随着微服务数量的增加，容器编排也非常重要，可以帮助管理容器，使它们能够作为应用平稳运行。诸如 Kubernetes 之类的容器编排平台可以对容器的运行位置和运行方式进行监督和控制、修复任何故障，以及在各容器之间实现负载均衡。

DevOps：云原生应用的开发需要改为采用像 DevOps 这样的敏捷交付方法，这样，开发者和 IT 运维团队就可以密切协作，自动执行基础设施和软件交付流程。DevOps 使开发和运营团队可以更密切地沟通和协作，实现共同的目标，从而打造出可以更快地构建、测试和发布应用的文化和环境。

持续集成和持续交付 (CI/CD)：通过该自动化流程，可以更快地修复、扩缩和部署系统。通过 CI/CD 流水线，可以自动构建、测试和部署应用更改，而无需安排停机时间或等待维护窗口。持续交付可确保软件发布更可靠、风险更低，从而使得团队可以更快速、更频繁地提供新的服务和功能。

云原生服务和技术可帮助您在任何环境中构建、运行和部署可扩缩的应用。当您的客户和企业用户从常规应用中受益时，正是云原生服务在后台运行，确保了这些应用的平稳运行。

例如，云原生服务可能会由云服务提供商提供的各种“aaS”类产品（例如，IaaS、PaaS 和 SaaS 服务模型）、应用的各种微服务以及用于连接各服务并实现服务间通信的 API 构成。

实际上，云和云原生是有区别的。“云”指的是云计算，公司或个人会付费以按需服务的方式访问计算资源。

虽然“云原生”经常被用作用于在云端开发软件的工具和技术的笼统描述，但这一术语并不仅仅与云采用有关。相反，它指的是如何构建和交付应用，而不仅仅是在哪里部署应用。在某些情况下，应用甚至可能并未在云端运行。您可以依照云原生原则构建应用，但在本地或混合环境中运行应用。

尽管云原生有很多优势，但在采用这种模型时，确实需要考虑一些权衡取舍。云原生计算并不总是很容易实现，因为除了要采用新的工具和技术之外，还需要相应的文化转变才能成功实现该方法。

云原生面临的一些常见挑战包括：

• 如果您没有适当的工具或流程来管理开发、测试和部署，那么处理分布式系统和许多移动部件的过程可能会非常棘手
• 如果没有适当的成本优化和监督措施来控制云环境中的资源使用，那么运营和技术成本都会增加
• 目前缺少可用来使用并集成更为复杂的技术栈的技术性技能
• 人们对实现云原生技术和 DevOps 最佳实践所需的文化转变存在一定的抵制
• 难以向非技术高管传达云原生概念来获得他们的支持和认可

然而，只要有正确的专业知识和策略，以上所有问题都是可以解决的。例如，可以在最开始采用简单的“直接原样迁移”方法来迁移到云端，但这样做将无法充分利用上文列出的许多云原生优势。许多组织最终在这个阶段停滞不前，因为他们没有预料到重新设计架构以迁移到云原生架构的费用和复杂性。

我们建议不要将云原生视为一个多年期的一次性项目；而应将其视为一个不断迭代，不断学习和改进的持续过程。