前言

这是《程序员如何让自己 Be Cloud Native》系列文章的第二篇，从第一篇的反馈来看，有些同学反馈十二要素太形式主义，不建议盲目跟从。作者认为任何理论和技术都需要有自己的观点，这些观点是建立在个体知识体系逐渐锻炼出来的辩别能力之上的。Be Cloud Native这一系列的文章，会基于十二要素为理论基础，加上作者在云计算诞生以来对于架构的演进所观察到的变化去分享自己的一些心得。

第一篇：仓库与依赖。「传送门」

实例

配置这个要素的核心思想就是代码与数据隔离，一开始我们的软件很小很小的时候，我们会可能直接把各种配置、甚至生产环境中的代码直接写在代码中，配置甚至就是代码的一部分？比如以下的这断代码就是这样：

public boolean serviceConnectable() {return ping("edas.console.aliyun.com", 3);}

该方法实现一个本地是否可以连接到远端 server 的功能。如果按照上面的代码进行编写，只能保证在公共云的环境达到想要的效果。该程序如果部署到了一个专有云或者 IDC 的环境中的时候，就需要改代码了。

如果改成以下的方式，效果就会截然不同。那时如果程序部署到了一套新的环境中，只需改变edas.server.address 这个配置。

@Value("edas.server.address")
private String remoteAddress;public boolean serviceConnectable() {
return ping(remoteAddress, 3);}

定义与示例

这个例子应该比较贴近大家的日常，我们将上面这个例子往上提升一层，可以做出一个如下的初步定义：应用的行为(_Behavior_) = 代码(_Code_) + 输入(_Data_)。代码是固定的，需要重新编译分发，无法根据环境进行变化的；而输入是活的。上面的例子，就是一个把 Code 中的一部分内容抽离，变成 Data 的过程。做完这个变化之后，应用对变化的适应性就更强了。当然，这些 Data 有些是用户输入的，有些是系统启动时就已经确定的，后者是我们定义的 配置 ，也是我们今天讨论的主题。从这个层面(_Data_)说起来，配置其实可以包含很多种，以 Java 语言为例，至少分为以下几种：

• 代码中的文件配置: *.properties 文件。
• 机器上的文件配置 *.properties 文件。
• 通过 -D 参数指定的启动参数。
• 环境变量。
• 配置管理系统，简单的有 DB；比较流行的领域产品如 Nacos、ZooKeeper、ectd 等。

选择多了，貌似世界就不那么美妙了，因为我们总是会陷入到“用什么”和“为什么”中去。作者的观点是，在用什么之前，先弄清楚需求层面的两点：

• 隔离粒度：每个版本不一样？每台机器不一样？每个进程不一样？
• 安全性：运维人员可见？开发人员可见？还是都不应该可见？

仔细讨论上述两点之前，我们举几个关于配置的例子：

• 程序版本号：从代码 Release (build) 开始，基本上就确定了；这一类配置基本上不存在变化的可能，即这一类配置的隔离粒度等同于 Code 。
• 某个前端组件的版本号：前端版本号有一个特点，就是变动很频繁，尤其是在上线的过程中，发布三四个版本是很常见的现象；而且在上线的过程中，一般都会先灰度验证，再进行现网发布。所以这类配置需要具备一个特点就是，可灵活变动与可按照环境（不同机器、不同流量）粒度发布。
• 服务器端口号：服务器的端口号是需要和进程绑定的，尤其在某些微服务场景；同一个服务，如果部署在同一台机器上，必须准确的告知其他服务本服务的确切的地址和端口。
• 数据库元信息配置：这种配置，同一套环境中的相同服务会是一样的，而且其真实的值隐藏的越深越好，其他还有某些 AK/SK、用户名密码之类，每套环境会不一样，同时不同的产品对待这类配置的安全性要求也可能不一样。

归纳

通过上面例子简单的论述，我们大致可以把相关的配置做如下的归类：

这里作者想额外强调的是安全性这一个点，尤其某些金融场景。原生的配置方式，如果不做代码的改动的话，都无法做到很高的安全性，但是在一些分布式产品中，尤其是一些云产品内部，就可以做到很安全，具体可以参考下图：

以 Nacos 的云上实现 ACM 为例，对上图进行一个简单的阐述。一般的程序读取配置方式如左图，当执行启动脚本后，应用程序从脚本中设置的环境变量、文件或启动参数中获取配置。这些方式可以满足大部分的场景，但是如果你的应用是一个分布式的大集群，这个时候如果想改一个配置是不可能在机器上配置的，然后一台台的区修改，此时我们需要一个支持大集群的分布式配置服务来支持。开源的配置中心有很多，如 ZooKeeper、etcd、Nacos 等。

但是有一种场景，一般意义上的配置中心也是满足不了的，那就是诸如数据库密码这一类安全性要求很高的配置。这类在云上会有一些很好的实现，以上图右边为例解释一下在云上是如何做到的：

• 当用户往配置服务中写入一个配置时，会先使用加密服务进行加密，图中的 A。
• 如果有客户端需要，将相应的加密数据推往对应的客户端，图中的 B。
• 客户端收到数据，会根据机器上的_云角色_，请求云加密服务进行解密，图中的 C。

从上面这个描述，我们就能很感受到整个过程，利用云生态的能力，可以做得很优雅、很安全，而且也没有额外的代码侵入。

总结

写到这里，我需要点一下题，要做到 “Be Cloud Native” ，配置是必不可少的一个环节。能让我们的世界变得稍微美好点的方式之一，就是把每个硬编码的字符，变成一个个可运维、安全的配置。

同时在云上，我们会看到有不一样的、更加优雅、更安全、成本更低的解决方案。配置的安全无小事，一时图简单省事，可能就会造成生产级别的敏感信息、甚至 DB 的泄露。

Be Cloud Native 的另外一层意思，正是尽可能多的利用云厂商提供的原生技术能力，来构建一个更安全、优雅、可扩展、高可用的应用架构。