在第一篇cloudnative实验室文章中，我将向您展示在cloudfoundry环境中定义环境变量的七种不同方法。接下来，我将比较这些方法，以便找到最适合您需要的方法，这篇文章以Fiori风格列出了所有变量。

这篇文章介绍了环境变量在云原生世界中的作用，大数据分析技术，以及它们在SAP云平台中的主要使用方式。由于环境变量是这样一个众所周知的概念，有很多方法来定义它们。我将解释我个人使用的各种技术，并将它们相互比较，以确定哪些选项适合哪些用例。

UI5 Web组件列表可视化了环境变量

我假设没有必要深入解释环境变量，因为大多数人已经以这样或那样的形式处理它们了。因此，我只给大家留下Wikipedia文章的第一句话：

环境变量是一个动态命名值，它可以影响进程在计算机上运行的方式。它们是流程运行环境的一部分。

我认为这个描述非常适合。我相信每个开发人员都已经使用了臭名昭著的path变量。环境变量的概念在1979年被引入Unix世界，不久之后也被引入Windows世界。虽然这个想法很古老，但它还远未退休。实际上，我想说的是，环境变量正在经历第二个青春期。

我经常听到人们把CloudFoundry和Kubernetes这样的云原生平台称为云原生操作系统，这是有道理的。这些新平台与传统操作系统一样依赖于环境变量。在所有内容都被容器化的云本地区域中，环境变量经常被用来将配置注入容器。它们可以声明连接的服务，或者包含有关较大集群中容器的角色或任务的信息。第一种方法的一个例子是，当开发人员没有显式地输入服务凭据时，软件模块会默认地检查环境变量中的服务凭据，就像GCP BigQuery客户端那样。后者的一个例子是CircleCI之类的CI/CD工具如何使用它们来传递关于并行运行的容器数量的信息。这可以让每个容器知道有多少助手在他们之间分配工作负载。

一个（基本）容器通常适用于许多场景，物联网断路器，这减少了使用不同配置管理各种容器的开销。可以公平地说，环境变量使容器更具可重用性，从而实现整个云的原生思维。

SAP云平台中的环境变量与其他云平台上的环境变量一样，用于配置和绑定微服务。每次服务实例绑定到微服务以将凭据注入应用程序时，cloudfoundry环境都会创建新的环境变量。许多来自SAP的云模块在启动时读取这些变量，并将它们解释为配置。

我使用最多的包是应用程序路由器。它将环境变量用于许多配置维度，其中最著名的是目标的配置。您可能知道，可以通过cockpit、服务实例或环境变量来配置目的地。当审批者正在寻找一个新的配置时，它会逐个检查这三个配置以找到正确的目标。在另一个配置维度中，审批者将搜索绑定服务的凭证以将流量转发到。

依赖于环境变量的包的另一个示例是xsenv。此实用程序包有助于加载和读取SAP Cloud Platform Cloud Foundry环境、SAP XS advanced model和Kubernetes（K8S）中绑定服务的应用程序配置。在npmjs.org网站，您可以看到SAP的几乎所有其他npm包都依赖于这个模块。因此，xsenv是SAP最流行的npm包也就不足为奇了。xsenv将dotenv和cfenv等工具的用途结合在一个工具中，这个工具已经是大多数基于节点的SAP项目的一部分。因此，不需要使用额外的包，这会增加node\u modules文件夹的大小。

在本节中，我想解释一些如何定义环境变量的方法。我相信这个列表还远远不够完整，大数据学习，但我想我提到了最常见和最有用的。如果我错过了一种方法，请在评论中告诉我。

Shell变量

使用本机操作系统命令可能是最常见的方法：

根据您的操作系统和使用的Shell，这些命令可能会有所不同。一般来说，这样定义的变量适用于从当前shell启动的所有进程。这种方法可以与shell配置文件相结合，使变量永久可用。像这样定义的环境变量只在本地机器上可用，在本地机器上它们已经被声明并且没有用git持久化。

流程变量

您也可以只为给定的流程定义环境变量。为此，您需要在命令前面加上声明。

Afaik，这只适用于Unix环境。这些变量仅在执行命令期间在计算机上可用。无法使用git之类的版本控制系统存储值。

基于包

以前的类别是特定于操作系统的，阿里大数据应用平台，但与所使用的运行时平台无关。此类别仅适用于节点.js，但我相信Java或Python也有类似的方法来实现相同的结果。

这两个包都允许使用Unicode字符作为变量，并写入文本文件。这样做的好处是，这些环境变量可以存储在版本控制系统中，因此，这些变量可以很容易地在团队成员/社区之间共享。因此，一旦项目部署到另一个（基于云的）环境中，变量也可用。

基于目标平台