Junedayday Blog

随着接口参数校验功能的完善，我们能快速定位到接口层面的参数问题；而应用服务的分层代码，也可以通过log的trace-id发现常见的业务逻辑问题。

但在最底层与数据库的操作，也就是对GORM的使用，经常会因为我们不了解ORM的一些细节，导致对数据的CRUD失败，或者没有达到预期效果。这时，我们希望能在ORM这一层，也有一个通用的解决方案，来协助问题的排查。趁这个机会，我们也对gormer这个工具再做一次迭代，生成新的功能。

随着API在线文档的发布，服务的接口将会被开放给各种各样的调用方。

大量开发接口的朋友会经常遇到接口参数校验的问题。举个例子，我们希望将某个字段是必填的，如name，我们经常会需要做两步：

1. 在程序中加一个判断逻辑，当这个字段为空时返回错误给调用方
2. 在接口文档中加上注释，告诉调用方这个参数必填

一旦某项工作被拆分为两步，就很容易出现不一致性：对应到参数检查，我们会经常遇到文档和具体实现不一致，从而导致双方研发的沟通成本增加。那么，今天我将引入一个方案，实现两者的一致性。

为了缩小讨论范围，我们将 参数校验 限定为简单规则。

而复合条件的检查（逻辑组合等），不在本次的讨论范围内，主要考虑到2点：

1. 要生成跨语言的方案，技术上比较难实现
2. 复合条件往往是一种业务逻辑的检查，放在接口层面不合适

随着项目的迭代，一个服务会开放出越来越多的接口供第三方调用。

虽然protobuf已经是通用性很广的IDL文件了，但对于未接触过这块的程序员来说，还是有很大的学习成本。在综合可读性和维护性之后，我个人比较倾向于使用oepnapiv2的方案，提供在线接口文档。

接下来，我们一起来看看这部分的实现。

我们从API层到数据库层的链路已经打通，简单的CRUD功能已经可以快速实现。

随着模块的增加，我们会越发感受到系统的复杂性，开始关注系统的可维护性。这时，有个名词会进入我们的视野：分布式链路追踪。相关的内容可以参考这我的两篇文章：

• OpenTelemetry https://junedayday.github.io/2021/10/14/readings/go-digest-2/
• Jaeger https://junedayday.github.io/2021/10/20/readings/go-digest-3/

我们接下来直接进入实战。

概览

通过上一次技术阅读摘要，我们了解了分布式链路追踪这项技术，Jaeger是其主流的实现方案。

今天，我们就一起来看看Jaeger的相关资料，初步掌握这门技术。

概览

本系列的第二讲，我原先计划聊一下OpenTracing这个技术，但计划赶不上变化，我发现OpenTracing的官网上已经声明:这部分的技术将迁移到OpenTelemetry。

从OpenTelemetry的官方定义来看： An observability framework for cloud-native software，它的重点在于两块：

1. 可观察性：通过metrics、logs和traces数据，观察软件的运行情况
2. 云原生：适配云原生理念

OpenTelemetry的图标采用了一个望远镜，可见其核心在于可观察性。

概览

十二要素应用原则（The Twelve-Factor App） 在如今的微服务领域非常流行，相信大家或多或少有所耳闻，但了解其中细节的并不多。

今天，我将对这12个原则做一个概要分析，结合Go语言中的相关例子，根据开源与大厂的具体实践，和大家一起看看个中究竟。

在上一篇，我们写一个gormer工具库，支持了简单的CRUD。但是，在实际的开发场景中，这部分的功能仍显得非常单薄。

例如，我们对比一下GORM库提供的gorm.Model，它在新增、修改时，会自动修改对应的时间，这个可以帮我们减少很多重复性的代码编写。这里，我就针对现有的gormer工具做一个示例性的迭代。

CRUD是贯穿整个程序员日常开发的基本工作，占据了我们绝大多数的coding时间。

作为一名程序员，我们总是希望能有更简单的开发方式来解决重复性的工作问题。在这个小版本中，我将结合自己的工作，来给出一套自动生成代码的完整方案，供大家借鉴。

随着RPC与MySQL的打通，整个框架已经开始打通了数据的出入口。

接下来，我们就尝试着实现通过RPC请求操作MySQL数据库，打通整个链路，真正地让这个平台实现可用。