web通用脚手架2
这个模板的基本架构和1是一样的，唯一的一点区别就是在设计上进行了优化。
因为在一盘的场景下，配置文件其实并不好读取，不如结构体要好读，于是这里进行的优化就是，将配置文件里面的配置项全部改成用结构体表示，这样显得更直观，而且就算改成用结构体表示，配置项和结构体还是可以完成数据更新的同步。
实现数据更新同步的思想：
1.仍然使用watch监控配置文件。
2.然后利用里面的那个钩子函数。一旦配置文件发生修改，就立即反序列化到这个全局结构体。
这样就完成了结构体的不断更新。反序列化要注意：结构体和配置文件直接要完成一个映射关系，这种映射关系一般是使用tag标签来实现。这里的反序列化的函数还是使用viper里面的Unmarshal(*全局结构体)来实现。但是viper里面用于映射的tag，不管是什么类型的配置文件（yaml，json），用的标签必须是mapstructure:“配置项”。
其他模块该如何变化：
在前一个模板1中。所有的Init中的配置项全是从配置文件中拉取，实质是配置文件被读取到了viper中，所以就从viper拉取。
那现在基于结构体来实现的话，由于已经说了配置项全改成结构体表示，那这里显然模块参数配置肯定就是从结构体中进行拉取。这个实现思路已经很明显了，此时的各模块的Init，那不就是这个全局结构体的方法。
所以各模块现在就是基于全局结构体的方法实现，因为这样我们很容易的就可以拿到结构体的字段进行模块内的配置填充。
首先层次理论要搞清楚，还是和模板一一样。
//1.加载配置文件
//2.日志初始化
//3.初始化mysql连接
//4.初始化redis连接
//5.注册路由
//6.启动服务
这就是我们项目的主要框架，也就是目标需求。模块化来解决。
1.加载配置文件
还是两个模块：一个conf，一个settings模块，conf放配置文件，settings进行viper的配置。
1.conf：conf就是个配置文件，没有什么代码逻辑。
config.yaml
name: "web_app"
mode: "dev"
port: 8080
version: "v0.1.4"
log:
level: "debug"
filename: "web_app.log"
max_size: 200
max_age: 30
max_backups: 7
mysql:
host: "127.0.0.1"
port: 13306
user: "root"
password: "root1234"
dbname: "sql_demo"
max_open_conns: 200
max_idle_conns: 50
redis:
host: "127.0.0.1"
port: 16379
password: ""
db: 0
pool_size: 100
2.settings这里就和模板1有点区别了，模板1是直接进行viper和配置文件的绑定。但是这里由于是要用结构体，那么这里就要完成viper和配置文件绑定，然后再从viper中反序列化到我的结构体。
一步步的来：
1.先根据config配置文件，先把结构体给写出来：
直接看上面的配置文件可以分析出：
顶层就是我们的web，有name，mode，port，version字段，然后下面三个显然就是嵌套结构体。然后把下面三个嵌套结构体的结构体也要写。
2.最后就是进行viper配置，和反序列化到我的结构体的操作。
注意事项：
package settings
import (
"fmt"
"github.com/fsnotify/fsnotify"
"github.com/spf13/viper"
)
// Conf 全局变量，用来保存程序的所有配置信息
//必须大写，这样大写对外暴露，实现全局可用。
var Conf = new(AppConfig)
type AppConfig struct {
Name string `mapstructure:"name"`
Mode string `mapstructure:"mode"`
Version string `mapstructure:"version"`
Port int `mapstructure:"port"`
*LogConfig `mapstructure:"log"`
*MySQLConfig `mapstructure:"mysql"`
*RedisConfig `mapstructure:"redis"`
}
type LogConfig struct {
Level string `mapstructure:"level"`
Filename string `mapstructure:"filename"`
MaxSize int `mapstructure:"max_size"`
MaxAge int `mapstructure:"max_age"`
MaxBackups int `mapstructure:"max_backups"`
}
type MySQLConfig struct {
Host string `mapstructure:"host"`
User string `mapstructure:"user"`
Password string `mapstructure:"password"`
DbName string `mapstructure:"db_name"`
Port int `mapstructure:"port"`
MaxOpenConns int `mapstructure:"max_open_conns"`
MaxIdleConns int `mapstructure:"max_idle_conns"`
}
type RedisConfig struct {
Host string `mapstructure:"host"`
Password string `mapstructure:"password"`
Port int `mapstructure:"port"`
DB int `mapstructure:"db"`
PoolSize int `mapstructure:"pool_size"`
}
//可以看到用到了结构体指针，既然是嵌套结构体，那么用结构体指针和不用结构体指针到底有什么区别？
不使用指针嵌入：
当你直接嵌入一个结构体（不使用指针）时，这个被嵌入的结构体成为了外层结构体的一个内联字段。这意味着：
1.嵌入的结构体与外层结构体在同一块内存中连续分布。
2.修改嵌入的结构体字段会直接影响外层结构体中的对应字段，因为它们共享同一内存区域。
3.当创建外层结构体的实例时，嵌入的结构体也会被自动初始化（分配内存并设置为零值）。
使用指针：
当你通过指针嵌入一个结构体时，这个被嵌入的结构体成为了外层结构体的一个指针字段。这意味着：
1.嵌入的结构体与外层结构体不再是连续分布的内存，而是通过指针引用。
2.修改嵌入的结构体字段仍然会影响到外层结构体中的对应字段，因为指针指向的是同一个结构体实例。
3.当创建外层结构体的实例时，嵌入的结构体指针默认为 nil，除非你显式地为其分配内存（例如，通过 new 或 &StructType{}）。
选择使用哪种方式
1.如果你需要共享嵌入结构体的实例或者允许嵌入结构体为 nil（可能表示某种状态，或者是可选配置不一定要设置），使用指针嵌入比较合适。
2.如果嵌入的结构体总是作为外层结构体不可分割的一部分存在，且不需要为 nil，那么直接嵌入（不使用指针）可能更简单且性能稍好一些，因为减少了一次间接引用。
//这里我还解决一个疑问：
//因为按我们平时的理解，比如我在写RedisConfig时，我想我能不能写tag的时候写成"Redis.Host"，这样比较方便？而且对于像Host这样的字段，不会因为redis和mysql中都有Host而在映射的时候产生冲突吗？
//回答是不需要（也不能），并不会产生冲突
//1.首先回答不能，因为语法错了。
//2.不会冲突，因为顶层结构体在Mysqlconfig那个内嵌结构体也进行了映射，所以是基于相对路径的映射，并不会冲突。
func Init() (err error) {
//直接指定这个文件在哪。
viper.SetConfigFile("./conf/config.yaml")
//viper.SetConfigName("config") // 指定配置文件名称（不需要带后缀）
//viper.SetConfigType("yaml") // 指定配置文件类型(专用于从远程获取配置信息时指定配置文件类型的)
viper.AddConfigPath(".") // 指定查找配置文件的路径（这里使用相对路径）
err = viper.ReadInConfig() // 读取配置信息
if err != nil {
// 读取配置信息失败
fmt.Printf("viper.ReadInConfig() failed, err:%v\n", err)
return
}
// 把读取到的配置信息反序列化到 Conf 变量中
if err := viper.Unmarshal(Conf); err != nil {
fmt.Printf("viper.Unmarshal failed, err:%v\n", err)
}
viper.WatchConfig()
viper.OnConfigChange(func(in fsnotify.Event) {
fmt.Println("配置文件修改了...")
//这就是个钩子函数，一旦配置文件发生修改，会马上调用viper的反序列化，使得结构体能够不断地与配置文件进行同步。
if err := viper.Unmarshal(Conf); err != nil {
fmt.Printf("viper.Unmarshal failed, err:%v\n", err)
}
})
return
}
这一套操作下来，就拿到了这个代表了我的配置文件的结构体。现在我的所有的配置都不用从viper里面去拉取了，而是可以直接通过访问这个全局结构体的字段进行获取配置，因为在通常的情况下，结构体要比配置文件具有更好的可读性。
然后在main函数里面启动一下这个模块
// 1. 加载配置
if err := settings.Init(); err != nil {
fmt.Printf("init settings failed, err:%v\n", err)
return
}
fmt.Println(settings.Conf)
fmt.Println(settings.Conf.LogConfig == nil)
2.初始化日志
这次我们先看main函数，因为我们有模板1 的知识，这里我们看看变化：
if err := logger.Init(settings.Conf.LogConfig); err != nil {
fmt.Printf("init logger failed, err:%v\n", err)
return
}
defer zap.L().Sync()
zap.L().Debug("logger init success...")
变化就是这里的参数，但是这就显得更直观了，这个结构体就代表了我的logger的所有配置项，我直接传这个结构体，然后从这个结构体拿配置项信息就行了。
模块实现：
package logger
import (
"net"
"net/http"
"net/http/httputil"
"os"
"runtime/debug"
"strings"
"time"
"web_app/settings"
"github.com/gin-gonic/gin"
"github.com/natefinch/lumberjack"
"go.uber.org/zap"
"go.uber.org/zap/zapcore"
)
// Init 初始化Logger
func Init(cfg *settings.LogConfig) (err error) {
//可以看到配置项全用的结构体的字段
writeSyncer := getLogWriter(
cfg.Filename,
cfg.MaxSize,
cfg.MaxBackups,
cfg.MaxAge,
)
encoder := getEncoder()
var l = new(zapcore.Level)
//就换了成了从结构体取
err = l.UnmarshalText([]byte(cfg.Level))
if err != nil {
return
}
core := zapcore.NewCore(encoder, writeSyncer, l)
lg := zap.New(core, zap.AddCaller())
// 替换zap库中全局的logger
zap.ReplaceGlobals(lg)
return
}
func getEncoder() zapcore.Encoder {
encoderConfig := zap.NewProductionEncoderConfig()
encoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder
encoderConfig.TimeKey = "time"
encoderConfig.EncodeLevel = zapcore.CapitalLevelEncoder
encoderConfig.EncodeDuration = zapcore.SecondsDurationEncoder
encoderConfig.EncodeCaller = zapcore.ShortCallerEncoder
return zapcore.NewJSONEncoder(encoderConfig)
}
func getLogWriter(filename string, maxSize, maxBackup, maxAge int) zapcore.WriteSyncer {
lumberJackLogger := &lumberjack.Logger{
Filename: filename,
MaxSize: maxSize,
MaxBackups: maxBackup,
MaxAge: maxAge,
}
return zapcore.AddSync(lumberJackLogger)
}
// GinLogger 接收gin框架默认的日志
func GinLogger() gin.HandlerFunc {
return func(c *gin.Context) {
start := time.Now()
path := c.Request.URL.Path
query := c.Request.URL.RawQuery
c.Next()
cost := time.Since(start)
zap.L().Info(path,
zap.Int("status", c.Writer.Status()),
zap.String("method", c.Request.Method),
zap.String("path", path),
zap.String("query", query),
zap.String("ip", c.ClientIP()),
zap.String("user-agent", c.Request.UserAgent()),
zap.String("errors", c.Errors.ByType(gin.ErrorTypePrivate).String()),
zap.Duration("cost", cost),
)
}
}
// GinRecovery recover掉项目可能出现的panic，并使用zap记录相关日志
func GinRecovery(stack bool) gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
// Check for a broken connection, as it is not really a
// condition that warrants a panic stack trace.
var brokenPipe bool
if ne, ok := err.(*net.OpError); ok {
if se, ok := ne.Err.(*os.SyscallError); ok {
if strings.Contains(strings.ToLower(se.Error()), "broken pipe") || strings.Contains(strings.ToLower(se.Error()), "connection reset by peer") {
brokenPipe = true
}
}
}
httpRequest, _ := httputil.DumpRequest(c.Request, false)
if brokenPipe {
zap.L().Error(c.Request.URL.Path,
zap.Any("error", err),
zap.String("request", string(httpRequest)),
)
// If the connection is dead, we can't write a status to it.
c.Error(err.(error)) // nolint: errcheck
c.Abort()
return
}
if stack {
zap.L().Error("[Recovery from panic]",
zap.Any("error", err),
zap.String("request", string(httpRequest)),
zap.String("stack", string(debug.Stack())),
)
} else {
zap.L().Error("[Recovery from panic]",
zap.Any("error", err),
zap.String("request", string(httpRequest)),
)
}
c.AbortWithStatus(http.StatusInternalServerError)
}
}()
c.Next()
}
}
总结：
可以看出就动了原本用viper配置项填参数的地方，别的地方都没有动。
初始化mysql
先看main函数
// 3. 初始化MySQL连接
if err := mysql.Init(settings.Conf.MySQLConfig); err != nil {
fmt.Printf("init mysql failed, err:%v\n", err)
return
}
defer mysql.Close()
还是和上面一样，直接传全局Conf里面的MySQLConfig进去
package mysql
import (
"fmt"
"web_app/settings"
"go.uber.org/zap"
_ "github.com/go-sql-driver/mysql"
"github.com/jmoiron/sqlx"
)
var db *sqlx.DB
func Init(cfg *settings.MySQLConfig) (err error) {
dsn := fmt.Sprintf("%s:%s@tcp(%s:%d)/%s?charset=utf8mb4&parseTime=True",
cfg.User,
cfg.Password,
cfg.Host,
cfg.Port,
cfg.DbName,
)
// 也可以使用MustConnect连接不成功就panic
db, err = sqlx.Connect("mysql", dsn)
if err != nil {
zap.L().Error("connect DB failed", zap.Error(err))
return
}
db.SetMaxOpenConns(cfg.MaxOpenConns)
db.SetMaxIdleConns(cfg.MaxIdleConns)
return
}
func Close() {
_ = db.Close()
}
总结：仍然是直接用结构体的字段取代viper的配置。
初始化redis
main：
if err := redis.Init(settings.Conf.RedisConfig); err != nil {
fmt.Printf("init redis failed, err:%v\n", err)
return
}
defer redis.Close()
模块：
package redis
import (
"fmt"
"web_app/settings"
"github.com/go-redis/redis"
)
// 声明一个全局的rdb变量
var rdb *redis.Client
// Init 初始化连接
func Init(cfg *settings.RedisConfig) (err error) {
rdb = redis.NewClient(&redis.Options{
Addr: fmt.Sprintf("%s:%d",
cfg.Host,
cfg.Port,
),
Password: cfg.Password, // no password set
DB: cfg.DB, // use default DB
PoolSize: cfg.PoolSize,
})
_, err = rdb.Ping().Result()
return
}
func Close() {
_ = rdb.Close()
}
总结：还是调用结构体的字段。
注册路由
main:
// 5. 注册路由
r := routes.Setup(settings.Conf.Mode)
模块：
package routes
import (
"net/http"
"web_app/logger"
"web_app/settings"
"github.com/gin-gonic/gin"
)
func Setup(mode string) *gin.Engine {
//这段代码的意思是，如果传入的 mode 参数等于 gin.ReleaseMode，那么就通过 gin.SetMode(gin.ReleaseMode) 设置 Gin 框架为生产模式（release mode）。gin.SetMode 函数用于设置 Gin 运行的模式。
//如果 mode 参数不等于 gin.ReleaseMode，则 Gin 会保持默认的运行模式，即 debug 模式，或者根据其他地方的设置决定运行模式。
//这样做的目的是让你可以根据不同的环境（开发环境、生产环境等）来调整 Gin 的运行模式，以适应不同的需求。例如，在开发环境中，你可能需要更多的调试信息来帮助开发和排错；而在生产环境中，则更关注性能和日志的精简。
if mode == gin.ReleaseMode {
gin.SetMode(gin.ReleaseMode)
}
r := gin.New()
r.Use(logger.GinLogger(), logger.GinRecovery(true))
r.GET("/version", func(c *gin.Context) {
c.String(http.StatusOK, settings.Conf.Version)
})
return r
}
这里面还有一个变化就是这个mode，这里我进行补充（我之前也不知道mode是什么）
gin框架有三种运行模式：debug、reluase和test。这些模式影响gin框架的行为，比如日志输出和错误处理。
debug 模式是默认模式，它会打印很多调试信息，包括路由匹配、中间件加载等。
release 模式是为生产环境准备的，它会减少日志输出，优化性能。
test 模式主要用于单元测试。
启动服务
基本没什么变化，就是有关viper的配置项信息的全改成结构体字段
// 6. 启动服务（优雅关机）
fmt.Println(settings.Conf.Port)
srv := &http.Server{
Addr: fmt.Sprintf(":%d", settings.Conf.Port),
Handler: r,
}
go func() {
// 开启一个goroutine启动服务
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("listen: %s\n", err)
}
}()
// 等待中断信号来优雅地关闭服务器，为关闭服务器操作设置一个5秒的超时
quit := make(chan os.Signal, 1) // 创建一个接收信号的通道
// kill 默认会发送 syscall.SIGTERM 信号
// kill -2 发送 syscall.SIGINT 信号，我们常用的Ctrl+C就是触发系统SIGINT信号
// kill -9 发送 syscall.SIGKILL 信号，但是不能被捕获，所以不需要添加它
// signal.Notify把收到的 syscall.SIGINT或syscall.SIGTERM 信号转发给quit
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM) // 此处不会阻塞
<-quit // 阻塞在此，当接收到上述两种信号时才会往下执行
zap.L().Info("Shutdown Server ...")
// 创建一个5秒超时的context
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
// 5秒内优雅关闭服务（将未处理完的请求处理完再关闭服务），超过5秒就超时退出
if err := srv.Shutdown(ctx); err != nil {
zap.L().Fatal("Server Shutdown", zap.Error(err))
}
zap.L().Info("Server exiting")
总结：
总体上就做了个viper与配置文件绑定，然后通过反序列化到一个全局结构体上（这样直观），然后通过这个全局结构体来进行各种配置。这样更加的直观。