程序员如何让本身 Be Cloud Native - 配置篇

前言

这是《程序员如何让本身 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 的另一层意思，正是尽量多的利用云厂商提供的原生技术能力，来构建一个更安全、优雅、可扩展、高可用的应用架构。

 

原文连接

本文为云栖社区原创内容，未经容许不得转载。