本文基于 apps-scheduler 和 cat-led 两个实际项目，介绍懒猫微服 Go-SDK 的使用方法。
SDK 简介 懒猫微服 Go-SDK（gitee.com/linakesi/lzc-sdk）是懒猫微服平台提供的 Go 语言 SDK，允许应用通过 gRPC 与懒猫微服系统交互。SDK 封装了以下核心能力：
应用管理（PkgManager）：查询、启动、暂停应用 用户管理（Users）：查询用户信息 设备管理（Box）：查询设备信息、控制 LED、关机/重启 项目结构 使用 Go-SDK 开发的懒猫应用推荐采用如下项目结构：
your-app/ ├── cmd/ │ └── your-app/ │ └── main.go # 应用入口 ├── internal/ │ ├── web/ │ │ └── server.go # Web 服务器配置与路由 │ ├── handlers/ │ │ ├── app.go # SDK 调用相关 handler │ │ └── userinfo.go # 用户信息 handler │ ├── biz/ │ │ └── usecase....
我搭建的一个kratos项目模板，欢迎使用，仓库地址
需要特别注意的一些建议 API路由覆盖的问题 比如有两个接口 A get /v1/user/{user_id}和 B get /v1/user/profile如果A定义在B之前，那么B可能会被A覆盖路由。需要将A放到B之前。
JWT使用的建议 摘自极客时间课程《高并发系统实战课》
通讯过程必须使用 HTTPS 协议，这样才可以降低被拦截的可能。 要注意限制 token 的更换次数，并定期刷新 token，比如用户的 access_token 每天只能更换 50 次，超过了就要求用户重新登陆，同时 token 每隔 15 分钟更换一次。这样可以降低 token 被盗取后给用户带来的影响。 Web 用户的 token 保存在 cookie 中时，建议加上 httponly、SameSite=Strict 限制，以防止 cookie 被一些特殊脚本偷走。 配置文件 配置文件校验 配合buf的validate可以方便地进行配置文件的校验，在程序启动之前就对配置文件进行一次校验。下面是一个简单的proto配置定义
syntax = "proto3"; package conf; import "buf/validate/validate.proto"; import "google/protobuf/duration.proto"; option go_package = "github.com/tpl-x/kratos/internal/conf;conf"; message Bootstrap { Server server = 1; Data data = 2; Log log = 3; } message Server { message HTTP { string network = 1; string addr = 2; google....
从零开始，手把手带你构建 P2P 网络应用,本文由claude code编写
1. 核心概念扫盲 在写代码之前，先花 5 分钟理解几个关键词。这些概念会贯穿整个教程。
PeerID —— 节点的"身份证" 每个 libp2p 节点在启动时都会生成（或加载）一对密钥（默认是 Ed25519）。PeerID 就是公钥的哈希值，是全网唯一的节点标识。
QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N Multiaddr —— 节点的"地址簿" 传统 TCP 地址长这样：192.168.1.1:4001。libp2p 的多地址（Multiaddr）更丰富，包含了协议栈信息：
/ip4/192.168.1.1/tcp/4001/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N └─────────────┘ └────────┘ └─────────────────────────────────────────────────────┘ IP 地址 TCP 端口 PeerID 也可以是：
/ip4/0.0.0.0/tcp/0 —— 随机端口的 TCP /ip4/0.0.0.0/udp/0/quic-v1 —— QUIC 协议 /dns4/example.com/tcp/443/wss —— WebSocket over TLS Host —— 你的节点实例 host.Host 是 libp2p 的核心对象，可以理解为"这台机器在 P2P 网络中的代理"。所有操作都从它出发：监听连接、发起连接、注册协议处理器等。
Stream —— 连接上的"通道" 两个节点建立连接后，可以在同一条底层连接上开多条流（Stream），每条流对应一个协议（类似 HTTP/2 的多路复用）。
Protocol ID —— 协议的"频道号" 每条流都有一个协议 ID，是一个字符串，用于标识通信双方在"聊什么话题"：...
（本文内容基于 Bun ORM 官方文档 翻译整理）
1. 简介：什么是 Bun ORM？ Bun 是一个 SQL 优先的 Go 语言 ORM（对象关系映射）框架，支持 PostgreSQL、MySQL、MSSQL 和 SQLite。它旨在提供一种简单高效的方式来操作数据库，同时利用 Go 的类型安全特性并减少样板代码。
核心特性 基于标准库构建：构建在 Go 标准 database/sql 包之上 类型安全：提供类型安全的查询构建器，性能卓越 复杂关系支持：支持复杂的关系和连接操作 迁移支持：提供迁移和架构管理功能 强大的扫描能力：全面的数据扫描功能 钩子和中间件：支持钩子和中间件 生产就绪：经过广泛测试，可用于生产环境 为什么选择 Bun？ Bun 通过 SQL 优先 的理念区别于其他 Go ORM，不试图对开发者隐藏 SQL。这种方法具有以下优势：
可预测的查询：你确切知道生成的 SQL 是什么 高性能：对原始 SQL 的开销最小 渐进式采用：易于集成到现有代码库 灵活性：需要时可降级到原始 SQL 类型安全：大多数操作的编译时检查 2. 安装与配置 安装 Bun 要安装 Bun 和所需的数据库驱动：
# 核心 Bun 包 go get github.com/uptrace/bun@latest # 数据库驱动（选择一个或多个） go get github....
Hertz的优缺点 优点 中文社区维护 稳定，字节产品，有相关的开源项目参考，比如coze和coze studio hz的模板支持，使得代码生成更加灵活 缺点 工程体验上，不如go-kratos等项目。比如不能很好得支持buf等第三方生态。代码生成的使用场景，如多service模式下体验不好。 Template 模板 之所以将模板放在第一，是因为Hertz里面模板是过不去的坎。😄官方的一个mvc的template 或者 cwgo内置的模板
自动生成路由注册 新建一个template/package.yaml
layouts: # 覆盖默认 router.go 模板 # 关键：将 Register 函数名改为包含服务名的唯一名称 - path: router.go delims: ['{{', '}}'] body: |- // Code generated by hertz generator. DO NOT EDIT. package {{$.PackageName}} import ( "github.com/cloudwego/hertz/pkg/app/server" {{- range $k, $v := .HandlerPackages}} {{$k}} "{{$v}}" {{- end}} ) /* This file will register all the routes of the services in the master idl....
原文链接 https://destel.dev/blog/preserving-order-in-concurrent-go
并发是 Go 语言的一大优势，但它带来一个根本性的权衡：当多个 goroutine 同时处理数据时，自然顺序会被打乱。大多数情况下，这并无大碍——无序处理已足够，且更快速、更简单。
但有时，顺序至关重要。
当顺序至关重要 以下是三个需要保持顺序至关重要的实际场景：
实时日志增强 ：您正在处理高流量的日志流，通过数据库或外部 API 为每个条目添加用户元数据。顺序处理无法跟上输入速率，但并发处理会打乱顺序，使得增强后的日志对依赖时间顺序的下游消费者变得不可用。
在文件列表中查找首个匹配项 ：您需要从云存储下载文件列表，并找到包含特定字符串的第一个文件。并发下载速度更快，但完成顺序是乱序的——第 50 个文件可能比第 5 个文件先完成，因此您不能简单地返回找到的第一个匹配项，因为无法确定更早的文件是否也包含该字符串。
时间序列数据处理 ：这个场景激发了我的原始实现。我需要下载 90 天的交易日志（每个约 600MB），提取部分数据，然后比较连续日期的数据以进行趋势分析。顺序下载需要数小时；并发下载可实现数量级的速度提升，但会破坏我进行比较所需的时间关联性。
挑战很明确：我们需要在不牺牲结果顺序可预测性的前提下获得并发处理的速度优势。这不仅是理论问题——更是影响实际大规模系统的现实约束。
本文将探讨我在生产级 Go 应用中开发并采用的三种方法。我们将构建一个并发的 OrderedMap 函数，它能在保持顺序的同时将输入通道转换为输出通道，并支持具有背压机制的无限流处理。通过对每种方法进行基准测试，我们将理解其权衡取舍，并在此过程中发现令人惊讶的性能洞见。
问题：为何并发会破坏顺序 让我们快速回顾一下为什么并发会打乱顺序。原因之一是各个 goroutine 处理任务的速度不同。另一个常见原因——我们无法预测 Go 运行时如何精确调度 goroutine。
例如，goroutine #2 可能在 goroutine #1 完成第 10 项之前就处理完了第 50 项，导致结果顺序错乱。这是并发处理的自然行为。
若想查看实际效果，这里有一个在 Go Playground 上的快速演示 。
设计理念：背压与缓冲的权衡 传统的顺序并发方法采用某种重排序缓冲区或队列。当工作线程计算出结果但尚不能写入输出时，该结果会被暂存于缓冲区中，直至能够按正确顺序写入。
在这种设计中，缓冲区通常可以无限制地增长。这种情况发生在：
输入存在倾斜 – 早期项目的处理时间比后续项目更长 下游消费者处理速度较慢 另一种常见方法是将所有结果暂存于内存中（切片/映射等）再进行排序。但我们今天的目标是构建一个流式解决方案，它能够：
最小化延迟 – 结果一旦准备就绪立即输出 处理无限输入流 – 支持任意大甚至无限的输入（例如从标准输入或网络流读取） 保持内存受限 – 避免不必要地在内存中累积结果 话虽如此，下面介绍的算法是背压优先的。如果工作协程还无法将结果写入输出通道，它就会阻塞。这种设计受内存限制，并保持了开发者对 Go 通道行为的预期。...
需要下载相关的模型 https://github.com/Kagami/go-face-testdata 下面的models
代码实现 代码如下
package main import ( "encoding/base64" "encoding/json" "errors" "fmt" "io" "log" "math" "net/http" "os" "path/filepath" "strconv" "sync" "time" "unsafe" "github.com/Kagami/go-face" "github.com/gorilla/mux" ) // Config 配置结构 type Config struct { Port string `json:"port"` ModelsDir string `json:"models_dir"` UploadsDir string `json:"uploads_dir"` TempDir string `json:"temp_dir"` DataFile string `json:"data_file"` MaxFileSize int64 `json:"max_file_size"` DefaultThreshold float32 `json:"default_threshold"` LogLevel string `json:"log_level"` } // Person 人员结构（支持多样本） type Person struct { ID int `json:"id"` Name string `json:"name"` Samples []FaceSample `json:"samples"` Created time....
Tailscale中有很多实用的代码，下面是EWMA的一个实现，源码
// Copyright (c) Tailscale Inc & AUTHORS // SPDX-License-Identifier: BSD-3-Clause // Package maths contains additional mathematical functions or structures not // found in the standard library. package maths import ( "math" "time" ) // EWMA is an exponentially weighted moving average supporting updates at // irregular intervals with at most nanosecond resolution. // The zero value will compute a half-life of 1 second. // It is not safe for concurrent use....
在netbird中看到一个semaphore-group函数
package semaphoregroup import ( "context" "sync" ) // SemaphoreGroup is a custom type that combines sync.WaitGroup and a semaphore. type SemaphoreGroup struct { waitGroup sync.WaitGroup semaphore chan struct{} } // NewSemaphoreGroup creates a new SemaphoreGroup with the specified semaphore limit. func NewSemaphoreGroup(limit int) *SemaphoreGroup { return &SemaphoreGroup{ semaphore: make(chan struct{}, limit), } } // Add increments the internal WaitGroup counter and acquires a semaphore slot. func (sg *SemaphoreGroup) Add(ctx context....
原文链接 https://atlasgo.io/blog/2025/05/26/gophercon-scalable-multi-tenant-apps-in-go
为 GopherCon Israel 2025 准备并呈现。
引言 在本篇博客中，我们将基于我们在构建 Atlas Cloud 后端（作为我们商业产品的一部分）的经验，探讨在 Go 中构建可扩展多租户应用程序的不同策略。
但首先，让我们明确一下我们所说的多租户应用是什么。
多租户是一个系统的特性，即单个实例为多个客户（租户）提供服务。
作为一家商业企业，你的目标当然是有很多客户！但你想要服务许多客户，他们期望有一个流畅无缝的体验，就好像只有他们在使用你的服务一样。
你向客户隐含做出的两个重要承诺是：
数据隔离：每个租户的数据都是隔离和安全的，确保一个租户无法访问另一个租户的数据。 性能：无论租户数量如何，应用程序都应表现良好，确保一个租户的使用不会降低其他租户的体验。 让我们探讨一些可能实现这些承诺的方法。
物理隔离 确保数据和性能隔离最直接的方法是为每个租户运行一个独立的应用实例。这种方法通常被称为“物理隔离”或“专用实例”。
为每个租户运行独立实例，可以确保：
每个租户的数据存储在独立的数据库中，从而保证完全隔离。如有需要，租户可以在不同的 VPC 中运行，甚至可以在不同的云账户中运行。 租户独立消费资源，因此一个租户的使用不会影响其他租户，从而消除了“吵闹邻居”问题。 然而，大多数公司不会选择这条路，原因有几点：
运营开销：将应用程序部署到数百或数千个生产环境，每个环境都有自己的数据库和配置，管理起来可能非常复杂。 成本：如果您的公司需要为每个租户的资源支付云服务提供商的费用，成本可能会迅速变得难以承受。 可扩展性：如果添加新租户需要部署新实例，那么扩展应用程序以支持许多租户可能会成为瓶颈。 可见性：跨多个实例监控和调试问题可能具有挑战性，因为您需要从所有实例中聚合日志和指标。 逻辑隔离 另一种方法是运行单个应用程序实例来服务多个租户，通常称为“逻辑隔离”。在此模型中，租户共享相同的应用程序代码和数据库，但它们的数据在逻辑上是隔离的。逻辑隔离可以总结为：
共享基础设施，作用域请求
让我们看看在 Go 应用程序中实际如何使用这个示例，从一个简单的 GORM 示例开始：
package main type Tenant struct { ID uint `gorm:"primaryKey" json:"id"` Name string `json:"name"` } type Customer struct { ID uint `gorm:"primaryKey" json:"id"` Name string `json:"name"` TenantID uint `json:"tenant_id"` } 在这个示例中，我们有两个模型： Tenant 和 Customer 。每个 Customer 属于一个 Tenant ， Customer 模型中的 TenantID 字段用于将每个客户与特定的租户关联起来。...