Grafana 能做什么？#

1
CPU使用率
2
│
3
│      ╱╲
4
│    ╱╱  ╲
5
│  ╱╱     ╲
6
└───────────── 时间

Grafana 的数据来源#

Grafana 本身不存储监控数据，它负责展示数据。

常见搭配：

Grafana + Prometheus 是最经典组合#

架构通常如下：

1
服务器
2
   │
3
Node Exporter
4
   │
5
Prometheus
6
   │
7
Grafana
8
   │
9
Dashboard

工作流程：

1. Node Exporter 收集服务器指标
2. Prometheus 定时拉取指标
3. Grafana 从 Prometheus 查询数据
4. Grafana 展示监控图表

一个典型场景#

比如你有一个 Java 网站：

1
用户访问网站
2
       │
3
Spring Boot
4
       │
5
Prometheus
6
       │
7
Grafana

Grafana 可以实时展示：

• QPS（每秒请求数）
• 接口响应时间
• 错误率
• JVM 内存
• GC 次数
• 数据库连接数

为什么 Grafana 这么流行？#

优点：

• 免费开源
• 界面美观
• 支持大量数据源
• Dashboard 丰富
• Kubernetes/云原生生态事实标准
• 插件生态完善

很多公司会使用：

• Grafana + Prometheus（监控）
• Grafana + Loki（日志）
• Grafana + Tempo（链路追踪）

形成完整的可观测性（Observability）平台。

一句话理解#

Prometheus 负责“采集和存储监控数据”，Grafana 负责“把数据画成好看的图表并进行告警”。

如果你是在学习 DevOps、运维、云原生或 Kubernetes，那么 Grafana 几乎是必学工具。

HTTP 场景#

标准做法是放在请求头里，通常是 W3C Trace Context：

• traceparent
• tracestate
• 可选 baggage

流程是：

1. 服务 A 收到请求，创建或继续一个 trace
2. 服务 A 调服务 B 前，把当前 trace context 注入到 HTTP header
3. 服务 B 收到请求后，从 header 提取 trace context
4. 服务 B 基于这个 context 创建自己的 span

这样 A 和 B 的 span 就会落到同一个 trace 里。

所以一般不需要你在接口 JSON 里专门加：

1
{
2
  "traceId": "..."
3
}

除非你有业务上的特殊需求。对 tracing 本身来说，不该这么做，原因是：

• 污染业务接口契约
• 容易和真实 OTel 上下文不一致
• 标准库/中间件已经能自动处理 header

HTTP 里通常像这样：

• 服务端：Extract（从入站 header 恢复上下文）
• 客户端：Inject（把上下文写入出站 header）

Go + OpenTelemetry 的服务端提取示例：

1
// 服务端：从入站请求 header 中提取上下文，再基于它创建 span
2
ctx := otel.GetTextMapPropagator().Extract(
3
  r.Context(),
4
  propagation.HeaderCarrier(r.Header),
5
)
6
ctx, span := tracer.Start(ctx, "handle-request")
7
defer span.End()

客户端注入示例：

1
// 客户端：把当前上下文注入到出站请求 header
2
req := httptest.NewRequest("GET", "http://service-b/api", nil)
3
otel.GetTextMapPropagator().Inject(
4
  ctx,
5
  propagation.HeaderCarrier(req.Header),
6
)

gRPC 与消息队列#

gRPC 也是一样，只是不是 HTTP header，而是 gRPC metadata。原理完全相同：

• client interceptor 注入
• server interceptor 提取

消息队列也类似，通常放在消息 header / metadata 里，不放消息 body。

实务建议#

• HTTP：用 traceparent 这些标准 header
• gRPC：用 metadata
• MQ/Kafka：用 message headers
• 不要把 trace id 做成业务接口字段，除非只是为了调试展示
• 可以额外返回一个 X-Trace-ID 给前端或调用方排查问题，但这只是便于观察，不是主链路传播的标准方式

相关概念见 OpenTelemetry 与链路追踪笔记。

转发 Pod#

把某个 Pod 的 8080 转到本机 18080：

1
kubectl port-forward pod/<pod-name> 18080:8080

如果 Pod 在指定 namespace：

1
kubectl -n <namespace> port-forward pod/<pod-name> 18080:8080

访问方式：

1
http://127.0.0.1:18080

转发 Service#

通常转发 Service 更稳：

1
kubectl -n <namespace> port-forward svc/<service-name> 18080:8080

注意这里后面的 8080 是 Service 的端口，不一定是容器端口。

让局域网其他机器也能访问#

默认只监听本机 127.0.0.1。如果要让其他机器访问你这台主机上的转发端口：

1
kubectl -n <namespace> port-forward --address 0.0.0.0 pod/<pod-name> 18080:8080

然后其他机器访问：

1
http://你的主机IP:18080

常用排查命令#

