yafeiaa Blogs

Agones SDK-Server 与 Allocator

Wed, 14 Jan 2026 00:00:00 +0000

前言

Agones 通过 SDK-Server 让 GameServer 自己管理生命周期状态。每个 GameServer 启动时会连接本地的 SDK Server，通过 gRPC API 同步状态。

在实际部署时，sdk-server 会作为一个 sidecar 容器，和 gameserver 容器共享 network namespace，所以 gmaeserver 可以直接以 localhost 访问 sdk-server 的 api。

sdk-server 作为 agones 和 gameserver 之间的状态同步器，负责将 gameserver 的状态同步给 agones，以及将 agones 的分配请求同步给 gameserver。

Allocator Service

Allocator 是 Agones 提供的 gRPC 服务，用于分配 GameServer。它监听集群中所有 Ready 状态的 GameServer，当收到分配请求时，选择一个合适的 GameServer 并将其状态改为 Allocated。

Allocator 提供了两种分配方式：

gRPC Service - 直接调用 gRPC API（适合高性能、安全性要求高的场景，通过mtls认证）
Allocation API - 通过 Kubernetes CRD GameServerAllocation（更简单，通过k8s api调用）

核心 API

Ready() - 标记就绪，可以被分配
Health() - 发送心跳，保持健康状态
Shutdown() - 通知关闭
SetAnnotation() - 设置自定义信息（如自定义的对外访问地址）
WatchGameServer() - 监听状态变化

状态流转

Port -> Ready -> Allocated -> Shutdown

Port - 刚启动，等待 Ready
Ready - 调用 Ready() 后进入，等待分配
Allocated - 被 match-maker 分配后进入，开始游戏逻辑
Shutdown - 调用 Shutdown() 或收到关闭信号后进入

一个dedicate-server和 match-maker通过 sdk-server 和 allocator 交互的例子

dedicate-server

启动流程：

Minimatch 轻量级匹配服务使用体验

Wed, 14 Jan 2026 00:00:00 +0000

前言

最近在一个项目中，了解到了minimatch这个轻量级匹配服务，并借助minimatch实现了简单的match-maker服务，进行了学习。

在游戏服务器匹配场景中，Open Match 是一个成熟的解决方案，但它的架构相对复杂，需要部署多个 Kubernetes 组件。在本地开发、或者不希望额外管理open-match的复杂性，只想实现 match 核心逻辑，minimatch 是一个很好的选择。

核心概念

1. Frontend 服务

Frontend 负责接收玩家的匹配请求，创建和管理 Ticket。每个 Ticket 包含玩家的搜索条件，如地区、等级、角色等。

// 创建 Ticket
ticket := &pb.Ticket{
    SearchFields: &pb.SearchFields{
        Tags: []string{
            fmt.Sprintf("region:%s", user.Region),
            fmt.Sprintf("role:%s", user.Role),
        },
        DoubleArgs: map[string]float64{
            "level": float64(user.Level),
        },
    },
}

2. Backend 服务

Backend 是匹配的核心，它定期（每个 tick）从 Redis 获取活跃的 Tickets，执行匹配逻辑，并将匹配结果分配给 GameServer。

Backend 包含三个关键组件：

MatchProfile：定义匹配规则，包括多个 Pool（匹配池），每个 Pool 可以设置过滤条件（如地区、等级范围）
MatchFunction：实现具体的匹配算法，根据 Pool 中的 Tickets 生成 Match
Assigner：将匹配结果分配给 GameServer

3. 匹配流程

玩家请求 → Frontend 创建 Ticket → Redis 存储
                                    ↓
Backend 定时轮询（通过提前设置的tick） → 获取 Tickets → MatchFunction 匹配 → Assigner 分配 GameServer → 更新 Ticket 状态

实践：与 Agones 集成实现一个简单的match-maker

架构设计

我们将 minimatch 的 Frontend 和 Backend 集成到同一个服务中，通过 HTTP API 对外提供服务：

protoc-gen-cloudevents-go：从 Protobuf 自动生成类型安全的事件驱动代码

