Cloud

背景 在 homelab 里用 Argo CD 管理 QuantDinger（application-quantdinger.yaml，automated + selfHeal）。把 MiniMax 相关配置 push 到 w10n-config 后，集群里的 ConfigMap 一度还是旧内容：Argo 显示 Synced，但 revision 仍停在旧 commit。 当时本机没有安装 argocd CLI，于是先用 kubectl annotate 触发 hard refresh，又用 kubectl apply -k 把 manifest 直接打进集群。事后整理一下两种「触发 Argo」方式的区别，避免下次混淆。 两种方式分别做什么 argocd CLI Argo CD 官方命令行，通过 Argo API Server 操作 Application，语义最完整。 常见用途： argocd app get quantdinger：查看同步状态、health、当前 revision argocd app sync quantdinger：主动执行一次 Sync，把 Git 目标 revision 应用到集群 argocd app diff quantdinger：对比 Git 与集群 live 状态 argocd app rollback quantdinger：回滚到历史 revision sync 会走 Argo 的完整同步流水线（diff、apply、health 等待、hook 等），并在 Argo UI / Application 状态里留下明确的 operation 记录。 ...

是什么 PVC 的 accessModes 描述的是这块卷在集群里能被怎样挂载，不是 Linux 文件权限里的 rwx。 Kubernetes 常见三种： 模式 全称 含义（简化） RWO ReadWriteOnce 同一时刻，最多一个节点以读写方式挂载 ROX ReadOnlyMany 多个节点可同时只读挂载 RWX ReadWriteMany 多个节点可同时读写挂载（需 NFS、CephFS、Longhorn RWX 等） 日常自建集群里，Longhorn、本地盘、云厂商块存储（EBS 等）给 Pod 用的，几乎都是 RWO。 RWO 不等于 Pod 不能换节点 很多人会把 RWO 理解成「Pod 永远绑死在一个节点上」。更准确的说法是： 同一时刻只能有一个节点挂载读写； Pod 迁到另一节点时，流程是：旧 Pod 退出 → 卷 detach → 新节点 attach → 新 Pod 启动。 因此 RWO 不阻止 Pod 漂移，但不允许两个 Pod 同时挂同一块盘。 和 Longhorn 副本数的关系 Longhorn 的 numberOfReplicas: 2 表示数据在多个节点各存一份（容错、迁移时 attach 更快），与 RWX 无关： ...

概述 AWS Lambda 是无服务器（Serverless）计算服务：上传函数代码，由 AWS 按事件触发执行，按实际运行时长计费，无需管理虚拟机。 适合短任务、事件驱动、低频定时作业（配合 EventBridge Scheduler）、轻量 API（API Gateway）、消息消费（SQS / SNS）等场景。不适合长时间常驻进程或持续高 CPU 负载。 核心概念 概念 说明 Function 一个部署单元：代码 + 运行时 + 配置（内存、超时、环境变量） Handler 入口函数名，格式 文件名.函数名，如 lambda_function.handler Runtime 运行环境，如 python3.13、nodejs22.x Execution Role Lambda 扮演的 IAM Role，决定函数内能调用哪些 AWS API Event 触发时传入的 JSON 载荷（Scheduler、SNS、API Gateway 等格式不同） Context 运行时元数据（剩余超时时间、请求 ID 等） Resource-based policy 挂在函数上的策略，声明谁可以调用本函数（aws_lambda_permission） ARN 格式 函数 ARN 示例： arn:aws:lambda:ap-northeast-1:123456789012:function:enx-api-backup 版本与别名会追加后缀（:1、:prod）；日常在 Scheduler、SNS 订阅里通常用未限定版本的函数 ARN。 权限模型（两层） Lambda 涉及两类 IAM，容易混淆： 类型 谁配置 解决什么问题 Execution Role 函数自身 role 字段 函数出站能做什么（写日志、调 SSM、读 S3） Resource policy aws_lambda_permission 等 谁可以调用这个函数（Scheduler、SNS、API Gateway） EventBridge Scheduler ──(resource policy: lambda:InvokeFunction)──► Lambda │ ▼ Execution Role (ssm:SendCommand, logs:PutLogEvents, …) │ ▼ EC2 / SSM / … Execution Role 信任策略 Principal 为 lambda.amazonaws.com（见 AWS IAM） 调用方（如 Scheduler）还需要自己的 Role 带 lambda:InvokeFunction；函数侧通常再加一条 aws_lambda_permission 限定 source_arn Handler 约定 以 Python 为例，入口签名固定为 handler(event, context)： ...

