前言

平时大家写完 gRPC 接口后是如何测试的？往往有以下几个方法：

1. 写单测代码，自己模拟客户端测试。
   

2. 可以搭一个 gRPC-Gateway 服务，这样就可以在 postman 中进行模拟。

前言

前段时间有个项目即将上线，需要对其中的核心接口进行压测；由于我们的接口是 gRPC 协议，找了一圈发现压测工具并不像 HTTP 那么多。

最终发现了 ghz 这个工具，功能也非常齐全。

事后我在想为啥做 gRPC 压测的工具这么少，是有什么难点嘛？为了验证这个问题于是我准备自己写一个工具。

不知不觉写 Go 已经快一年了，上线了大大小小好几个项目；心态也经历了几轮变化。

因为我个人大概前五年时间写的是 Java ，中途写过一年多的 Python，所以刚接触到 Go 时的感觉如下图：

既没有 Java 的生态，也没有 Python 这么多语法糖。

前言

日常开发中我们大概率会遇到超时控制的场景，比如一个批量耗时任务、网络请求等；一个良好的超时控制可以有效的避免一些问题（比如 goroutine 泄露、资源不释放等）。

前言

设计模式不管是在面试还是工作中都会遇到，但我经常碰到小伙伴抱怨实际工作中自己应用设计模式的机会非常小。

正好最近工作中遇到一个用观察者模式解决问题的场景，和大家一起分享。

前言

作为一个 Go 语言新手，看到一切”诡异“的代码都会感到好奇；比如我最近看到的几个方法；伪代码如下：

1
2
3
4
5
6
7
8
9
10
11

func FindA() ([]*T,error) {
}

func FindB() ([]T,error) {
}

func SaveA(data *[]T) error {
}

func SaveB(data *[]*T) error {
}

前言

最近在实现两个需求，由于两者之间并没有依赖关系，所以想利用队列进行解耦；但在 Go 的标准库中并没有现成可用并且并发安全的数据结构；但 Go 提供了一个更加优雅的解决方案，那就是 channel。

channel 应用

Go 与 Java 的一个很大的区别就是并发模型不同，Go 采用的是 CSP(Communicating sequential processes) 模型；用 Go 官方的说法：

Do not communicate by sharing memory; instead, share memory by communicating.

前言

最近用 Python 写了几个简单的脚本来处理一些数据，因为只是简单功能所以我就直接使用 print 来打印日志。

任务运行时偶尔会出现一些异常：

背景

我们最近在做新业务的技术选型，其中涉及到了对消息中间件的选择；结合我们的实际情况希望它能满足以下几个要求：

• 友好的云原生支持：因为现在的主力语言是 Go，同时在运维上能够足够简单。
• 官方支持多种语言的 SDK：还有一些 Python、Java 相关的代码需要维护。
• 最好是有一些方便好用的特性，比如：延时消息、死信队列、多租户等。

前言

最近公司内部项目的发布流程接入了 GitHub Actions，整个体验过程还是比较美好的；本文主要目的是对于没有还接触过 GitHub Actions的新手，能够利用它快速构建自动测试及打包推送 Docker 镜像等自动化流程。