Tue, 25 Nov 2025 00:00:00 +0000

前言

在微服务架构和事件驱动系统中，我们经常需要编写大量的事件发布和订阅代码。这些代码往往充斥着：

❌ 字符串魔法值：事件类型容易拼写错误
❌ 类型不安全：使用 map[string]interface{} 传递数据
❌ 重复代码：每个事件都要手写发布/订阅函数
❌ 难以维护：事件定义分散在各处，缺乏统一管理

为了解决这些问题，我开发了 protoc-gen-cloudevents-go —— 一个基于 CloudEvents 标准的 Protobuf 代码生成器。

GitHub: https://github.com/yafeiaa/protoc-gen-cloudevents-go

核心理念

单一数据源（Single Source of Truth）

使用 Protobuf 定义事件结构，自动生成类型安全的发布/订阅代码：

syntax = "proto3";
package myapp.events;

import "cloudevents/event_meta.proto";

// 用户注册事件
message UserRegisteredPayload {
  option (cloudevents.event_meta) = {
    event_type: "myapp.user.registered"
    description: "用户注册成功"
  };
  
  string user_id = 1;
  string email = 2;
  int64 registered_at = 3;
}

一条命令生成所有代码：

protoc \
  -I . \
  --go_out=. \
  --cloudevents_out=. \
  events.proto

类型安全 + 零样板代码

传统方式 vs 使用 protoc-gen-cloudevents：

Go 服务性能优化实战：从 pprof 分析到落地方案

Fri, 31 Oct 2025 00:00:00 +0000

前言

在生产环境中，Go 服务的性能问题往往不是单一原因造成的。本文基于真实的性能优化经验，通过 pprof 工具分析一个高并发 gRPC 服务的性能瓶颈，并给出具体的优化方案和代码实现。

优化成果：

CPU 使用率降低 30-50%
内存对象数降低 65-95%
P99 延迟降低 35-55%
QPS 提升 50-80%

一、性能分析的正确姿势

1.1 pprof 数据的类型

Go 的 pprof 提供了多个维度的 profile 数据：

┌─────────────────────────────────────────────────────┐
│                  pprof 数据类型                       │
├─────────────────────────────────────────────────────┤
│ CPU Profile      │ 程序运行时 CPU 占用情况            │
│ Heap (inuse)     │ 当前正在使用的内存                │
│ Heap (alloc)     │ 历史累计的内存分配                │
│ Goroutine        │ 当前 goroutine 的数量和状态       │
│ Block            │ 同步原语（锁）的阻塞情况           │
│ Mutex            │ 互斥锁的竞争情况                  │
└─────────────────────────────────────────────────────┘

关键洞察：不同的 profile 数据能揭示不同的问题

读书| 2025年想看的书

Tue, 24 Dec 2024 12:03:00 +0800

2025年想看的书

2025年，我25岁，我希望自己能读完以下这些书：

《我们生活在巨大的差距里》- 余华
《小城与不确定性的墙》 - 村上春树
《乡土中国》 - 费孝通
《团圆记》 - 杨云苏
《弃长安》 - 张明扬
《我与地坛》 - 史铁生
《草民》 - 蔡崇达

希望能够以娱乐的心态，读完这些书，给自己的生活增添一些乐趣，而不是给自己增加任务。

Golang| golang项目中对json处理的优化

Mon, 16 Dec 2024 16:36:15 +0800

本文主要介绍我在golang项目中遇到的一个json.Marshal导致的内存占用大的问题，以及解决思路和方案。

问题描述

在我的一个golang项目中，其中有一个http服务，它提供的api接口需要返回一些数Mb级别的json数据，在很长的一段时间内都能正常使用，但是随着业务的增长，发现这个服务使用的内存越来越大，从最开始的2gb规模增长到了10gb甚至更高，而且随着时间的推移，内存占用还在不断增长，最终导致服务OOM、进程被kill。

问题分析

为了解决这个问题，我首先通过监控面板对比了该服务器的几个指标：

CPU使用量
内存使用量
goroutines
向操作系统请求的内存量