ARN（Amazon Resource Name） ARN 是 Amazon Resource Name（亚马逊资源名称）的缩写，用于在 AWS 中唯一标识一项资源。IAM 策略、跨服务授权、Lambda 触发器、备份任务等场景里，经常需要写 ARN 来指定「对哪个资源生效」。 基本格式 arn:partition:service:region:account-id:resource 常见字段说明： 字段 说明 partition 分区，一般为 aws；中国区为 aws-cn，GovCloud 为 aws-us-gov service 服务名，如 ec2、s3、iam、lambda region 区域；全局资源（如 IAM 角色）此处为空 account-id 12 位 AWS 账号 ID resource 资源类型与 ID，格式因服务而异 示例： arn:aws:s3:::my-bucket arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcd1234 arn:aws:iam::123456789012:role/MyRole 精确到哪一级？ ARN 的粒度取决于资源类型，不是固定「只到服务」或「只到实例」。 以 EC2 为例： 资源 ARN 示例（示意） 粒度 某台 EC2 实例 arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcd1234 精确到这一台虚拟机 某块 EBS 卷 arn:aws:ec2:region:account:volume/vol-xxx 精确到这一块盘 某个安全组 arn:aws:ec2:region:account:security-group/sg-xxx 精确到这一个安全组 某个 AMI arn:aws:ec2:region:account:image/ami-xxx 精确到这一张镜像 因此：EC2 实例的 ARN 会带上 instance/i-xxxxxxxx，指向某一台具体 VM，而不是只表示「EC2 这个服务」。S3 桶、Lambda 函数、IAM 角色等同理，各自有独立的 ARN。 ...

概述 AWS Systems Manager（简称 SSM） 是 AWS 的运维管理平台：在 EC2、混合机上远程执行命令、打补丁、收集清单、免 SSH 登录等。 本文只聚焦备份场景里用到的一块：Run Command（运行命令）——通过 API 在实例上执行脚本，无需 SSH。 核心组件 组件 说明 SSM Agent 装在 EC2 上的代理，接收并执行 Run Command（Amazon Linux 2023 通常已预装） Managed Instance 已向 Systems Manager 注册的实例（Agent 在线 + IAM 权限正确） Command document 命令模板；常用内置文档 AWS-RunShellScript（跑 shell） SendCommand API：对一台或多台实例下发命令 GetCommandInvocation API：查询某台实例上该次命令的执行结果 调用方（Lambda / CLI / 控制台） → SendCommand（指定 InstanceId + Document + 命令） → SSM Agent 在 EC2 上执行 → GetCommandInvocation 查看 Success / Failed / 输出 与 SSH 的对比 SSH SSM Run Command 网络 通常要开放 22 端口 走 Agent 出站 HTTPS，不必开 22 凭证 SSH 密钥 / 密码 IAM 授权谁可以 SendCommand 调用方 人要登录或脚本 ssh Lambda、CLI、控制台均可 适合 交互式排错 自动化、批量、审计 Session Manager 是同一产品族里的交互式终端（浏览器里连 shell）；Run Command 是非交互、一次一条命令。 ...

概述 Amazon Simple Notification Service（SNS）是 AWS 的消息通知服务，采用发布/订阅（pub/sub）模型：向 Topic 发布一条消息，所有 Subscription 都会收到。 常见用途： CloudWatch Alarm 触发后发邮件、短信 应用解耦广播（一个事件通知多个下游） 推送到 Lambda、SQS、HTTP 端点 SNS 不负责监控、不负责排队存消息；它只负责「把通知送出去」。 核心概念 概念 说明 Topic 主题，消息发布的目标（如 enx-api-backup-alerts） Publisher 发布方，调用 Publish 把消息发到 Topic Subscription 订阅，声明 Topic 上的消息要发到哪（邮箱、Lambda 等） Protocol 订阅协议：email、sms、lambda、sqs、https 等 Endpoint 订阅目标地址（邮箱地址、Lambda ARN、队列 ARN 等） Publisher（CloudWatch Alarm / 应用 / 其它 AWS 服务） → Publish → Topic ├─ Subscription: email → 你的邮箱 ├─ Subscription: lambda → 触发函数 └─ Subscription: sqs → 写入队列 与 CloudWatch、SQS 的区别 服务 角色 SQS 消息队列，消费者拉取；适合异步削峰、DLQ 存档 CloudWatch 监控与告警；Alarm 触发时不直接发邮件 SNS 通知；把一条消息推给多个订阅者 备份失败通知链路： ...