1
kubectl get pods -n <namespace>
2
kubectl get svc -n <namespace>
3
kubectl describe pod <pod-name> -n <namespace>

注意事项#

• kubectl port-forward 是前台命令，终端关闭后转发会断开。
• 目标端口必须是 Pod 或 Service 实际监听的端口。
• 如果是长期暴露服务，不建议靠 port-forward，应该考虑 NodePort、LoadBalancer、Ingress 或反向代理。

Kubernetes

查看当前集群#

1
kubectl config current-context
2
kubectl get nodes
3
kubectl get ns

查看资源#

1
kubectl get all -n demo
2
kubectl get pods -n demo
3
kubectl get deploy -n demo
4
kubectl get svc -n demo
5
kubectl get configmap -n demo
6
kubectl get secret -n demo
7
kubectl get job -n demo

查看详情#

1
kubectl describe pod -n demo <pod-name>
2
kubectl describe deploy -n demo user-api-deployment
3
kubectl describe svc -n demo user-api

看日志#

1
kubectl logs -n demo <pod-name>
2
kubectl logs -f -n demo deploy/user-api-deployment
3
kubectl logs -n demo job/ai-migrate-job

进入容器#

1
kubectl exec -it -n demo <pod-name> -- sh

本地访问服务#

1
kubectl port-forward -n demo svc/user-api 18000:80
2
curl http://localhost:18000/readyz

部署和删除#

1
kubectl kustomize deploy/overlay/dev
2
kubectl apply -k deploy/overlay/dev
3
kubectl delete -k deploy/overlay/dev

重启和发布状态#

1
kubectl rollout restart deployment/user-api-deployment -n demo
2
kubectl rollout status deployment/user-api-deployment -n demo
3
kubectl rollout history deployment/user-api-deployment -n demo

看事件#

1
kubectl get events -n demo --sort-by=.lastTimestamp

相关笔记：Kubernetes 排障手册、K8s 本地实战

它解决什么问题#

Deployment 后面可能有多个 Pod：

1
user-api Pod A: 10.1.0.11
2
user-api Pod B: 10.1.0.12
3
user-api Pod C: 10.1.0.13

客户端不应该记住这些 Pod IP，因为 Pod 随时会变化。Service 通过 label selector 找到这些 Pod，对外提供一个稳定入口。

1
client -> Service -> matching Pods

最小示例#

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: user-service
5
spec:
6
  type: ClusterIP
7
  selector:
8
    app: user-service
9
  ports:
10
    - name: http
11
      port: 80
12
      targetPort: 8000

关键字段：

Service 类型#

实际项目例子#

项目里有：

• user-api：把流量转发到 app: user-api 的 Pod。
• admin-api：把流量转发到 app: admin-api 的 Pod。

本地调试时常用 port-forward：

1
kubectl port-forward -n demo svc/user-api 18000:80
2
curl http://localhost:18000/readyz

常用命令#

1
kubectl get svc -n demo
2
kubectl describe svc user-api -n demo
3
kubectl get endpoints -n demo

如果 Service 没有转发到 Pod，优先检查：

• Service 的 selector 是否匹配 Pod 的 labels。
• Pod 是否处于 Ready 状态。
• targetPort 是否等于容器实际监听端口。

相关笔记：pod、k8s deployment、Kubernetes 排障手册

控制平面组件 #

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足 Deployment 的 [replicas](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-replica) 字段时，要启动新的 Pod）。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，安装脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 请参阅使用 kubeadm 构建高可用性集群中关于跨多机器安装控制平面的示例。

节点组件 #

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境。

插件（Addons） #

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

下面描述众多插件中的几种。有关可用插件的完整列表， 请参见插件（Addons）。

对比结论#

参考资料：

• 16 张图解带你掌握一致性哈希算法 - 华为开发者话题
• Consistent 和 Rendezvous 两种分布式 Hash 的比较 - 知乎
• 分布式算法 - 一致性 Hash 算法 - Java 全栈知识体系

实测的两条核心结论：

• rendezvous 的均匀度更好，所有场景的均值偏差都在 10% 以内。但当集群节点数较多时，rendezvous 更耗时：100 个节点时，rendezvous 的耗时是 consistent 的一倍（因为每个 key 都要和全部节点算一遍分数，O(n)）。
• consistent 随虚拟节点数量增加，均匀性越来越好，且虚拟节点数量基本不影响调度用时（哈希环 + 二分查找，O(log n)）。但均匀度和 rendezvous 比始终有差距。

怎么选#

• 节点数较少：直接选 rendezvous hash，简单且均匀。
• 节点数较多且时间敏感：选 consistent hash。
• 节点数较多但对均匀性要求更高、能接受耗时：依然选 rendezvous hash 来确保均匀性。

一句话：rendezvous 用计算时间换均匀度；consistent 用虚拟节点改善均匀度，查询则是哈希环上 O(log n) 的二分。

