专业商城网站设计制作,在线建筑设计,网站开发工具 下载,网站定制那个好前言
这是《程序员如何让自己 Be Cloud Native》系列文章的第二篇#xff0c;从第一篇的反馈来看#xff0c;有些同学反馈十二要素太形式主义#xff0c;不建议盲目跟从。作者认为任何理论和技术都需要有自己的观点#xff0c;这些观点是建立在个体知识体系逐渐锻炼出来的…前言
这是《程序员如何让自己 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 的另外一层意思正是尽可能多的利用云厂商提供的原生技术能力来构建一个更安全、优雅、可扩展、高可用的应用架构。
#阿里云开年Hi购季#幸运抽好礼 点此抽奖https://www.aliyun.com/acts/product-section-2019/yq-lottery?utm_contentg_1000042901
原文链接 本文为云栖社区原创内容未经允许不得转载。