概述 Amazon CloudWatch 是 AWS 的监控与可观测性服务：收集指标（Metrics）、写日志（Logs）、配置告警（Alarms）、做看板（Dashboards）。多数 AWS 服务（EC2、Lambda、SQS 等）会自动把基础指标推到 CloudWatch，无需自建 Prometheus/Grafana 也能做基础监控。 CloudWatch Alarm 不是独立产品，而是 CloudWatch 里的「指标超阈值 → 触发动作」能力，常配合 SNS 发邮件、或触发 Auto Scaling。 核心能力 能力 说明 典型用途 Metrics 时序数据（CPU、队列深度、Lambda 错误次数等） 看图、设告警 Alarms 对 metric 设阈值，满足条件时执行动作 DLQ 有消息 → 发邮件 Logs 集中存储应用 / Lambda 日志 aws logs tail 排错 Dashboards 把多个 metric 画在一张图 运维看板 Metrics 从哪来？ 来源 示例 AWS 服务自动上报 SQS ApproximateNumberOfMessagesVisible、Lambda Errors、EC2 CPUUtilization 自定义 metric 应用调用 PutMetricData 上报业务指标 Logs Insights / Metric Filter 从日志里统计错误行数生成 metric 基础服务指标通常不单独收 metric 存储费；自定义 metric 和高分辨率 metric 会另计费。 ...

概述 Amazon Simple Queue Service（SQS）是 AWS 的托管消息队列：生产者把消息发到队列，消费者拉取并处理。无需自建 RabbitMQ/Kafka 集群，按 API 请求量计费。 常见用途： 服务之间异步解耦（下单后发消息，库存服务慢慢处理） 削峰填谷（突发流量先排队，Worker 按能力消费） 作为其它服务的 Dead Letter Queue（死信队列，DLQ），收纳处理失败的消息 核心概念 概念 说明 Queue 队列本身，有唯一 URL Message 一条消息，最大 1 MiB（超大 payload 可配合 S3） Producer 发送方，调用 SendMessage Consumer 接收方，调用 ReceiveMessage，处理完后 DeleteMessage Visibility Timeout 消息被某消费者取走后，在超时时间内对其它消费者不可见；超时未删除则重新可见，可被再次处理 标准队列 vs FIFO 队列 类型 特点 适用场景 Standard 至少一次投递、可能乱序、吞吐量高 大多数场景；DLQ 通常用标准队列 FIFO 严格顺序、恰好一次（需配置）、吞吐量较低 订单、账务等强顺序场景 EventBridge Scheduler、Lambda 等配置的 DLQ，一般使用 标准队列。 计费与免费额度 SQS 没有队列月租，按 API 请求次数 计费： 永久免费档：每月 100 万次 SQS 请求（各区域合计，不结转） 超出后（标准队列，东京等区域参考价）：约 $0.40 / 百万次 请求 计费细节： ...

概述 EventBridge Scheduler 是 AWS 托管的定时任务服务，可以在指定时间或按固定频率触发各种 AWS 目标（Lambda、ECS Task、SNS、SQS 等），无需管理服务器。 与老版本的 EventBridge Rules（Cron Rules） 相比，Scheduler 是独立的服务，功能更强： 特性 EventBridge Rules EventBridge Scheduler 时区支持 仅 UTC 支持任意时区 一次性调度 不支持 支持 灵活速率表达式 有限 支持 rate、cron、一次性 目标数 每条规则最多 5 个 每个 Schedule 1 个 错误重试 无内置重试 支持重试策略和死信队列（见 AWS SQS） 时间窗口 无 支持弹性时间窗口 核心概念 Schedule 类型 类型 说明 示例 Rate 固定间隔重复 rate(5 minutes) Cron Cron 表达式，支持时区 cron(0 2 * * ? *) 每天凌晨 2 点 One-time 指定某个时刻执行一次 2026-06-01T00:00:00 Schedule Group Schedule 的逻辑分组，用于统一管理（打标签、批量删除）。默认分组为 default。 ...