在某个内存增长的点，这些指标的值变化如下图：

可以在图上看到，内存使用量增长的时候，cpu使用量在增长、向操作系统请求的内存量也在增长。但是goroutines没有明显变化。

这里可以排除是goroutines泄漏导致的问题，因为goroutines数量一直都比较平稳。

排除了goroutines泄漏的问题之后，这里我们猜测是正常的服务器行为导致的内存使用量增多。

然后，我通过golang的pprof endpoint中暴露出的数据，对内存使用量增长的原因进行了分析。在golang的pprof中暴露了几个关于内存的数据：

inuse_space — 已分配但尚未释放的内存空间
inuse_objects——已分配但尚未释放的对象数量
alloc_space — 分配的内存总量(已释放的也会统计)
alloc_objects — 分配的对象总数(无论是否释放)

这里我们重点对inuse_space进行分析：

Inuse_space

在图中，可以明显看到，约89%的内存都来自于json.Marshal函数，json.Marshal在这个服务中充当的作用就是对一些大对象进行序列化，返回给客户端。

所以，这里可以确认，内存使用量增长的原因就是json.Marshal函数导致的。

解决方案

既然问题已经确认，那么接下来就是想办法解决这个问题。

通过对json.Marshal函数的源码进行分析，发现它使用的是反射机制，对结构体进行遍历，然后对每个字段进行序列化，最终将序列化后的结果拼接成一个字符串返回。

众所周知，golang是静态编译型语言，为了在运行时提高灵活性，我们有些时候不得不使用反射机制，但是golang的反射机制性能较差（具体见参考资料）。所以会导致json.Marshal函数在序列化大对象的时候，性能较差。

在社区中，有很多对标准库encoding/json的优化方案，比如：

字节跳动开源的sonic：https://github.com/bytedance/sonic
滴滴开源的json-iterator：https://github.com/json-iterator/go
jsonparser：https://github.com/buger/jsonparser

其中，json-interator完全兼容encoding/json接口，便于直接替换标准库，而sonic和jsonparser则没有兼容encoding/json，需要修改代码。

所以，基于兼容性考虑，我选择了json-iterator。

1、安装json-iterator

go get github.com/json-iterator/go

2、导入json-iterator并替换encoding/json

import (
    // "encoding/json"
    "github.com/json-iterator/go"
)
// 替换encoding/json
var json = jsoniter.ConfigCompatibleWithStandardLibrary

优化效果

在经过调整之后，再次观察在相同qps下，inuse_space的分布：

从图上可以看到，json.Marshal函数造成的大量占用已经消失。

从grafana的内存使用量上也可以看到内存使用量也降到了原来的1/3左右。

参考资料

gRPC的负载均衡和服务发现

Fri, 27 Sep 2024 14:22:00 +0800

在分布式系统中，gRPC凭借其高性能和高效的通信方式，近年来越来越受欢迎，被广泛应用于微服务架构和客户端/服务器（C/S）之间的通信协议中。本文将分享我在使用gRPC过程中关于负载均衡和服务发现的一些实践经验、思考以及遇到的问题，并通过grpc-go的示例代码，深入探讨客户端负载均衡的实现。

为什么选择gRPC？

gRPC基于HTTP/2协议，支持多路复用、流控、头部压缩等特性，使其在性能和效率上优于传统的HTTP/1.x协议。此外，gRPC支持多种语言，方便跨语言服务间的通信，对于微服务架构的扩展性和灵活性提供了极大的支持。

负载均衡的必要性

在微服务架构中，一个服务通常有多个实例以应对高并发和高可用的需求。负载均衡负责将客户端的请求合理分配到各个服务实例上，以实现资源的有效利用和系统的高可用性。gRPC支持多种负载均衡策略，包括客户端负载均衡和服务端负载均衡。

客户端负载均衡在gRPC中的实现

在gRPC中，负载均衡可以在客户端实现，这样客户端能够直接感知到多个服务实例，并根据一定的策略进行请求分发。以下是使用grpc-go实现客户端负载均衡的示例。

示例：使用Round Robin策略实现客户端负载均衡

