从零开始搭建一个简单实用的微服务模板 Part 2

[Gota]

这是用 Go 写微服务系列第二篇, 围绕于业务层中的标准方法展开.

主要内容如下:

1. 如何实现 Google API 设计指南中的五个标准方法
2. 如何处理声明式参数绑定和校验
3. 如何简化和复用处理 SQL 事务的代码

由于里面处理事务的方式是我自己想的, 所以如果有更直观的方案 (尽量不加额外的依赖) 欢迎留言讨论.

照例贴下第一段引言.

---

引言

在 前篇文章 中我们搞定了最基础的三件事: 启动, 路由, 可观测性. 正因为基础, 所以这部分代码的变化频率也是最低的.

这次我们就集中精力来处理变化稍快的业务层. 按照我们之前的规则, 业务层其实也可以分成两部分: API 和 具体实现. 其中 API 较为稳定, 很少出现破环性的变更, 一般维护良好的 API 会充分考虑其兼容性. 相较而言, 具体实现的变化速度就快得多了.

由于这篇文章的主要目的还是带着大家一起写代码, 所以如何得到一个设计良好的 API 就不是本篇的重点了, 想深入了解的话推荐读读看 <软件设计哲学> 这本书. 这里我就直接采用 Google API 设计指南 中的接口方案了, 可以稍微浏览下, 有个大概的概念.

至于业务场景, 就假想一个购物车的场景吧, 之后正好可以用来说明事务处理相关的流程. 数据库选择 SQLite, 这样方便在本地把 Demo 跑起来.

另外, 这次我考虑把篇幅稍微控制一下, 上次一口气写太多了, 估计读起来也挺累的 XD.

全篇链接: https://blog.igota.net/posts/20220427/

[lanlanye]

前篇地址 404 ，不过通过 blog 找到了，支持干货。
说到 Google API Design ，Golang 主流的 router 在处理 URL 参数时都选择了冒号前缀，很难受;(

[Gota]

@lanlanye 谢谢反馈.
由于贴的时候直接 Copy 的原始 Markdown 文件, 没注意改相对路径, 结果这里显示出的前篇的链接 404 了.
这里选 Fiber 当路由其中一个原因, 就是因为它支持带冒号的路径比较方便, 只要加反斜杠就可了.