首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Go语言微服务框架 - 2.实现加载静态配置文件

Go语言微服务框架 - 2.实现加载静态配置文件

作者头像
junedayday
发布2021-09-24 14:36:45
1.1K0
发布2021-09-24 14:36:45
举报
文章被收录于专栏:Go编程点滴Go编程点滴

我们的基础RPC服务已经正常运行,我们再来看下一个特性:配置文件的加载。

首先,我们要正确地认识到配置文件的重要性:在程序交付后,变更代码的成本很大;相对而言,变更配置文件的成本就比较小。但有的同学又走了另一个极端,也就是将大量的逻辑放入到配置文件中,导致配置文件膨胀,本质上就是将部分本应在代码中维护的内容转移到了配置文件,导致配置文件也很难维护。

今天,我们先将重点放到加载配置文件库的技术选型,顺便分享一些常见的问题。

一个基础的加载配置文件示例

Go语言中,用官方库就能快速实现配置文件的加载,下面就是一个简单的代码实现:

b, err := ioutil.ReadFile("config.json")
if err != nil {
  panic(err)
}
var config MyConfig
err = json.Unmarshal(b, &config)
if err != nil {
  panic(err)
}

关键的实现分为两块:

  1. 读取文件中的数据
  2. 将数据解析到Go程序的对象中,作为可识别的数据结构,这里指定了数据类型为json

v0.2.0:实现加载静态配置文件

项目链接 https://github.com/Junedayday/micro_web_service/tree/v0.2.0

目标

从配置文件中解析数据到程序中,并具备更高的可读性和扩展性。

关键技术点

  1. 命令行参数与配置文件的差异
  2. github.com/spf13/viper的介绍
  3. 使用viper库的推荐方式

目录构造

github.com/spf13/viper中存在一个全局变量var v *Viper(点击查看),如果我们调用默认的viper包,其实就是将参数解析到这个全局变量中。

在具体的项目中,更推荐的方式是将这个变量保存到内部项目中,作为一个项目中的全局变量,所以我们会新建一个viper.New()。配置参数会被全局调用,为了保证不会发生循环依赖,我们就需要一个专门的package来保存这个全局变量,这里对应项目中的internal/config/viper.go

--- micro_web_service            项目目录
 |-- gen                            从idl文件夹中生成的文件,不可手动修改
    |-- idl                             对应idl文件夹
       |-- demo                             对应idl/demo服务
          |-- demo.pb.go                        demo.proto的基础结构
          |-- demo.pb.gw.go                     demo.proto的HTTP接口,对应gRPC-Gateway
          |-- demo_grpc.pb.go                   demo.proto的gRPC接口代码
 |-- idl                            原始的idl定义
    |-- demo                            业务package定义
       |-- demo.proto                       protobuffer的原始定义
 |-- internal                       项目的内部代码,不对外暴露
    |-- server                          服务器的实现
       |-- demo.go                          server中对demo这个服务的接口实现
       |-- server.go                        server的定义,须实现对应服务的方法
    |-- config                          新增:配置相关的文件夹
       |-- viper.go                         新增:viper的相关加载逻辑
 |-- buf.gen.yaml                   buf生成代码的定义
 |-- buf.yaml                       buf工具安装所需的工具
 |-- gen.sh                         buf生成的shell脚本
 |-- go.mod                         Go Module文件
 |-- main.go                        项目启动的main函数

1.命令行参数与配置文件的差异

命令行参数类似于./demo --config=a.yaml --http_port=8080 --grpc_port=8081Go语言中自带flag包可供解析,开源的有pflag和相关的扩展工具,如cobra

而配置文件则是将参数从文件解析到内存中,一般用读取文件+反序列化工具来使用。

同样是解析参数到程序里,我们该选择哪种方案呢?我们从可读性和可维护性来对比下:

  • 可读性:命令行参数是扁平化的,可读性远不如格式化后的配置文件
  • 可维护性:配置文件增加了一个维护项,但成本不高