核心结论#

• Gateway 负责 Authentication（你是谁）
• Microservice 负责 Authorization（你能干什么）

Gateway 应该做什么#

• 验证登录态：JWT / OAuth2 / Session / API Key
• 提取并传递身份上下文：x-user-id、x-user-role、x-tenant-id
• 公共安全能力：限流、黑名单、IP 风控、CORS、TLS、WAF、审计日志、Tracing

Service 必须做什么#

• 校验资源归属（是否本人数据）
• 校验角色权限（RBAC）
• 校验属性条件（ABAC，可选）
• 校验租户边界（tenant）

反例#

只在 Gateway 校验 JWT，service 完全信任 header。

风险：

• 内网横向攻击
• 内部请求伪造
• SSRF 间接越权
• 资源 ID 枚举导致越权操作

gRPC 透传身份（Go）#

1
md := metadata.Pairs(
2
    "x-user-id", "123",
3
    "x-user-role", "user",
4
)
5
ctx := metadata.NewOutgoingContext(ctx, md)
6

7
// server side
8
md, _ = metadata.FromIncomingContext(ctx)
9
uid := md.Get("x-user-id")
10
role := md.Get("x-user-role")

说明：

• metadata 适合内部身份上下文透传
• 不能只“读到 uid 就执行业务”，必须继续做业务授权校验

更成熟的内部安全#

• 内部签名头（例如：x-auth-signature + x-request-ts）防伪造
• Service Mesh（Istio/Linkerd）做服务间 mTLS 身份认证

文件服务场景落地#

外部：HTTP/JSON -> Gateway
内部：Gateway -> gRPC filesystem-service

filesystem-service 关注：

• 元数据、分片、hash、配额、权限
• 对象存储交互
• presigned URL 签发

大文件推荐：

• Gateway 只签发 URL
• 客户端直传对象存储（S3/OSS/MinIO）

快速检查清单#

• 是否明确区分认证与授权
• service 是否做了资源归属校验
• 是否有 role/tenant 维度校验
• 是否限制了内部伪造请求风险
• 上传链路是否避免 Gateway 传大文件

启动和停止#

1
minikube start
2
minikube status
3
minikube stop
4
minikube delete

确认 kubectl 连到 minikube#

1
kubectl config current-context
2
kubectl get nodes

正常情况下会看到：

1
minikube

使用 minikube 内部 Docker#

本地构建镜像后，如果希望 Kubernetes 直接使用这个镜像，需要让当前 shell 的 Docker 命令指向 minikube 内部 Docker：

1
eval $(minikube docker-env)

之后构建的镜像会进入 minikube，可以配合：

1
imagePullPolicy: IfNotPresent

避免 Kubernetes 去远程镜像仓库拉取。

退出 minikube Docker 环境#

1
eval $(minikube docker-env -u)

常用调试命令#

1
minikube dashboard
2
minikube ssh
3
minikube image ls

本地练习#

推荐流程：

1
minikube start
2
eval $(minikube docker-env)
3
make build-base-image
4
APP_VERSION=dev docker compose -f docker-compose.yaml build user-api admin-api worker image-worker
5
docker tag user-api:dev localhost/user-api:dev
6
kubectl apply -k deploy/overlay/dev

相关笔记：kubectl 常用命令

一个具体例子#

1
# 上下文 = 当前目录（末尾的 .），Dockerfile 默认为 ./Dockerfile
2
docker build -t my-app .
3

4
# 上下文 = 当前目录，但指定别的 Dockerfile
5
docker build -f microservice.Dockerfile -t my-app .
6

7
# 上下文 = 指定目录（构建时路径都相对它解析）
8
docker build -t my-app ./backend

执行 docker build . 时终端里那一行 Sending build context to Docker daemon xx MB，就是把整个上下文目录打包成 tar 传给 daemon 的过程——这也解释了为什么 COPY 不能引用上下文之外的路径（如 COPY ../foo 是非法的）。

用 .dockerignore 收窄上下文#

上下文太大不仅拖慢构建，还会把不该进镜像的文件传进 daemon。在上下文根目录放 .dockerignore：

1
.git
2
node_modules
3
dist
4
*.log
5
.env

语法类似 .gitignore。被排除的文件不会进入 tar 包，COPY . 也就拿不到它们，同时避免密钥、构建产物意外进镜像。

分区与复制#

主题的每个分区都有至少一个副本，也就是 --replication-factor 参数必须大于 1。副本分为 leader 和 follower 两种，每个副本都需要消耗一个存储空间，leader 对外提供读写消息，而 follower 提供冗余备份，leader 会及时将消息增量同步到所有 follower 中。

在 hello-topic 主题中，当分区只有一个副本时，或只关注 leader 副本时，leader 副本对应的 Broker 节点位置如下：