核心概念 IAM（Identity and Access Management）是 AWS 的权限管理服务，控制"谁能对哪些资源做什么操作"。 概念 说明 User 人用的账号，有固定 Access Key，用于控制台登录或 CLI Group 用户组，把多个 User 归组，统一附加策略 Role 权限载体，定义"能做什么"，不能直接登录，由主体 assume Policy 权限策略（JSON），附加到 User/Group/Role 上 Instance Profile 专用于 EC2 的 Role 容器，EC2 通过它携带 Role User vs Role User：人或应用持有的固定身份，有长期有效的 Access Key。适合人工操作、CI/CD 等场景。 Role：临时身份，被某个主体（EC2、Lambda、另一个账号）“扮演”（assume）后获得临时凭证（15 分钟 ~ 12 小时有效）。不绑定固定密钥，安全性更高。 Instance Profile（EC2 专用） EC2 实例不能直接绑定 IAM Role，必须通过 Instance Profile 作为中间层： EC2 实例 └─ Instance Profile（容器） └─ IAM Role └─ 权限策略（Policy） EC2 启动后通过 IMDS（实例元数据服务，169.254.169.254）自动获取 Role 的临时凭证，aws CLI 和各语言 SDK 会自动读取，无需 aws configure。 ...

简介 Litestream 是一个开源工具，专为 SQLite 设计，以 sidecar 进程的方式运行，持续监听 SQLite 的 WAL（Write-Ahead Log），实时将变更流式同步到对象存储（S3、GCS、Azure Blob 等）。 核心特点： 不改应用代码：应用仍然正常读写 SQLite，Litestream 在旁边透明工作 实时增量复制：默认每秒同步一次 WAL frames，不是全量快照 RPO 秒级：最多丢失几秒内的写入，远优于每日全量备份的 24 小时 RPO 可恢复到任意时间点：S3 上保留完整的 WAL 历史，支持 point-in-time restore 工作原理 应用写 SQLite (enx.db) └─ SQLite WAL 机制产生变更帧 └─ Litestream 监听 WAL └─ 定期上传 WAL frames 到 S3 └─ S3 保留完整变更历史 恢复时，Litestream 从 S3 下载快照 + WAL frames，重放到指定时间点。 安装 # Arch Linux yay -S litestream-bin # 直接下载二进制（Linux amd64） wget https://github.com/benbjohnson/litestream/releases/latest/download/litestream-linux-amd64.tar.gz tar -xzf litestream-linux-amd64.tar.gz sudo mv litestream /usr/local/bin/ 配置 创建配置文件 /etc/litestream.yml： ...

概览 服务 类型 免费额度 最低月费 S3 对象存储 5 GB（前 12 个月） 极低，详见 S3 EBS 块存储 30 GB（前 12 个月） 按容量计费 EFS 文件存储（NFS） 5 GB（前 12 个月） 按用量计费 RDS 关系型数据库 db.t3.micro 750h（前 12 个月） ~$15/月 Aurora 关系型数据库（高性能） 无 ~$30/月起 DynamoDB KV / 文档 NoSQL 25 GB 存储 + 25 WCU/RCU（永久） 免费起步 ElastiCache 内存缓存（Redis / Memcached） 无 ~$15/月 DocumentDB 文档数据库（MongoDB 兼容） 无 ~$30/月起 Keyspaces 宽列 NoSQL（Cassandra 兼容） 无 按用量计费 Neptune 图数据库 无 ~$50/月起 Timestream 时序数据库 无 按用量计费 OpenSearch 全文检索 / 日志分析 无 ~$20/月起 Redshift 数据仓库（OLAP） 无 ~$180/月起 Athena S3 直接查询 无 $5/TB 查询数据量 NoSQL 数据库（免费首选） DynamoDB AWS 自研全托管 NoSQL，完全 Serverless。 ...