所以,我个人倾向于的方案是:

  • 命令行参数:用于维护极少量关键性的参数,如配置文件的路径
  • 配置文件:维护绝大多数的参数

在某些极端的场景中,比如提供一个纯二进制文件作为工具,那不得不把所有配置参数都放入到命令行参数中。这并不是我们微服务框架要讨论的场景。所以,接下来我们重点讨论配置文件的加载。

关于pflag相关的内容,在后续程序复杂到一定阶段后会引入。

2.github.com/spf13/viper的介绍

对比上面的方案,我们来看一个业内使用最广的Go语言配置加载库github.com/spf13/viper的实现,对应的代码如下:

viper.SetConfigName("config")        // config file name without file type
viper.SetConfigType("yaml")          // config file type
viper.AddConfigPath("./")            // config file path
if err := viper.ReadInConfig(); err != nil {
  panic(err)
}

而在获取配置文件时,又采用key-value形式的语法:

viper.GetInt("server.grpc.port")

详细的特性我会在Go语言技巧系列里说明,今天我们聚焦于工程侧的宏观特性,来聊聊这个库的优劣势:

可选的参数序列化

viper库的源码中(点击跳转),我们可以看到它支持多种本地文件类型远程k-v数据库

// SupportedExts are universally supported extensions.
var SupportedExts = []string{"json", "toml", "yaml", "yml", "properties", "props", "prop", "hcl", "dotenv", "env", "ini"}

// SupportedRemoteProviders are universally supported remote providers.
var SupportedRemoteProviders = []string{"etcd", "consul", "firestore"}

我们先忽略远程的存储,先看一下最常用的几个序列化的库:

  1. JSON: 官方自带的encoding/json
  2. TOML: 开源的github.com/pelletier/go-toml
  3. YAML: 官方推荐的gopkg.in/yaml.v2
  4. INI:官方推荐的gopkg.in/ini.v1

在这四种技术选型时,我个人倾向于选择JSONYAML。进一步斟酌时,虽然JSON的适用范围最广,但当配置文件复杂到一定程度时,JSON格式的配置文件很难通过换行来约束,当存在大量的嵌套时,可读性很差。所以,我个人比较推荐使用YAML格式的配置文件,一方面通过强制的换行约束,可读性很棒;另一方面云原生相关技术大量使用了YAML作为配置文件,尤其是Kubernetes中各种定义。

例如,我们将服务的端口改造到配置文件里,就成了:

server:
  http:
    port: 8081
  grpc:
    port: 8082

对应的Go语言代码为:

viper.GetInt("server.http.port")
viper.GetInt("server.grpc.port")

可扩展的获取参数方法

viper库提供的获取参数方式为viper.Get{type}("{level1}.{level2}.{level3}...")的格式。随着配置文件的扩大,也只需新增Get方法即可。

从获取参数的方法来看,它的设计分为3种:

  1. 基本类型,直接提供Get{具体类型}的方法,如GetIntGetString
  2. 任意类型,提供Get(key string) interface{},自行转化
  3. 复杂类型的反序列化,提供UnmarshalKey等方法,更方便地获取复杂结构

我个人建议各位只使用第一类的方法,将配置文件这个模块做到最简化。毕竟,配置文件的复杂化很容易引入各种问题,占用大量的排查故障的时间。如果你的系统必须引入一套非常复杂的配置,那么我更建议将它独立成一个专门的服务,用来维护这套配置。

3.使用viper库的推荐方式

如果你仔细地阅读viper相关的代码,你会发现它有很多超酷的特性。但今天,我想告诉各位:请克制地使用进阶的特性,最棒的特性往往是简洁的

我们对照着官方的README文件中介绍的特性进行讲解。

尽量避免手动设置的参数值

原文链接

viper.SetDefault函数可以给某些参数设置默认值,如果只是少数的几个参数还是很容易维护的。但如果设置的值过多了,就会给阅读代码的人带来困扰:这个参数是来自配置文件,还是在代码某处手动设置的?也就是存在二义性,增加了排查问题的复杂度。