如果设置了多个副本( --replication-factor=3 ) 时，leader 副本和 follower 副本的位置如下所示：

在不同的副本中，只有 leader 副本能够进行读写，follower 接收从 leader 推送过来的数据，做好冗余备份。

docker build 各种用法#

1
sudo docker build -f microservice.Dockerfile -t docker-jar .

1
sudo docker build -t minecraft-modpack-server .

1
cat Dockerfile | docker build -

1
docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14

删除镜像#

1
# 删除单个镜像（可以用镜像名:tag 或镜像 ID）
2
docker rmi nginx:latest
3

4
# 强制删除（即使有基于它的容器存在）
5
docker rmi -f <image-id>
6

7
# 清理所有悬空镜像（dangling，即没有 tag 引用的中间层）
8
docker image prune
9

10
# 清理所有未被任何容器使用的镜像
11
docker image prune -a

为什么需要#

典型的缓存只缓存「查到了」的结果，但线上更耗资源的往往是查不到的请求：

• 缓存穿透：不存在的 key 每次都要打到数据库，负面结果不缓存，等于每次都白查一遍。
• 下游故障放大：某个依赖超时/报错后，上层不断重试同样的失败请求，把故障放大。
• 恶意或爬虫流量：大量轮询不存在的资源 ID。

负缓存（negative caching）就是把「不存在 / 失败」也当成一种结果缓存起来，短时间内对同一 key 直接复用这个结论。

实现要点#

1
// 极简示意：本地 map + 过期时间
2
var negativeCache sync.Map // key -> expireAt
3

4
func GetProfile(ctx context.Context, id string) (*Profile, error) {
5
  if exp, ok := negativeCache.Load(id); ok && time.Now().Before(exp.(time.Time)) {
6
    return nil, ErrNotFound // 命中负缓存，直接返回
7
  }
8
  p, err := repo.Find(ctx, id)
9
  if errors.Is(err, ErrNotFound) {
10
    negativeCache.Store(id, time.Now().Add(60*time.Second))
11
    return nil, err
12
  }
13
  return p, err
14
}

• TTL 要短：负缓存是「暂时的结论」，实体可能随后就被创建。一般秒级到一分钟，宁短勿长。
• 只缓存确定性失败：不存在 可以缓存；超时/网络错误 不应该固化为负缓存，否则下游恢复后仍被挡住。
• 要有容量上限与淘汰：本地内存是无底洞风险，配合 LRU 或分片 + 定期清理，防止被不存在的 key 撑爆。
• 命中打点：监控负缓存命中率，异常升高往往意味着上游调用方在犯错或有攻击流量。

与「缓存空对象」是同一个思路，只是把空值判断从 Redis 前移到进程内，省一次网络往返。

排查与定位#

• 开启慢查询日志：slow_query_log=ON，long_query_time=0.2，配合 pt-query-digest 或云监控聚合分析。
• 用 EXPLAIN 看执行计划，重点看 type（至少到 range，避免 ALL 全表扫描）、key（实际用到的索引）、rows（预估扫描行数）、Extra（Using filesort / Using temporary 都是危险信号）。

JOIN 与数据量#

内联JOIN是求交集，数据变小

外JOIN，会导致数据量过大

• JOIN 的驱动表尽量选过滤后结果集小的那张，被驱动表的关联列必须有索引。
• 避免在 JOIN 条件列上做函数运算或类型转换（如字符串列和数字比较），否则索引失效。

索引失效的常见场景#

• 对索引列使用函数或运算：WHERE DATE(created_at) = ...、WHERE id + 1 = ...。
• 隐式类型转换：varchar 列用数字比较。
• 前导模糊匹配：LIKE '%keyword'。
• 联合索引不满足最左前缀。
• IN 列表过大：如果 IN 关键字包含的id过多，数据库有可能抛弃索引直接进行全表扫描（优化器认为回表成本高于全表扫描）。

分批查询#

如果单次查询的数据量大于1000，则最好需要分批次进行查询 每批次500条

分批不只为了保护索引，还能控制单次网络包大小、减少锁持有时间与内存占用。配合覆盖索引（只 SELECT 需要的列）效果更好。

RDB#

RedisDatabase

将Redis某一时刻的内存数据写入到RDB文件中，并保存到磁盘上。 该文件是一个压缩过的二进制文件，默认文件名为dump.rdb，通过该文件可以还原redis数据库的数据。在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中，达到恢复数据目的。

可根据 redis.conf 配置文件中设置rdb文件名 和 保存目录：

1
# 指定本地数据库文件名（rdb文件的名称），默认值为dump.rdb
2
dbfilename dump.rdb
3

4
# 指定本地数据库存放目录（dump.rdb文件存放目录），rdb、aof文件也会写在这个目录dir /usr/local/var/db/redis/

save#

