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

引言 微服务算是一个 Go 语言的主要应用场景, 与 Java 不同 Go 语言生态中并不存在一个像 Spring 那样具有绝对统治力的后端框架. 一般大家都是按照自己的业务需求, 组

引言 文中的源码在这里: https://github.com/gota33/errors 在 Part 1 中我们重新认识了什么是错误. 这次我们就以 Go 语言为例, 看看如何处理下面的问题: 如何告诉机器有没有错误? 如何告诉机

引言 错误处理一直都是开发中绕不开的坑, 而且往往一时偷懒, 摔得更惨. 所以这次打算从头梳理下这个让人头大的问题. 先简单介绍下思路, 本文开篇会讨论

引言 源码见: https://github.com/gota33/go-config-server/tree/v0.2.3 在 Part 1 中我们用少量代码实现了配置中心的最小可用版本. 其中只包含能够使流程跑通的基础功能: Git 后端存储 Jsonnet 渲染引擎 优雅退出 HTTP 接口 命令

引言 源码见 https://github.com/GotaX/go-config-server/tree/v0.1.0 只要接触过微服务的同学都知道, 配置管理不好, 运维真的压力山大. 过去呢, 我一直都首选 spring-cloud-config-server 做配置服务器, 主要是因为: 遗留了不少 Java 服务,

英文原文及项目结构示例: https://github.com/golang-standards/project-layout 这里列举的是一个 Go 项目的基础布局. 它并不是由 Go 核心开发团队定义的官方标准; 然而, 它是 Go 生态圈中新老项目常用的一组布