云原生应用的10大关键属性

“云原生”是用于描述基于容器的环境的术语，而Kubernetes是一个运行云原生应用程序工作负载的理想平台。

开发人员在设计云原生应用程序时，一定要牢记本文内这10个关键属性！

------------

“云原生（Cloud Native）”是用于描述基于容器的环境的术语。云原生技术被用于开发应用程序，这些应用程序是使用容器打包的服务构建的、被部署为微服务、并通过灵活的DevOps流程和持续交付工作流在弹性基础架构上进行管理。

在运维团队手动管理传统应用程序的基础架构资源分配的情况下，云原生应用程序部署在抽象了底层计算、存储和网络原语的基础架构上。处理这种新型应用程序的开发人员和运维人员不直接与基础架构提供商公开的API交互。相反的，编排器会根据DevOps团队制定的策略自动进行资源分配。控制器和调度程序是编排引擎的基本组件，负责处理资源分配问题和应用程序的生命周期。

像Kubernetes这样的云原生平台使用扁平网络，该网络覆盖在云提供商的现有网络拓扑和原语上。类似地，本地存储层通常被抽象出来，以暴露与容器集成的逻辑卷。运维人员可以分配开发人员和资源管理员访问的存储配额和网络策略。基础架构抽象不仅解决了跨云环境的可移植性需求，还让开发人员可以利用新兴模式来构建和部署应用程序。无论基于物理服务器或虚拟机，私有云或公共云的底层基础架构如何，编排管理器都将成为部署目标。

Kubernetes是一个运行云原生应用程序工作负载的理想平台。它已经成为云的事实上的操作系统，就像Linux是底层机器的操作系统一样。只要开发人员在设计和开发软件时，遵循其作为云原生应用程序的微服务的最佳实践，DevOps团队就能够在Kubernetes中打包和部署它们。以下是开发人员在设计云原生应用程序时应牢记的云原生应用程序的10个关键属性。

1、打包为轻量级容器：云原生应用程序是打包为轻量级容器的独立自治服务的集合。与虚拟机不同，容器可以快速扩缩容。将扩展单元转移到容器，能够优化基础架构利用率。

2、使用最佳语言和框架开发：云原生应用程序的每项服务都是使用最适合该功能的语言和框架开发的。云原生应用程序是多语言的，服务会使用各种不同的语言、运行时和框架。例如，开发人员可以构建基于在Node.js中开发的WebSockets的实时流服务，同时选择Python和Flask来暴露API。开发微服务的细粒度方法使它们能够为特定任务选择最佳语言和框架。

3、设计为松耦合的微服务：属于同一应用程序的服务通过应用程序运行时来发现彼此。它们独立于其他服务而存在。正确集成时，弹性基础架构和应用程序架构可以高效地、以高性能来进行扩展。

松耦合的服务让开发人员可以在处理每个服务时都能够独立于其他服务来工作。通过这种分离，开发人员可以专注于每项服务的核心功能，以提供细粒度的功能。这种方法可以实现整个应用程序的有效生命周期管理，因为每个服务都是独立维护的，并且拥有明确的所有权。

4、以API为中心进行交互和协作：云原生服务使用轻量级API，这些API基于REST、gRPC或NATS等协议。REST通常被用作通过HTTP公开API的最低公分母。为了提高性能，gRPC通常用于服务之间的内部通信。NATS具有发布-订阅功能，可在应用程序内实现异步通信。

5、在架构中将无状态和有状态服务清晰分离：持久耐用的服务通常遵循不同的模式，以确保更高的可用性和弹性。无状态服务和有状态服务是彼此独立存在的。存储会影响容器的使用。我们必须越来越多地在有状态、无状态、微存储环境（这一点有些人可能觉得有争议）等不同语境下考虑持久性这一因素。

6、与服务器和操作系统依赖关系隔离：云原生应用程序与任何特定操作系统或单个计算机没有关联。它们在更高的抽象级别上运行。唯一的例外是微服务需要某些功能，包括固态驱动器（SSD）和图形处理单元（GPU），这些功能可能由一部分机器专门提供。

7、部署在自服务的弹性云基础架构上：云原生应用程序部署在虚拟的、共享的和弹性的基础架构上。它们可以与底层基础架构保持一致，以动态增长和缩小——根据不同的负载来自我调节。

8、通过敏捷DevOps流程进行管理：云原生应用程序的每项服务都会经历一个独立的生命周期，通过敏捷的DevOps流程进行管理。多个持续集成／持续交付（CI / CD）流水线可以协同工作以部署和管理云原生应用程序。

9、自动化功能：云原生应用程序可以高度自动化。它们与Infrastructure as Code的概念相得益彰。企业需要一定程度的自动化来管理大型和复杂的应用程序。

10、定义的、策略驱动的资源分配：最后，云原生应用程序与通过一组策略定义的治理模型一致。它们遵循CPU和存储配额以及将资源分配给服务的网络策略等策略。例如，在企业方案中，中央IT可以定义策略来为每个部门分配资源。每个部门的开发人员和DevOps团队都拥有对其资源共享的完全访问权和所有权。