🍕 Go 食品配送微服务

Go 食品配送微服务是一个虚构的实用食品配送微服务，使用 Golang 和不同的软件架构及技术构建，如微服务架构、垂直切片架构、CQRS 模式、领域驱动设计 (DDD)、事件溯源、事件驱动架构和依赖注入。对于独立服务之间的通信，我们使用 RabbitMQ 进行异步消息传递，有时我们使用 REST 和 gRPC 调用进行实时通信的同步通信。

您可以将此项目作为模板来构建您的 Go 语言后端微服务项目

💡 此应用程序不是面向业务的，我主要关注技术部分，我只想使用不同的技术、软件架构设计、原则以及我们创建微服务应用所需的所有内容来实现一个示例。

🚀 此应用程序正在进行中，我将随着时间的推移添加新功能和技术。

对于您最简单的 Golang 项目，您可以使用我的 go-vertical-slice-template 项目：

https://github.com/mehdihadeli/go-vertical-slice-template

对于更高级的项目，带有两个微服务和模块化单体架构，请查看 C# 版本：

特性

✅ 使用垂直切片架构作为高级架构
✅ 使用基于 RabbitMQ 消息代理的事件驱动架构，带有自定义事件总线
✅ 在目录读取服务中使用基于 CRUD 的数据中心架构
✅ 在审计基础服务中使用事件溯源，如订单服务
✅ 使用基于 Go-MediatR 库的CQRS 模式和中介者模式
✅ 使用基于 uber-go/fx 库的依赖注入和控制反转
✅ 使用 Echo 框架的 RESTFul API，并使用 swaggo/swag 库进行 swagger
✅ 使用 gRpc 进行内部服务通信
✅ 使用 go-playground/validator 和 go-ozzo/ozzo-validation 验证 REST 和 gRpc 中的输入数据
✅ 使用 Postgres 和 EventStoreDB 作为写入数据库，完全支持事务(ACID)
✅ 使用 MongoDB 和 Elastic Search 作为读取数据库 (NOSQL)
✅ 使用 OpenTelemetry 收集使用 Jaeger 和 Zipkin 的分布式追踪
✅ 使用 OpenTelemetry 收集使用 Prometheus 和 Grafana 的指标
✅ 使用单元测试测试小单元，模拟依赖类，并使用 Mockery 模拟依赖
✅ 使用端到端测试和集成测试，使用 docker 容器（清理测试）和 testcontainers-go 库测试具有所有真实依赖的功能
✅ 使用 Zap 和结构化日志记录
✅ 使用 Viper 进行配置管理
✅ 使用 docker 和 docker-compose 进行部署
🚧 在某些服务中使用领域驱动设计，如目录写入服务和订单服务
🚧 使用 Helm 和 Kubernetes 进行部署
🚧 对所有微服务使用 Outbox 模式，以实现保证交付或至少一次交付
🚧 使用 Inbox 模式 处理接收方的幂等性和精确一次交付

技术 - 库

[此处列出了所有使用的技术和库，保持原文]

项目布局和结构

每个微服务都基于以下项目结构：

标准 Go 项目布局

系统架构

应用程序结构

在这个项目中，我使用了垂直切片架构或重构为垂直切片架构，同时我还在这个项目中使用了特性文件夹结构。

我们将每个请求视为一个独特的用例或切片，封装并分组从前端到后端的所有关注点。
当我们在 n 层架构的应用程序中添加或更改功能时，我们通常会触及应用程序中许多不同的"层"。我们正在更改用户界面、向模型添加字段、修改验证等。我们沿着切片垂直耦合，而不是跨层耦合，每个更改只影响一个切片。
我们最小化切片之间的耦合，并最大化切片内的耦合。
使用这种方法，我们的每个垂直切片都可以自行决定如何最好地满足请求。新功能只添加代码，我们不会更改共享代码并担心副作用。对于实现垂直切片架构，使用 CQRS 模式是一个很好的匹配。

这里我还使用了 CQRS 来将功能分解成非常小的部分,使我们的应用:

最大化性能、可扩展性和简单性。
向这个机制添加新功能非常容易,不会对代码的其他部分造成破坏性变更。新功能只增加代码,我们不会更改共享代码并担心副作用。
易于维护,任何更改只影响一个命令或查询(或一个切片),避免对其他部分造成任何破坏性变更。
它为我们的代码提供了更好的关注点分离和横切关注点(在 MediatR 行为管道的帮助下),而不是一个大型服务类来做很多事情。

通过使用 CQRS,我们的代码将更符合 SOLID 原则,特别是:

单一责任规则 - 因为负责给定操作的逻辑被封装在它自己的类型中。
开闭规则 - 因为要添加新操作,你不需要编辑任何现有类型,而是需要添加一个带有代表该操作的新类型的新文件。

这里我们不是使用某种技术拆分,例如为我们的 services、controllers 和 data models 设置文件夹或层,这会增加技术拆分之间的依赖性,并且需要在层或文件夹之间跳转。我们将每个业务功能切割成一些垂直切片,在每个切片内部,我们有特定于该功能的技术文件夹结构 (命令、处理程序、基础设施、仓储、控制器、数据模型等)。

通常,当我们处理给定功能时,我们需要一些技术性的东西,例如:

API 端点(控制器)
请求输入(Dto)
请求输出(Dto)
一些处理请求的类,例如命令和命令处理程序或查询和查询处理程序
数据模型

现在我们可以将所有这些东西放在一起,这减少了在一些层或文件夹之间的跳转和依赖。

保持这种拆分与 CQRS 配合得很好。它隔离了我们的操作,并垂直而非水平地切割应用程序代码。在我们的 CQRS 模式中,每个命令/查询处理程序是一个单独的切片。这就是你可以减少层之间耦合的地方。每个处理程序可以是一个独立的代码单元,甚至可以复制/粘贴。多亏了这一点,我们可以调整特定的方法以不遵循一般约定(例如使用自定义 SQL 查询或甚至不同的存储)。在传统的分层架构中,当我们在一层中改变核心通用机制时,它可能会影响所有方法。

高级结构

待办

格式化

在这个应用中,我使用 Conventional Commit,并且为了强制执行其规则,我使用 conventional-changelog/commitlint 和 typicode/husky 以及一个预提交钩子。要了解更多关于其设置的信息,请查看 commitlint 文档和这篇文章以及这篇文章。

为了在 IDE 级别应用 golangci-lint,我使用 intellij-plugin-golangci-lint 插件。

对于格式化,我在我的 GoLand 中使用了 mvdan/gofumpt、goimports-reviser、golines 和 golangci-lint,对于每个包,都有一个关于如何在你的 IDE 中设置它的指南,例如这里是 goimports-reviser 的配置。

此外,你可以通过在开发环境中安装 husky 来自动控制这种格式化,在任何提交之前:

安装工具:

make install-tools

安装 NPM:

npm init

安装 CommitLint:

npm install --save-dev @commitlint/config-conventional @commitlint/cli

创建 commitlint.config.js 文件,内容如下:

module.exports = { extends: '@commitlint/config-conventional']};

安装 Husky:

npm install husky --save-dev

在 package.json 文件中添加 prepare 命令,用于安装和激活我们将在下一步添加的 husky hooks:

npm pkg set scripts.prepare="husky install"

创建 Husky 文件夹:

mkdir .husky

添加提交前的 lint 和格式化钩子:

npx husky add .husky/pre-commit "make format && git add -A ."
npx husky add .husky/pre-commit "make lint && git add -A ."

在提交前添加 CommitLint 到 husky:

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'

使用此命令激活并安装所有 husky 钩子:

npm run prepare

开发中的实时重载

对于开发模式下的实时重载,我使用 air 库。关于使用这些工具的指南,你可以阅读这篇文章。

要在 实时重载模式 下运行每个微服务,在每个服务文件夹中输入以下命令(在安装 air 之后):

air

贡献

该应用程序处于开发状态。您可以随时根据贡献指南提交拉取请求或创建问题。

许可证

该项目使用 MIT 许可证。

go-food-delivery-microservices