安装依赖首先，确保已安装grpc-go。可以通过以下命令安装：

go get google.golang.org/grpc bash 2. 自定义解析器和负载均衡器 gRPC需要自定义服务发现和负载均衡策略，这里以Round Robin为例进行实现。

package main

import (
    "context"
    "fmt"
    "log"
    "sync/atomic"
    "time"

    "google.golang.org/grpc"
    "google.golang.org/grpc/resolver"
    "google.golang.org/grpc/balancer"
    "google.golang.org/grpc/balancer/base"
)

// 定义服务地址
const (
    scheme = "custom"
    serviceName = "myService"
)

// 解析器实现
type customResolver struct {
    target resolver.Target
    cc     resolver.ClientConn
    addrs  []resolver.Address
}

func (r *customResolver) Start() {
    r.addrs = []resolver.Address{
        {Addr: "localhost:50051"},
        {Addr: "localhost:50052"},
        {Addr: "localhost:50053"},
    }
    r.cc.UpdateState(resolver.State{Addresses: r.addrs})
}

func (r *customResolver) ResolveNow(o resolver.ResolveNowOptions) {}
func (r *customResolver) Close() {}

func newCustomResolver(target resolver.Target, cc resolver.ClientConn, opts resolver.BuildOptions) resolver.Resolver {
    cr := &customResolver{
        target: target,
        cc:     cc,
    }
    cr.Start()
    return cr
}

// 注册解析器
func init() {
    resolver.Register(&resolver.Builder{
        Scheme: scheme,
        Build:  newCustomResolver,
        // Deprecated: we use a separate build function
    })
}

// 简单的Round Robin负载均衡器
type roundRobinBalancer struct {
    current uint64
}

func (b *roundRobinBalancer) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
    next := atomic.AddUint64(&b.current, 1)
    addr := info.CC().GetAddresses()[next%uint64(len(info.CC().GetAddresses()))]
    return balancer.PickResult{SubConn: addr.SubConn, Done: func(info balancer.DoneInfo) {}}, nil
}

func newRoundRobinBuilder() balancer.Builder {
    return base.NewBalancerBuilder("round_robin", &roundRobinBalancer{}, base.Config{})
}

func main() {
    // 注册负载均衡器
    balancer.Register(newRoundRobinBuilder())

    // 创建连接
    conn, err := grpc.Dial(
        fmt.Sprintf("%s:///%s", scheme, serviceName),
        grpc.WithInsecure(),
        grpc.WithBalancerName("round_robin"),
    )
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()

    // 创建gRPC客户端
    client := NewMyServiceClient(conn)

    // 发起请求
    for {
        resp, err := client.MyMethod(context.Background(), &MyRequest{})
        if err != nil {
            log.Printf("Error calling MyMethod: %v", err)
        } else {
            log.Printf("Response: %v", resp)
        }
        time.Sleep(1 * time.Second)
    }
}

代码解析自定义解析器 (customResolver)：实现了resolver.Resolver接口，模拟服务发现过程。在实际应用中，可以从服务注册中心（如etcd、Consul）动态获取服务实例列表。

注册解析器：使用resolver.Register注册自定义解析器，指定Scheme为custom。

Golang| golang中为什么resp.body要关闭

Sat, 10 Sep 2022 11:20:00 +0800

本文介绍在golang的标准库net/http中，为什么请求之后，要主动关闭resp.body、以及不关闭resp.body有什么影响。

问题描述

在golang中，我们使用http标准库发起一个http请求，一般会使用如下的方式：