当某个客户端发送 save 命令后，此时会阻塞当前Redis服务器，在RDB文件创建完成之前是不能处理其他客户端发送的任何命令请求，如果数据量太大会造成长时间阻塞，期间redis无法处理其他请求，线上环境不建议使用。

bgsave#

当某个客户端发送 bgsave 命令后，Redis服务器会执行fork() 函数创建一个子进程，由子进程负责rdb文件创建和写入，期间服务器不会阻塞，可以接受其他客户端的命令请求，**但在fork执行阶段，服务器还会阻塞，无法接受其他客户端命令（一般时间很短）

自动触发#

在以下几种情况时会自动触发生成 RDB 文件：

• redis.conf 配置文件中达到 save 参数条件
• 主从复制时，从节点要从主节点进行全量复制，此时会触发 bgsave，生成快照发送到从节点
• 执行 shutdown，如果没有开启 AOF 持久化，会触发 bgsave
• 执行 flushall（生成空的 dump.rdb！）

flushall#

flushall 生成的是空dump.rdb文件，目的是覆盖并删除上次备份的快照，防止redis重启时，自动载入并恢复到上一份备份数据！

为什么会有 DDD#

很多项目一开始都是这样：

1
controller
2
service
3
repository
4
model

例如：

1
user_controller.go
2
user_service.go
3
user_repo.go

当业务简单时没问题。

但随着需求增加：

1
用户
2
订单
3
支付
4
优惠券
5
库存
6
物流
7
积分

Service 会越来越大：

1
func CreateOrder() {
2
    检查库存
3
    检查优惠券
4
    扣减库存
5
    创建订单
6
    创建支付单
7
    发MQ
8
}

最后：

1
OrderService
2
3000行

业务规则散落在：

• Controller
• Service
• SQL
• MQ Consumer

维护起来很痛苦。

DDD 就是为了解决：

复杂业务逻辑如何长期演进。

DDD 的核心概念#

1
电商系统
2
├── 用户领域
3
├── 订单领域
4
├── 支付领域
5
├── 库存领域
6
└── 物流领域

1
type User struct {
2
    ID int64
3
    Name string
4
}

1
张三 → 李四

1
ID没变

1
type Money struct {
2
    Amount int64
3
    Currency string
4
}

1
100 CNY
2
100 CNY

1
Order
2
├── OrderItem
3
├── Address
4
└── PaymentInfo

1
Order Aggregate

1
Order

1
OrderItem

1
order.AddItem(...)

1
order.Items[0].Count++

Repository#

Repository 不是 DAO。

DAO：

1
db.Create(...)

Repository：

1
type OrderRepository interface {
2
    Save(order *Order)
3
    FindByID(id string)
4
}

领域层不知道：

1
MySQL
2
PostgreSQL
3
Redis

Domain Service#

有些业务不属于某个实体。

例如：

1
订单创建
2
需要：
3

4
库存
5
优惠券
6
支付

放进 Order 也不合适。

这时：

1
type OrderDomainService struct {}

负责跨聚合逻辑。

Application Service#

很多人容易混淆。

DDD里通常：

1
Controller
2
 ↓
3
Application Service
4
 ↓
5
Domain
6
 ↓
7
Repository

Application Service：

负责：

• 编排流程
• 事务
• 调用领域对象

例如：

1
func CreateOrder(cmd CreateOrderCommand) {
2
    order := domain.NewOrder()
3

4
    order.AddItem(...)
5

6
    repo.Save(order)
7

8
    mq.Publish(...)
9
}

分层架构#

经典 DDD：

1
┌──────────────────┐
2
│ Presentation     │
3
│ Controller/API   │
4
└────────┬─────────┘
5
         ▼
6
┌──────────────────┐
7
│ Application      │
8
│ Use Case         │
9
└────────┬─────────┘
10
         ▼
11
┌──────────────────┐
12
│ Domain           │
13
│ Entity           │
14
│ Aggregate        │
15
│ Domain Service   │
16
└────────┬─────────┘
17
         ▼
18
┌──────────────────┐
19
│ Infrastructure   │
20
│ DB MQ Redis      │
21
└──────────────────┘

Go 项目常见目录#

1
internal/
2

3
├── application
4
│   └── order
5
│       └── service.go
6

7
├── domain
8
│   └── order
9
│       ├── entity.go
10
│       ├── repository.go
11
│       └── service.go
12

13
├── infrastructure
14
│   └── repository
15
│       └── order_repo.go
16

17
└── interfaces
18
    └── http
19
        └── order_handler.go

在微服务里怎么用#

假设你之前说的在线判题系统：

1
gateway
2
user
3
problem
4
judge
5
sandbox

每个微服务都可以有自己的领域。

例如：

1
Problem
2
Tag
3
SubmissionRule

1
Submission
2
JudgeTask
3
JudgeResult

1
User
2
Role
3
Permission

DDD 和 MVC 的区别#

MVC：

