2.14 思考

2.14.1 总结

至此，我们已经完成了这一章节的博客后端项目的编写，在整个项目中，我们从零开始实现，经历了技术框架选型、需求分析、数据库设计、项目工程设计、API 文档了解和编写、业务接口编写、接口访问控制、链路追踪等八个模块的编写。

与此同时我们还在文章中进行了一些深入的思考，受限于篇幅可能没法展开的过多，但是这对于你在构建了该项目的一个整体思维后会有一定的拓展，希望你能够对整体进行复盘，举一反三，将会对你的工程思维有进一步的提升。

2.14.2 作业

实践是认识的基础，完成了本章节的系列编写只是你的第二步，本节属于本书中具有一定业务逻辑性的特殊章节，因此接下来我会给你布置一些实践课题（常见功能点），你可以选择将其完成，让这个项目更加的完美，我相信你也会因此得到更多的知识和拓展面，同时更重要的是完成作业能够促进你的更进一步思考，若有疑问也欢迎随时探讨，作业的需求细项如下：

1. 实现标签和标签接口去重的判断逻辑：

   现在业务模块的标签和文章接口没有做去重判断，因此你需要在新增标签和文章时，判断是否已经存在于数据库中，若不存在则允许插入，存在则拒绝插入，返回其已存在的业务错误码提醒。

2. 实现文章与标签的一对多的关系：

   目前的接口设计只允许一篇文章对应一个标签，而一篇文章有时候会允许存在多个标签信息，因此我们需要对它进行改造，支持一篇文章设置多个标签信息。

3. 实现文章与标签的数据库事务的逻辑：

   这其实与第 2 个需求相关联，实际上在实现文章与标签的一对多关系后，你就会遇到一个问题，如果说在插入文章的多个标签时，其中一个标签失败了，那怎么办呢，实际上这时候就需要用到数据库的事务了，因此你在程序的业务接口逻辑处理中需要进行事务的处理，保证一致性。

   简单来讲，就是要通过开启事务，实现当插入文章的多个标签时，如果有其中一个插入失败了，就直接 Rollback，全部都插入的成功下才允许 Commit。

4. 实现支持多图片上传的接口：

   现在的上传图片接口是仅支持单文件上传的，但某个迭代中，需求突变，想要做图册，因此现在要支持多个图片上传了，为了提高效率，你需要新编写一个支持多张图片上传的接口。

5. 实现支持分布式的限流器：

   我们在章节中实现的限流器，它是基于本地计数器去做的，那么如果在分布式的环境下，它可能就会有问题，因为假设我的需求是针对全部后端服务的某个路由限流， 那么使用本地的计算器就会有问题，它只会单独每一个 Go 进程去进行累加计算。为了解决这个问题，你需要利用 Redis 实现 Token Bucket，让其成为一个支持分布式的限流器。