简介 Amazon Simple Storage Service（S3）是 AWS 的对象存储服务，用于存储任意类型的文件（备份、静态资源、日志等），按实际使用量计费。 核心概念： Bucket：存储桶，名字在全球所有 AWS 账号、所有区域共享同一命名空间，全球唯一 Object：对象，即一个文件，由 Key（路径）+ 数据 + 元数据组成 Key：对象的唯一标识符，形如 path/to/file.txt，只需在桶内唯一（S3 本身是扁平结构，/ 只是命名惯例） 概念 唯一性范围 Bucket 名字 全球唯一（跨账号、跨区域） Object Key 桶内唯一 数据存储位置 只在创建时指定的区域 区域与高可用 Bucket 在创建时必须指定区域（如 ap-northeast-1 东京），之后无法更改，数据默认只存在于该区域。 S3 在同一个区域内会把数据自动分散到至少 3 个可用区（AZ），设计耐久性是 99.999999999%（11 个 9）。区域内某个数据中心故障，数据不受影响。 如果整个区域发生故障（极罕见），默认情况下无法从其他区域访问该桶的数据。如需跨区域容灾，要显式配置 Cross-Region Replication（CRR）： 东京桶（主） --CRR--> 新加坡桶（副本） CRR 要求两个桶都开启版本控制（Versioning），并配置 IAM Role 授权跨桶复制权限。 实践建议：用于数据库备份等灾难恢复场景，单区域已经足够，无需配置 CRR。若担心区域级故障，更简单的做法是用 aws s3 sync 定期同步到另一个区域，或下载到本地存一份。 常用命令 # 列出所有 bucket aws s3 ls # 列出 bucket 内的对象 aws s3 ls s3://my-bucket/ aws s3 ls s3://my-bucket/prefix/ # 上传文件 aws s3 cp local-file.txt s3://my-bucket/path/file.txt # 下载文件 aws s3 cp s3://my-bucket/path/file.txt local-file.txt # 同步目录（本地 → S3） aws s3 sync ./local-dir s3://my-bucket/prefix/ # 同步目录（S3 → 本地） aws s3 sync s3://my-bucket/prefix/ ./local-dir # 删除对象 aws s3 rm s3://my-bucket/path/file.txt # 删除 prefix 下所有对象 aws s3 rm s3://my-bucket/prefix/ --recursive Bucket 管理 # 创建 bucket（指定区域） aws s3api create-bucket \ --bucket my-bucket \ --region ap-northeast-1 \ --create-bucket-configuration LocationConstraint=ap-northeast-1 # 删除 bucket（必须先清空） aws s3 rm s3://my-bucket --recursive aws s3api delete-bucket --bucket my-bucket # 查看 bucket 所在区域 aws s3api get-bucket-location --bucket my-bucket 生命周期策略（Lifecycle） 用于自动过期或转换存储类型，节省费用。 ...

nerdctl nerdctl 是 containerd 的命令行客户端工具，它提供了与 Docker CLI 兼容的用户体验。 什么是 nerdctl containerd 的 CLI 工具：nerdctl 全称是 “non-enterprise control”（或 containerd ctl） Docker 兼容：命令语法与 docker 命令高度兼容，降低学习成本 CNCF 项目：由 containerd 社区开发和维护 功能丰富：支持 Docker 不支持的一些高级功能 主要特性 1. Docker 兼容性 nerdctl 的命令与 docker 几乎完全兼容，可以无缝切换： # Docker 命令 docker run -d -p 80:80 nginx docker ps docker images docker build -t myapp . # nerdctl 命令（完全相同） nerdctl run -d -p 80:80 nginx nerdctl ps nerdctl images nerdctl build -t myapp . 2. 增强功能 nerdctl 支持一些 Docker 不支持的高级特性： ...

