Go on 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 数据能揭示不同的问题