1
Controller
2
 ↓
3
Service
4
 ↓
5
DAO

关注：

1
代码分层

DDD：

1
Domain
2
 ↓
3
Aggregate
4
 ↓
5
Business Rules

关注：

1
业务建模

所以：

MVC 是技术视角，DDD 是业务视角。

两者并不冲突。

什么时候值得引入 DDD#

如果是学习性质的：

1
Gateway
2
User
3
Problem
4
Judge
5
Sandbox

我的建议是：

1
handler
2
service
3
repo

1
提交代码
2
↓
3
创建Submission
4
↓
5
发MQ
6
↓
7
Judge消费
8
↓
9
更新结果
10
↓
11
更新排行榜

1
Aggregate
2
Domain Service
3
Repository

1
为了DDD而DDD

1
三层架构
2
    ↓
3
理解微服务
4
    ↓
5
事件驱动(MQ)
6
    ↓
7
DDD Lite
8
    ↓
9
完整DDD

1. StrEnum：运行时的枚举类型#

Python 3.11+

1
from enum import StrEnum
2

3
class Status(StrEnum):
4
    PENDING = "pending"
5
    SUCCESS = "success"
6
    FAILED = "failed"

使用：

1
status = Status.PENDING
2

3
print(status)          # pending
4
print(status.value)    # pending

特点：

• 运行时真实存在的对象
• 可以遍历
• 可以比较
• 可以作为配置、数据库字段、API参数等统一定义

1
for s in Status:
2
    print(s)

1
if status == Status.PENDING:
2
    ...

2. Literal：类型提示#

来自 typing

1
from typing import Literal
2

3
Status = Literal[
4
    "pending",
5
    "success",
6
    "failed"
7
]

使用：

1
def update_status(
2
    status: Status
3
):
4
    ...

IDE 会提示：

1
update_status("pending")  # ✅
2

3
update_status("abc")      # ❌ 类型检查报错

特点：

• 只存在于类型系统
• 运行时没有枚举对象
• 不能遍历
• 不能写 Status.PENDING

1
print(Status)

输出：

1
typing.Literal['pending', 'success', 'failed']

对比#

FastAPI/Pydantic 场景#

通常推荐：

1
from enum import StrEnum
2

3
class ModelProvider(StrEnum):
4
    OPENAI = "openai"
5
    ANTHROPIC = "anthropic"
6
    GEMINI = "gemini"

1
from pydantic import BaseModel
2

3
class Request(BaseModel):
4
    provider: ModelProvider

自动生成 OpenAPI：

1
{
2
  "enum": [
3
    "openai",
4
    "anthropic",
5
    "gemini"
6
  ]
7
}

同时还能：

1
if req.provider == ModelProvider.OPENAI:
2
    ...

什么时候用 Literal？#

当你只是想约束几个字符串参数，而且不会在别处复用：

1
def create_message(
2
    role: Literal[
3
        "user",
4
        "assistant",
5
        "system"
6
    ]
7
):
8
    ...

这种场景用 Literal 很轻量。

实际项目建议#

• 业务领域概念（状态、模型提供商、订单类型等） → StrEnum
• 函数参数的简单约束 → Literal
• FastAPI/Pydantic Schema → 优先 StrEnum

很多大型 Python 项目（如 Pydantic、FastAPI、LangGraph 等）最终都会把重要的字符串常量抽成 StrEnum，因为它既有类型安全，又有运行时能力。

1. C++ 的方式：生产者提供全局 Header 作为契约（显式、中心化）#

• 历史和编译模型驱动：C++ 继承自 C 的分离编译（separate compilation）模型。源文件（.cpp）分开编译成对象文件，再链接。编译器在编译一个 .cpp 时，需要知道其他模块的声明（类型、函数签名、类布局等），否则无法生成正确的代码（尤其是虚函数表、内存布局等）。
  • Header 文件（.h/.hpp）就是这个“声明”的载体。它定义了类、函数、虚方法等，作为全局可见的契约。
  • 生产者（库作者）必须在 header 中把接口写好，消费者（用户代码）通过 #include 来使用。
• 显式实现：类需要显式继承抽象基类（带纯虚函数），或使用模板。改变 header 往往影响 ABI（二进制兼容性），容易导致“header hell”、编译时间爆炸和耦合。
• 优势：适合大型系统，需要精确控制内存布局、性能和二进制接口（比如游戏引擎、系统库）。header 像一份“公开规格书”。

这是生产者驱动（producer-driven）的契约：生产者决定“我的东西长什么样，你们都得按这个来”。

2. Go 的方式：消费者在消费端定义 interface（隐式、分散化）#