ZooKeeper 节点类型 ZooKeeper 的节点（ZNode）类型是两个维度的组合： 生命周期维度： 持久（Persistent）：客户端断开后节点依然存在，需要显式删除 临时（Ephemeral）：与创建它的客户端 Session 绑定，Session 结束节点自动删除 命名维度： 普通：你指定什么路径就创建什么路径，路径已存在则报错 顺序（Sequential）：路径作为前缀，ZooKeeper 自动追加 10 位单调递增序号 两两组合，实际有四种节点类型： 类型 说明 持久节点 最普通的节点，手动删除才消失 持久顺序节点 名称自动追加递增序号，永久存在 临时节点 Session 结束自动删除 临时顺序节点 Session 结束自动删除 + 名称追加序号 各场景适用类型： 场景 用哪种 分布式锁（抢占式） 普通临时节点，谁先创建谁得锁 分布式锁（公平排队） 顺序临时节点，序号最小的得锁 Leader 选举 顺序临时节点，序号最小的是 leader 配置中心、服务注册 普通持久节点 临时节点原理 ZooKeeper 客户端连接服务端后会建立一个 Session，并维持心跳（默认每隔 tickTime 发一次）。服务端为每个 Session 设置超时时间（sessionTimeout），超时内未收到心跳则判定 Session 过期，自动删除该 Session 创建的所有临时节点，其他 watch 了这些节点的客户端会收到删除通知。 状态 临时节点是否消失 网络抖动（短暂断开） 不消失，等待重连，Session 未过期 断开超过 sessionTimeout 消失，Session 过期 客户端主动 close() 立即消失 临时节点不能有子节点，因为它的生命周期是不确定的。 ...

微服务 微服务是一种分布式系统解决方案。 微服务 (Microservices) 就是一些协同工作小而自治的服务。 2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现 。 微服务与SOA 「面向服务的体系结构」 SOA (Service-Oriented Architecture) 听起来和微服务很像,但 SOA 早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如: J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间,最终 SOA 看起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。 此外,实施SOA时会遇到很多问题,比如通信协议 (例如SOAP)的选择、第三方中间件如何选择、服务粒度如何确定等,目前也存在一些关于如何划分系统的指导性原则,但其中有很多都是错误的。SOA并没有告诉你如何划分单体应用成微服务,所以在实施SOA时会遇到很多问题。 这些问题再微服务框架中得到很好的解决,你可以认为微服务架构是SOA的一种特定方法。 分布式系统 什么是分布式系统 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。 首先需要明确的是,只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候,且硬件的提升 (加内存、加磁盘、使用更好的CPU) 高昂到得不偿失的时候,应用程序也不能进一步优化的时候,我们才需要考虑分布式系统。因为,分布式系统要解决的问题本身就是和单机系统一样的,而由于分布式系统多节点、通过网络通信的拓扑结构,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的机制、协议,带来更多的问题。 “什么是分布式系统？这取决于看系统的角度。对于坐在键盘前使用IBM个人电脑的人来说,电脑不是一个分布式的系统。但对于在电脑主板上趴着的虫子来说,这台电脑就是一个分布式系统。” —— Leslie Lamport 复杂性 流量管理 (Traffic management) : 超时、重试、负载均衡； 安全性 (Security) : 终端用户的认证和授权； 可观察性 (Observability) : 跟踪、监控和日志。 私有数据的所有权 当多个服务直接读写数据库中同一张表时,对这些表做任何改动都需要协调这些相关服务的部署。这一点违背了服务相互独立这一原则。共享的数据存储很容易不经意间造成耦合。每个服务需要有自己的私有数据。 私有数据还能提供另一个优势: 根据服务的具体用例选择最适合的数据库技术。 每个服务都要有自己的数据服务器吗？ 不一定。每个服务需要自己的数据库,但这些数据库可共置在一台共享的数据服务器上。重点在于不应让服务知道其他服务底层数据库的存在。这样即可用一台共享数据服务器先开始开发,以后只要更改配置即可将不同服务的数据库隔离起来。 然而共享的数据服务器也可能造成一些问题。首先会形成单点故障,进而导致一大批服务同时故障,这一点绝不能掉以轻心。其次很可能因为一个服务占用太多资源而无意中对其他服务造成影响。 确定服务的边界 这个问题很复杂。每个服务应该是一种能提供某些业务能力的自治单位。 服务应当弱耦合在一起,对其他服务的依赖应尽可能低。一个服务与其他服务的任何通信都应通过公开暴露的接口 (API、事件等) 实现,这些接口需要妥善设计以隐藏内部细节。 服务应具备高内聚力。密切相关的多个功能应尽量包含在同一个服务中,这样可将服务之间的干扰降至最低。 服务应包含单一的界限上下文。界限上下文 (Bounded context) 可将某一领域的内部细节,包括该领域特定的模块封装在一起。 ...

