2.14 思考
2.14.1 总结
至此,我们已经完成了这一章节的博客后端项目的编写,在整个项目中,我们从零开始实现,经历了技术框架选型、需求分析、数据库设计、项目工程设计、API 文档了解和编写、业务接口编写、接口访问控制、链路追踪等八个模块的编写。
与此同时我们还在文章中进行了一些深入的思考,受限于篇幅可能没法展开的过多,但是这对于你在构建了该项目的一个整体思维后会有一定的拓展,希望你能够对整体进行复盘,举一反三,将会对你的工程思维有进一步的提升。
2.14.2 作业
实践是认识的基础,完成了本章节的系列编写只是你的第二步,本节属于本书中具有一定业务逻辑性的特殊章节,因此接下来我会给你布置一些实践课题(常见功能点),你可以选择将其完成,让这个项目更加的完美,我相信你也会因此得到更多的知识和拓展面,同时更重要的是完成作业能够促进你的更进一步思考,若有疑问也欢迎随时探讨,作业的需求细项如下:
实现标签和标签接口去重的判断逻辑:
现在业务模块的标签和文章接口没有做去重判断,因此你需要在新增标签和文章时,判断是否已经存在于数据库中,若不存在则允许插入,存在则拒绝插入,返回其已存在的业务错误码提醒。
实现文章与标签的一对多的关系:
目前的接口设计只允许一篇文章对应一个标签,而一篇文章有时候会允许存在多个标签信息,因此我们需要对它进行改造,支持一篇文章设置多个标签信息。
实现文章与标签的数据库事务的逻辑:
这其实与第 2 个需求相关联,实际上在实现文章与标签的一对多关系后,你就会遇到一个问题,如果说在插入文章的多个标签时,其中一个标签失败了,那怎么办呢,实际上这时候就需要用到数据库的事务了,因此你在程序的业务接口逻辑处理中需要进行事务的处理,保证一致性。
简单来讲,就是要通过开启事务,实现当插入文章的多个标签时,如果有其中一个插入失败了,就直接 Rollback,全部都插入的成功下才允许 Commit。
实现支持多图片上传的接口:
现在的上传图片接口是仅支持单文件上传的,但某个迭代中,需求突变,想要做图册,因此现在要支持多个图片上传了,为了提高效率,你需要新编写一个支持多张图片上传的接口。
实现支持分布式的限流器:
我们在章节中实现的限流器,它是基于本地计数器去做的,那么如果在分布式的环境下,它可能就会有问题,因为假设我的需求是针对全部后端服务的某个路由限流, 那么使用本地的计算器就会有问题,它只会单独每一个 Go 进程去进行累加计算。为了解决这个问题,你需要利用 Redis 实现 Token Bucket,让其成为一个支持分布式的限流器。
本图书由 煎鱼©2020 版权所有,所有文章采用知识署名-非商业性使用-禁止演绎 4.0 国际进行许可。