resp, err := http.Get("http://www.baidu.com")
if err != nil {
    log.Fatal(err)
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if err != nil {
    log.Fatal(err)
}
fmt.Println(string(body))

在上面的代码中，我们使用http.Get发起一个http请求，然后使用ioutil.ReadAll读取resp.Body的内容，最后关闭resp.Body。

在学习其他编程语言，如python，我们一般不需要进行类似的操作，这是为什么呢？

问题分析

阅读源码

要回答这个问题，我们首先要知道net/http包在做请求的时候，背后都做了哪些事情，所以要阅读net/http包的源码。

getConn：获取一个连接，或者重新创建连接

queueForDial: 把连接创建请求（后文简称w，一个经过初始化的wantConn结构体）放入到dialer的队列中等待被使用

一旦满足以下两种条件：

没有限制MaxConnsPerHost
还没有达到MaxConnsPerHost

就会通过dialConnFor函数为w创建一个真正的往目标地址的连接，dialConnFor函数创建连接调用了dialConn函数。

而dialConn函数是最关键的，在dialConn函数的最后，拉起了两个goroutine：

readloop
writeloop

我们这里分析下这两个goroutine的作用以及退出条件。

readloop

通过调用pc.readResponse函数接收response。

我们省略掉一些不重要的代码，只看关键的部分： readloop内部有一个for循环，循环的退出条件是：alive == false，而alive赋值为false的时机是：

resp.Close为true
rc.req.Close为true
resp.StatusCode == 199（https://http.dev/199）
bodyWritable为true

其他三点我们先忽略，重点关注resp.Close条件。这就是问题的答案，如果不执行resp.Body.Close，那么resp.Close永远为false，所以readloop永远不会退出，就会在程序生命周期中永远保留一个goroutine和文件句柄。

writeloop

writeloop的作用是往目标地址写入请求数据，并且进行一些写入的错误处理。

它内部是一个阻塞式的for-select控制结构，退出的条件是：

pc.closech能够读到数据
写入数据时出错

所以，如果我们在使用http.Get发起请求时，没有执行resp.Body.Close，那么readloop和writeloop就会一直保留，直到程序退出。

问题总结

在net/http包中，如果我们在发起请求时没有执行resp.Body.Close，那么就会导致readloop和writeloop这两个goroutine一直保留，直到程序退出。所以，为了防止goroutine泄露，我们需要在发起请求后，及时执行resp.Body.Close。

参考资料

golang源代码

Python| Drf常用view解析

Wed, 01 Dec 2021 12:11:15 +0800

1 APIView

drf提供了一个继承自View类的APIView类，它比View多了一些好用的方法。

由APIView来对请求对象进行再次封装，将django的HttpRequest变为drf的Request
返回Response而不是HttpResponse
捕获所有的APIException并进行响应
传入的请求通过APIView来进行认证、权限验证等操作

1.1 APIView的AOP

APIView保持了View的特性，dispatch方法在APIView里也存在，它按照不同的请求方法将请求分发至某个函数来处理。

继承自APIView的视图可以设置很多AOP(类属性)来进行认证、权限、频率、渲染等控制。

.render_classes：设置渲染器
.parser_classes：设置解析器
.authentication_classes：设置认证器
.throttle_classes：设置频率控制器
.permission_classes：设置权限控制器

1.2 策略方法

APIView也提供了一些策略方法：

.get_renderers(self)
.get_parsers(self)
.get_authenticators(self)
.get_throttles(self)
.get_permissions(self)
.get_content_negotiator(self)
.get_exception_handler(self)

这些策略方法会返回解析器、渲染器、频率控制器、权限控制器这些AOP的可调用对象列表：

def get_renderers(self):
        """
        Instantiates and returns the list of renderers that this view can use.
        """
        return [renderer() for renderer in self.renderer_classes]

    def get_parsers(self):
        """
        Instantiates and returns the list of parsers that this view can use.
        """
        return [parser() for parser in self.parser_classes]

    def get_authenticators(self):
        """
        Instantiates and returns the list of authenticators that this view can use.
        """
        return [auth() for auth in self.authentication_classes]

    def get_permissions(self):
        """
        Instantiates and returns the list of permissions that this view requires.
        """
        return [permission() for permission in self.permission_classes]

    def get_throttles(self):
        """
        Instantiates and returns the list of throttles that this view uses.
        """
        return [throttle() for throttle in self.throttle_classes]

1.3 控制策略实现

APIView如何实现权限、频率控制呢?在APIView内部实现了一些方法，在request分派到具体的处理方法（get、post）之前，它会自动调用一些策略进行验证：

读书｜vue.js快跑

Mon, 05 Jul 2021 20:14:45 +0800

vue.js，一个渐进式JavaScript框架，借助其优秀的响应式设计，提供了简单的数据状态到视图状态的双向映射。从原生js到jqury，react····，框架设计者们都在探索视图和数据之间的松耦合，以至于可以直接通过改变数据来改变视图。vue是在众多探索者中的一个把view和state之间的关系处理的恰到好处的渐进式框架。

为什么说它是渐进式呢？

其实vue的核心功能就是前面说到的：提供一个简单的数据状态到视图状态到双向映射，它更像是一个视图引擎，帮助开发者消除数据与视图之间的高耦合。在vue官网中，把这个功能称为——“声明式渲染”。

在vue生态中，我们可以通过添加组件系统，客户端路由，大规模状态管理，构建工具来让vue从一个“声明式渲染”引擎变为一个真正意义上的客户端开发框架，所以vue是“渐进式”的js框架（至少我是这么认为的，如果你有不同看法，洗耳恭听😄）。

这篇文章笔者准备围绕vue的核心功能——声明式渲染来介绍vue的入门级单文件用法，后面再结合组件系统，vuex，vue-router，webpack/vite等来介绍vue等工程化用法。

感受声明式渲染

我们前面提到，vue的核心就是它的声明式渲染，帮我们做好数据状态到视图状态的双向映射。

在《vue.js快跑》一书中，用模版、指令、数据解释了vue的组成部分，通过这些组成部分可以实现vue的声明式渲染（这里我们暂且不讨论原理）：

为正常的HTML添加特殊的属性——被称作指令——借助它来告诉vue我们想要实现的效果以及如何处理提供给它的数据。

<div id="app">
  <button v-on:click="change_show">点我一下我就让你好看</button>
  <span v-show="show_word">好看</span>
</div>
<script>
  new Vue({
    el: '#app',
    data: {
      show_word: false 
    },
    methods: {
      change_show:function(){
        this.show_word = !this.show_word;
      }
    }
  })
</script>

在上面的代码模型中。点击“点我一下我就让你好看”之后在页面上就会出现“好看”，在这个过程中，vue帮助我们实现了一个完整的交互和状态响应。

如果要使用原生js来实现上面的功能，我们需要考虑每一个实现细节：

1、捕获点击动作

2、更改状态变量值

3、根据改变后的状态变量值来渲染页面

而在vue中，我们只需要把一个数据和一个改变数据的方法声明在script中，并且通过vue的指令将两者建立联系，就可以实现”声明一个数据，通过改变数据改变状态”，我们不需要再关注其他的东西，因为这些vue已经帮助我们做好了。

v-if vs v-show

在前面的例子中我们已经了解到vue的声明式渲染大概是一个什么样子的，丰富的vue指令让我们可以更好的让数据和视图进行绑定。我们在前面的“点我一下就让你好看”的例子中使用了v-show这个指令，v-show指令是通过判断一个表达式或者变量的值是否为真来决定模版的渲染逻辑，它的作用有点像if语句。但实际上vue中也有专门的v-if用来控制条件渲染。

首先看看这两个指令的作用：

1、v-if：如果v-if指令的值为假，那么在渲染dom时，当前的元素就不会被插入dom

2、v-show：如果v-show的值为假，那么在显示dom的时候，这个元素不会被显示，它是css级别的控制

<div v-if="true">
  😄
</div>
<div v-if="false">
  👖
</div>

上面的代码会被浏览器解析成这样的：

<div>
  😄
</div>

从这里就可以看到，v-if指令的值为false的元素并不会被加入最终的html中。

<div v-show="true">
  😁
</div>
<div v-show="false">
  👌
</div>

浏览器解析这一段代码之后，它会产生这样的效果：

<div>
  😁
</div>
<div style="display:none;">
  👌
</div>

v-show指令的值不管是不是真，这个元素最终都会被加入最终的html中。

值得纪念的时刻

Mon, 01 Jan 0001 00:00:00 +0000