mysql-微服务集中式数据库模型

当前,我们有一些microservice,它们有自己的数据库模型,并且可以迁移GORM Golang软件包提供的内容.我们有一个很大的旧MySQL数据库,它违反了微服务法,但是我们不能替代它.恐怕当微服务数量开始增长时,我们将迷失在许多数据库模型中.当我在微服务中添加新列时,我只是键入将服务迁移到终端(因为运行和迁移命令存在cli),并且它刷新了数据库.

什么是管理它的最佳实践.例如,我有1000个微服务,当有人刷新模型时,没有人会键入服务迁移.我正在考虑一个集中式数据库服务,我们在其中添加一个新列,它存储所有迁移的所有模型.唯一的问题是,服务将如何了解数据库模型的更改.例如,这就是我们在服务中存储用户的方式：

type User struct {
    ID        uint           `gorm:"column:id;not null" sql:"AUTO_INCREMENT"`
    Name      string         `gorm:"column:name;not null" sql:"type:varchar(100)"`
    Username  sql.NullString `gorm:"column:username;not null" sql:"type:varchar(255)"`
}

func (u *User) TableName() string {
    return "users"
}

解决方法:

如果我正确理解了您的问题,则您仍在尝试使用一个MySQL实例,但要使用许多微服务.

有两种方法可以使SQL系统正常工作：

>您可以创建一个微服务类型,该类型可以处理数据库中的数据插入/读取,并利用connection pooling.让其余服务通过这些服务执行所有数据读取/写入操作.这肯定会给您的所有写/读操作增加一点额外的延迟,并且可能在规模上带来问题.
>您可以尝试寻找易于扩展的多主站SQL解决方案(例如CitusDB),并且可以为数据库使用中央模式,并确保处理数据插入(去重复等)的边缘情况.
>您可以使用数据流架构(例如Kafka或AWS Kinesis)将数据传输到微服务,并确保它们仅通过这些流处理数据.这样,您可以将数据库与数据分离.

我认为最好的方法是#3.这样,您就不必考虑微服务体系结构的计算层上的存储.

不确定您要为微服务使用哪种服务,但是StdLib会强制进行一些转换(例如,仅通过HTTP传输数据),从而帮助人们全神贯注. AWS Lambda还可以与Kinesis一起很好地作为启动该功能的源,该功能可能有助于#3方法.

免责声明：我是StdLib的创​​始人.

标签：go,microservices,mysql,database
来源： https://codeday.me/bug/20191111/2022408.html