Junedayday Blog

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

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

概览

通过上一次技术阅读摘要，我们了解了分布式链路追踪这项技术，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数据库，打通整个链路，真正地让这个平台实现可用。

GORM库的官方文档

GORM库作为Go语言最受欢迎的ORM框架，提供了非常丰富的功能，大家可以通过阅读中文官网了解详情。

这里，先着重介绍一个背景：GORM内部会区分v1与v2两个版本，其中

• v1的包导入路径为 github.com/jinzhu/gorm
• v2的包导入路径为 gorm.io/gorm

v1与v2对使用者来说体验相差不大，今天就主要针对v2版本进行讲解。

随着GORM库的引入，我们在数据库持久化上已经有了解决方案。但上一篇我们使用的GORM过于简单，应用到实际的项目中局限性很大。

与此同时，我们也缺乏一个有效的手段来验证自己编写的相关代码。如果依靠连接到真实的MySQL去验证功能，那成本实在太高。那么，这里我们就引入一个经典的sqlmock框架，并配合对数据库相关代码的修改，来实现相关代码的可测试性。

数据持久化是服务的必要特性，最常见的组件就是关系型数据库MySQL。而在Go语言里，GORM已经成了对接MySQL事实上的标准，那么也就不去横向对比其它库了。

GORM库是一个很强大、但同时也是一个非常复杂的工具。为了支持复杂的SQL语言，它比之前的配置文件加载工具github.com/spf13/viper要复杂不少。今天，我们不会全量地引入GORM里的所有特性，而是从一个最简单的场景入手，对它的基本特性有所了解。而后续随着框架的完善，我们会逐渐细化功能。