• 编译模型不同：Go 没有 header，整个 package 一起编译（快速构建是 Go 的核心目标之一）。编译器能直接看到所有源码，不需要单独的声明文件。
• 隐式满足（Implicit Implementation）：这是 Go 接口最关键的特性。
  • 一个类型只要实现了 interface 声明的所有方法，就自动满足该 interface，不需要 implements 关键字。
  • 接口本身只是一组方法签名的集合（往往很小，比如 io.Reader 只一个 Read 方法）。
• 消费者定义：推荐在使用接口的地方（消费者包）定义 interface，而不是在提供具体实现的包里。

为什么 Go 这样设计？

• 解耦和灵活性：生产者只需提供具体类型（struct + 方法），不需要预知所有可能的用法。消费者根据自己当前需求定义最小化的 interface（“我只需要这些行为”）。这符合 Go “小接口、大组合”的哲学（Small Interfaces）。
  • 例子：标准库的 io.Reader、io.Writer、fmt.Stringer 等，都是极小的接口，定义在需要它们的地方。
• 减少依赖：消费者定义 interface 时，不需要导入生产者包里的接口定义（避免循环依赖或不必要的包依赖）。测试时特别方便——你可以轻松 mock 一个只满足你自定义 interface 的假对象。
• Duck Typing 的静态检查版：像动态语言的鸭子类型，但编译期就检查。生产者代码不需要“知道”任何 interface 的存在。
• 设计哲学：Go 强调简单、可维护、少预判。生产者不用在设计时“预见所有用例”（这往往会导致胖接口、违背接口隔离原则）。消费者只依赖自己真正需要的行为，代码更松耦合、更易演化。

总结对比#

Go 的这种设计不是“随意”，而是深思熟虑的结果：它让接口真正成为“行为契约”而非“类型层次结构”。很多从 Java/C++ 转 Go 的人初期会不适应（总想在生产者端定义大接口），但用熟后会发现测试、扩展和维护都轻松很多。

1. PRIVATE#

PRIVATE 意味着包含目录仅对该目标自身可见，它不会传播给链接该目标的其他目标。

1
target_include_directories(MyTarget PRIVATE include/)

• 使用场景：目标在自身编译时需要该包含目录，但不希望其他链接到这个目标的目标使用该目录。

2. INTERFACE#

INTERFACE 表示该目标本身不需要这个包含目录，但是链接到这个目标的其他目标会需要它。

1
target_include_directories(MyTarget INTERFACE include/)

• 使用场景：该目标是一个头文件库（例如header-only library），它自身不需要包含目录，但任何链接到它的目标都需要这个包含目录来编译。

3. PUBLIC#

PUBLIC 意味着包含目录对该目标自身和链接到该目标的其他目标都可见。它既会用于编译这个目标，也会传播给任何依赖它的其他目标。

1
target_include_directories(MyTarget PUBLIC include/)

• 使用场景：该目标在编译时需要包含目录，同时任何依赖这个目标的其他目标也需要该包含目录。

总结：#

分析#

当需要求某个数是最大值/最小值的时候，会考虑到问题是否可以通过二分搜索来解决。

能用二分搜索解决的问题通常具有单调性，而对于本题，很明显的一个事实是如果等待时间越短，那么三个雕刻师一开始所选择的图案就与越多的玩具的a[i]相似.。

而且，还注意到，如果3个雕刻师能够在 t 的时间内制作所有的玩具，那么3个雕刻师必定也能在 d (d > t) 的时间内也制作所有的玩具

因此我们可以尝试二分搜索可行的时间（即三个雕刻师是否可以在这个时间内把所有的玩具制作完），一旦查到可行的时间，我们便试着不断缩小搜索的区间去把mid值逼近最优解。

条件判断#

那么现在的问题是该如何判断三者可以在时间 t 内制作所有玩具？

想象一下，如果我们给三个雕刻师分别分配任务，时间 t 实际上取决于三者之间最晚完成任务的人。 考虑到任务分配的顺序是没有影响的，那么我们最好对图案数组先排序一次，因为排序后的数组中对于 任意的 (i, j)，他们的 |a[i] - a[j]| 的值总要比未排序的要小。

也就是因为这个排序后的性质，如果我们在排序后的数组里面按顺序分配任务，选定 i，某个雕刻师在 t 时间内能制作完成的玩具数量即为在 [a[i], a[i] + 2*x] 值区间内的 a[i] 的数量

所以剩下来的部分就只有模拟了，我们模拟分配工作给雕刻师，记录当前已完成制作的玩具的数量 cur，每名雕刻师的工作完成后cur都会增加，而这个cur后面的玩具又会交给下一个雕刻师，最后检查cur是否到达n个数量即可

详细代码#

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int mod = 1e6+10;
5
typedef long long ll;
6
#define x first
7
#define y second
8
typedef pair<int, int> P;
9

10
ll v[mod];
11
ll n;
12

