yldmdocs

notification · 平台通知服务

notification 是 platform 类目下的一个微服务，镜像来自 ghcr.io/yldm-tech/notification，对外暴露 HTTP 8080 端口并提供 /health/live、/health/ready、/metrics 端点。从配置看，它负责消息通知的发送：配置文件中有独立的 Email（SMTP）段与 SMS 段（默认 provider 为 aliyun），业务数据落在 MySQL（库名默认 yldm_notification），并使用 Redis 做缓存与发布订阅（pubsub 前缀 yldm:notification，带死信队列 yldm:notification:deadletter），通过 Consul 做服务注册。镜像 tag 由 argocd-image-updater 按 semver 写回 kustomization，不要手动钉版本。

部署形态

  • Name
    命名空间
    Description
    platform（kustomization 设 namespace: platform、namePrefix: platform-，故活动对象名为 platform-notification-*）
  • Name
    工作负载
    Description
    Deployment
  • Name
    镜像 / 版本
    Description
    ghcr.io/yldm-tech/notification:2.3.1（kustomization images: 写回目标）
  • Name
    副本数
    Description
    2（kustomization replicas: 与 deployment replicas 均为 2）
  • Name
    滚动策略
    Description
    maxUnavailable: 0、maxSurge: 1，更新期间不减少可用副本
  • Name
    调度
    Description
    nodeSelector: workload=app；kustomization patch 设 priorityClassName: production-medium；按 app=notification 标签做主机级 podAntiAffinity（preferred，topologyKey kubernetes.io/hostname）
  • Name
    端口
    Description
    容器 8080，命名 http
  • Name
    资源
    Description
    requests cpu 50m / memory 64Mi，limits cpu 200m / memory 256Mi
  • Name
    健康检查
    Description
    liveness GET /health/live（initialDelay 30s，period 10s）；readiness GET /health/ready（initialDelay 15s，period 5s，timeout 5s）
  • Name
    存储
    Description
    无 PVC，配置以 ConfigMap 卷只读挂载

配置与依赖

容器以 CONFIG_FILE=configs/services/notification.yaml 读取配置，该文件来自 notification-config ConfigMap，挂载到 /root/configs/services/notification.yaml（subPath）；另有一个集群共享的 base-config ConfigMap 只读挂载到 /root/configs/base，notification.yaml 在其基础上覆盖特定字段。配置里 database / redis / pubsub / tracing 各段沿用基础值并覆盖库名与 db 编号；Email（email.smtp.*，默认发件人 noreply@yldm.tech、from_name YLDM、端口 587）与 SMS（sms.*，默认 provider aliyun）两段的敏感值都用 ${VAR} 占位，由环境变量在运行时注入。kustomization 通过 reloader.stakater.com/auto: "true" 注解让 reloader 在 ConfigMap/Secret 变更时自动滚动 Deployment。

运行环境固定为生产：ENV / ENVIRONMENT 为 production，SERVER_MODE=release，SWAGGER_AUTO_GEN=false，SERVER_PORT=8080，SERVER_NAME=notification。服务注册开启 Consul：CONSUL_ENABLED=true、CONSUL_ADDR=consul.consul.svc.cluster.local:8500。

所有密钥来自 ExternalSecret notification-db-secret（ClusterSecretStore vault-backend，KV v2，刷新间隔 1h），合成同名 Secret 后被 deployment 以 secretKeyRef 注入；注释明确这是“服务独立的 Secret，实现数据库凭证隔离”：

来源 Vault 路径 (remoteRef.key)注入的键
yldm/production/notificationdb_host/port/name/user/password、redis_host/port/password/db/pubsub_db、jwt_secret/expires_in/refresh_expires_in
yldm/databaseDB_ADMIN_USER、DB_ADMIN_PASSWORD（共享数据库管理员凭据）

注意 SMTP 与 SMS 的实际凭据（SMTP_*、SMS_*）在 ConfigMap 中以 ${VAR} 占位，但当前 deployment 与 ExternalSecret 未注入这些变量，因而会落到 configmap 内的默认值（如 SMTP host/username/password 为空）。

访问与监控

Service notification 为默认 ClusterIP，按 app=notification 选择 Pod，将服务 80 端口转发到容器 8080（命名 http），无 Ingress，仅集群内访问，外部调用方经 Consul 发现。

监控方面，ServiceMonitor notification 抓取 http 端口的 /metrics（interval 30s），并把 pod / namespace / service 标签 relabel 出来。PrometheusRule notification 定义了一组 notification.rules（interval 30s）告警：Pod 掉线（up==0，1m，critical）、可用副本不足（<1，2m，critical）、HTTP 5xx 错误率（>3% warning / >5% critical）、P95 延迟（>0.5s warning / >1s critical）、频繁重启（15m 速率 >0.05，warning）、CPU 与内存使用超 limit 80%（10m，warning）。

弹性与可用性：HPA notification-hpa 以 CPU 70% / 内存 80% 的利用率为目标在 2 到 5 副本间伸缩；VPA notification-vpa 为 updateMode: "Off"（仅给建议、不自动改资源），范围 cpu 25m–500m、memory 32Mi–512Mi；PDB notification 设 maxUnavailable: 1，保证多副本下节点排空不会一次性驱逐全部 Pod。

返回 platform 类目总览

评论