明确配置文件的来源

原文链接

viper.AddConfigPath("/etc/appname/")   // path to look for the config file in
viper.AddConfigPath("$HOME/.appname")  // call multiple times to add many search paths
viper.AddConfigPath(".")               // optionally look for config in the working directory

viper支持多个配置文件的路径,这虽然带来了便利性,但如果多个文件路径中都存在配置文件,那究竟以哪个为准?这也是一个二义性的问题,所以我个人更建议只设置一个,而这个路径由flag传入。

静态配置与动态配置的分离

原文链接

viper提供了接口viper.WatchConfig(),可以监听文件的变化,然后做相应的调整。这个特性很酷,我们可以用它实现热加载。但这个特性很容易让人产生混淆:例如发生了某个BUG,如何确定当时的配置文件情况?其实,这就需要引入一定的版本管理机制。

我更建议采用静态配置和动态配置分离的方案,也就是配置文件负责静态的、固定的配置,一旦启动后只加载一次;而动态的配置放在带版本管理的配置中心里,具备热加载的特性。

所以,我不太建议在配置文件这里引入监听文件变化的特性。

核心代码示例

main.go

flag中解析出配置文件路径,传到config包中用于解析。

var configFilePath = flag.String("c", "./", "config file path")
flag.Parse()

if err := config.Load(*configFilePath); err != nil {
  panic(err)
}

internal/config/viper.go

加载的代码并不多,尽量保证配置信息的简洁易懂。

// 全局Viper变量
var Viper = viper.New()

func Load(configFilePath string) error {
 Viper.SetConfigName("config")       // config file name without file type
 Viper.SetConfigType("yaml")         // config file type
 Viper.AddConfigPath(configFilePath) // config file path
 return Viper.ReadInConfig()
}

配置使用方

config.Viper.GetInt("server.grpc.port")

使用viper库的注意事项

在使用viper获取配置时,我们需要手动组装key,也就是"{level1}.{level2}.{level3}..."这种形式。这时,我们只能对照着原始配置文件逐个填充字段,一不小心填错、就会发生奇怪的问题。而如果采用的是将配置文件解析到结构体的方法,就能很容易地避免这个问题。

考虑到扩展性,官方库推荐的是手动组装key的方式,所以需要大家在认真查看这个key是否有效。

总结

加载静态配置文件是一个很常见的功能,viper提供了一套完整方案,兼具简洁和扩展性;与此同时,我们要学会克制,不要看到了viper中提供的各种特性、就想着应用到实际项目中,也就是常说的:手里拿了个锤子,看啥都是钉子

Github: https://github.com/Junedayday/code_reading Blog: http://junes.tech/ Bilibili: https://space.bilibili.com/293775192 公众号: golangcoding

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Go编程点滴 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 我们的基础RPC服务已经正常运行,我们再来看下一个特性:配置文件的加载。
    • 一个基础的加载配置文件示例
      • v0.2.0:实现加载静态配置文件
        • 目标
        • 关键技术点
        • 目录构造
      • 1.命令行参数与配置文件的差异
        • 2.github.com/spf13/viper的介绍
          • 可选的参数序列化
          • 可扩展的获取参数方法
        • 3.使用viper库的推荐方式
          • 尽量避免手动设置的参数值
          • 明确配置文件的来源
          • 静态配置与动态配置的分离
        • 核心代码示例
          • main.go
          • internal/config/viper.go
          • 配置使用方
        • 使用viper库的注意事项
          • 总结
          相关产品与服务
          文件存储
          文件存储(Cloud File Storage,CFS)为您提供安全可靠、可扩展的共享文件存储服务。文件存储可与腾讯云服务器、容器服务、批量计算等服务搭配使用,为多个计算节点提供容量和性能可弹性扩展的高性能共享存储。腾讯云文件存储的管理界面简单、易使用,可实现对现有应用的无缝集成;按实际用量付费,为您节约成本,简化 IT 运维工作。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档