13
bool check(ll x) {
14
  int cur = 0;
15
    for (int i = 0; i < 3; ++i) {
16
        int start = v[cur];
17
        int end = start + 2 * x;
18
        while (cur < n && v[cur] <= end) {
19
            ++cur;
20
        }
21
        if (cur >= n) {
22
            return true;
23
        }
24
    }
25

26
    return cur >= n;
27
}
28

29
void solve() {
30
  cin >> n;
31

32
  for (int i = 0; i < n; i++) {
33
    cin >> v[i];
34
  }
35

36
  sort(v, v+n);
37

38
  ll l = 0, r = 1e9;
39
  ll mid,ans=1e9;
40
  //mid为三者雕刻所需要的最大时间
41
  //check的时候，尽可能多的在mid时间内为雕刻师安排多的v
42
  //显然这个问题具有单调性，如果用时越久，模具的制作偏差就越大
43
  while (l <= r) {
44
    mid=(l+r)>>1;
45
    if (check(mid)) {
46
      r = mid-1;
47
      ans = mid;
48
    } else {
49
      l = mid+1;
50
    }
51
  }
52
  cout << ans << endl;
53
}
54

55
int main() {
56
    ios_base::sync_with_stdio(false);
57
    cin.tie(NULL);
58
    cout.tie(NULL);
59

60
  int t;
61
  cin >> t;
62
  while(t--) solve();
63

64
  return 0;
65
}

输入#

第一行包含一个整数 t ( 1≤t≤100) - 测试用例数。 对于每个测试用例，单行输入包含一个整数 n ( 1≤n≤100)。 保证在所有测试用例中， n 都是不同的。

输出#

对于每个测试用例，按以下格式输出答案： 在第一行，输出整数 x - 给定 n 的坏测试次数。 在接下来的 x 行中，输出两个整数 ai 和 bi - K1o0n 在测试” n “中的解决方案的整数。 ai bi” 得到正确答案。

Input

1
3
2
2
3
3
4
10

Output

1
3
2
20 18
3
219 216
4
2218 2214
5
1
6
165 162
7
1
8
1262 2519

题目大意：#

给你一个整数n，现在对于n*a - b有两种运算：

1. n作为一个字符往后延伸至a个，然后从最后减去b个字符
2. n作为一个数字，进行运算n*a - b

需要你求出 (a, b) 不同的组合数，使得两种运算后的结果相同。

思考#

此题的数据范围不大，使用暴力枚举再调整合适的枚举范围是可以通过的。

对于此题，我们容易想到O(n^2)的暴力解法，即从010000枚举a再从 0a*n 去枚举b 但是这样子做必定会超时，我们不可能直接按题目给的范围去直接枚举b

1
int len = 0;
2
while (tmp[len]) {
3
  arr[len] = tmp[len]-'0';
4
  len++;
5
}
6
for (int a = 1; a <= 10000; a++)
7
  for (int b = 0; b <= a*len; b++)

1
val = (n*a) - b; //具体值
2
rep = (a*len - b); //目标的字符串有多长
3

4
if (!val || !rep) {
5
  break;
6
}
7

8
int r = 0;
9
for (int i = 0; i < rep; i++) {
10
  r = r * 10 + arr[i%len];
11
}
12
if (r == val) {
13
  ans.push_back({a, b});
14
}

题解代码#

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int mod = 1e6+10;
5
typedef long long ll;
6
#define x first
7
#define y second
8
typedef pair<int, int> P;
9

10
void solve() {
11
    int n;
12
    cin >> n;
13

14
    vector<P> ans;
15
    int val;
16
    int rep;
17
    int d;
18

19
    int arr[3];
20
    char tmp[256] {};
21
    itoa(n, tmp, 10);
22
    int len = 0;
23

24
    while (tmp[len]) {
25
        arr[len] = tmp[len]-'0';
26
        len++;
27
    }
28

29
    for (int a = 1; a <= 10000; a++) {
30
        //对于B:  上界: a*len-1，下界: a*len-6 (在区间内最多不会超过6个字符)
31
        for (int b = max(1, len*a -5); b <= a*len; b++) {
32
            val = (n*a) - b; //具体值
33
            rep = (a*len - b); //目标的字符串有多长
34

35
            if (!val || !rep) {
36
                break;
37
            }
38

39
            int r = 0;
40
            for (int i = 0; i < rep; i++) {
41
                r = r * 10 + arr[i%len];
42
            }
43
            if (r == val) {
44
                ans.push_back({a, b});
45
            }
46
        }
47
    }
48

49
    cout << ans.size() << endl;
50
    for (int i = 0; i < ans.size(); i++) {
51
        cout << ans[i].x << ' ' << ans[i].y << endl;
52
    }
53
}
54

55
int main() {
56
    ios_base::sync_with_stdio(false);
57
    cin.tie(NULL);
58
    cout.tie(NULL);
59

60
    int t;
61
    cin >> t;
62
    while (t--)
63
        solve();
64

65
    return 0;
66
}