Tekton 什么是 Tekton Tekton（发音：/ˈtɛktɒn/，“TEK-ton”）名称来自希腊语 τέκτων，意为"建造者"。 Tekton 是一个开源的云原生 CI/CD 框架，运行在 Kubernetes 上，通过 CRD（自定义资源定义）的方式定义流水线。它是强制 Kubernetes 原生的，所有流水线组件都以 Pod 方式运行，没有其他执行模式。 与 Jenkins、GitLab CI 等工具不同，Tekton 从设计之初就只能运行在 Kubernetes 上，而不是"可选支持 K8s"。这是架构层面的硬性约束，带来的好处是与 K8s 生态深度集成，代价是强依赖 K8s 环境。 Tekton 是 CD Foundation 旗下项目，前身是 Knative 的 Build 模块。 核心概念 Step（步骤） 流水线中的最小执行单元，对应容器中的一条命令。 Task（任务） 由一组有序的 Step 组成，运行在同一个 Pod 中，Steps 共享存储卷。 apiVersion: tekton.dev/v1 kind: Task metadata: name: build-and-push spec: params: - name: image type: string steps: - name: build image: gcr.io/kaniko-project/executor:latest args: - "--dockerfile=$(workspaces.source.path)/Dockerfile" - "--context=$(workspaces.source.path)" - "--destination=$(params.image)" workspaces: - name: source Pipeline（流水线） 由多个 Task 按顺序或并行组成，定义完整的 CI/CD 工作流。 ...

containerd containerd: 2.2.0-1 runc: 1.4.0-1 nerdctl: 2.2.0-1 cni-plugins: 1.9.0-1 archlinux install containerd # archlinux install containerd pacman -S containerd runc nerdctl cni-plugins # containerd config sudo mkdir /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo systemctl daemon-reload sudo systemctl enable --now containerd # containerd 内存占用 47MB # containerd、runc、nerdctl 都是用户空间的程序, 不是内核模块，不需要重新加载内核, 不需要重启系统, 只需要运行守护进程即可, 安装完成就可以使用 sudo nerdctl pull hello-world sudo nerdctl run --rm hello-world # 如果需要编译镜像 sudo pacman -S buildkit sudo systemctl enable --now buildkit # build image, 需要在有 Dockerfile 的目录下运行 nerdctl build -t foo:v1.0.0 . sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml sudo systemctl restart containerd ubuntu install containerd https://gist.github.com/Faheetah/4baf1e413691bc4e7784fad16d6275a9 https://www.techrepublic.com/article/install-containerd-ubuntu/ ...

macos container Apple 官方的容器化工具，专为 Apple Silicon Mac 设计，使用轻量级虚拟机运行 Linux 容器。 系统要求 Apple Silicon Mac (M 系列芯片) macOS 26 或更高版本 Xcode (从 App Store 安装) 安装 # 使用 Homebrew Cask 安装 brew install --cask container # 启动 container 系统服务 container system start # 检查系统状态 container system status # 运行测试容器 container run --rm -it docker.io/library/hello-world:latest # 列出容器 (注意: 使用 ls 而不是 ps) container ls # 查看所有可用命令 container --help 从源码编译 git clone https://github.com/apple/container.git cd container swift build sudo cp .build/debug/container /usr/local/bin/container

podman basic install https://podman.io/getting-started/installation # archlinux install podman pacman -S podman # 提示选择 crun, runc, 选 crun # netavark aardvark-dns 会默认安装 # 正常情况，安装 podman 之后不需要重启系统, 但是如果有异常，比如 CNI 之类 的问题，可以考虑重启一下... Netavark Netavark 是一个 用 rust 实现的 配置 linux 容器网络的工具。 In addition to the existing CNI Out of the stack, Podman Now it also supports based on Netavark and Aardvark New network stack. The new stack features improved support for containers in multiple networks 、 improvement IPv6 Support, And improve performance. To ensure that there is no impact on existing users, used CNI The stack will keep the default value of the existing installation, The new installation will use Netvark. ...