守株阁

允许 TCP 为什么还可能拒绝报价 orders → inventory-v1 的 GET /quote?sku=paper 在四层被放行，不表示同一连接上的每个 HTTP 路径都获准。把 eBPF、相互认证和 mTLS 写成一个开关，会在排障时误把 L7 拒绝认作内核断网。按 Cilium 1.18 文档选择能力边界（2026-10-03 核验，网页实际标识 1.18.14）；相互认证页面明确标为 Beta。这是候选文档基线，当前没有部署 Cilium，功能开关与内核/发行版兼容须在安装时再次核对；源码固定 v1.18.0 tag，不将文档补丁版本和源码标签混作同一构建。 图中的数据方向是 orders → 内核策略/转发 →（需要 L7 时）Envoy → inventory。返回值在反方向返回；源 identity、策略命中和代理是否真的收到请求各自需要证据。无 L7 规则时不能假定这个 HTTP 请求一定经过 Envoy。inventory 不调用 external-stub，它的只读报价也不产生合成 POST /reserve 账本条目。 四件事在四个位置 eBPF ...

同一报价，为何换一个客户端就不遵守路由 主线第 07 篇用独立 Envoy 讨论 LDS/RDS/CDS/EDS 的依赖。将 orders → inventory 的报价做成真正的 gRPC Quote unary 方法，让 Go grpc-go v1.76.0 客户端经 xDS resolver 发现后端：路由和负载均衡的部分决策进入应用进程。如果另一个 HTTP 客户端仍直连当前工程的 /quote，它不会因同机运行了 Go SDK 而接受 xDS 配置。本例使用独立 Go 模块固定该版本，与累计 HTTP 工程分开运行。 图的上行是资源分发及反馈，下行是报价请求；控制面不转发每笔订单。客户端以 bootstrap 知道 xDS 服务、使用 xds:///... target，通过 xDS Client 将受支持的 listener、route、cluster、endpoint 映射到 gRPC channel 的服务配置、路由和连接选择。按 gRPC 官方 xDS 功能矩阵，Go 客户端从 v1.30.0 支持 LDS→RDS→CDS→EDS 与 ADS，v1.31.0 ...

库存在集群外，orders 找到的到底是谁 同一个 orders → inventory 报价，如果库存从 Kubernetes Pod 迁到独立虚拟机，应用的 URL 不一定需要变，但服务发现必须把 VM 地址纳入目标集合，且 VM 上的数据面要拿到可信身份。把一个普通 Pod 标注 vm=true，依然是 Pod、Kubernetes 身份与 Pod 网络，并没有验证跨边界注册。本文以 Istio 1.27 文档快照设计双端点用例；并未在当前机器安装 Istio。 图上 orders → 源代理 →（视网络拓扑经网关）→ VM 代理 → inventory 是数据通道；Istiod → VM 的注册发现与证书/配置是独立的启动依赖。若 VM 在同网络且直接可达，不应无证据地画成必经东西向网关。反过来，仅在控制面看到 WorkloadEntry，也不能证明真实入口端口/防火墙可达。相关基础见 19 身份、29 控制面失效 和 32 多集群。 谁注册，谁发证，谁连接 VM 启动和接收请求之间存在依赖，不是一个“已注册”布尔值： 12WorkloadEntry/服务发现 ──→ ...

一次报价该在哪一层检查租户 同一个 orders → inventory-v1 的 GET /quote?sku=paper，假设实验需要仅 x-tenant: lab 可访问。把租户判断塞进每个库存副本，会让规则变更与应用发布耦合；把检查放进代理又必须说明请求的身份来源、超时以及授权服务不可用时如何处理。本文选择 Envoy HTTP ext_authz，只解决这一个检查需求；x-tenant 在本例只是合成输入，不是可信身份，真实租户属性必须绑定到已认证来源且过滤不可由外部随意伪造的头。 图中外部授权是 Envoy HTTP 过滤链里的一步。LDS 中 listener 使用 HTTP connection manager，过滤器按次序调用授权服务；允许才继续到 router 的 RDS/CDS/EDS 路径（先修 03 Envoy）。控制面能部署规则，但“ext_authz 已加载”不等于目标请求确实经过这个 listener；负例必须在库存应用日志中找不到相同请求 ID。 扩展机制并非一种执行环境 Envoy 自带的 HTTP/network filter、Lua、Wa...

两个代理都说“还剩一个名额” 前端的两个副本各有代理，两个 orders → inventory-v1 的只读 GET /quote?sku=paper 同时到达。若每个代理各维护“每秒 5 个”的局部桶，它们没有共享计数器：在同一计数窗口的理想示意中，两个满桶最多可各准入 5 个，合起来 10 个，而不是整个库存服务的 5 个。这里的 5、10 都是说明模型的假设值，绝非实测：窗口起点、token refill、路由偏斜、并发和实例动态扩缩会改变实际数量。 图分为两种模型：本地模式的两个桶各自连接库存；全局模式的两个代理向同一 RLS 查询。若要为同一租户设置全局配额，两代理须使用一致的 descriptor 向外部限额服务请求，由限额服务返回允许或超限。Envoy 的 global rate limit filter 发送请求并执行响应，但整个系统能否严格保持限额取决于限额服务实现、缓存、故障配置和存储，而不是 filter 的名字。单代理可能有多个 worker，不同配置的 token bucket 范围也不同，需要逐项核对。 突发、排队与故障策略 以纯理论、非测量的同时...

B 集群的库存能接 A 集群的请求吗 在 32 多集群 的 sidecar 基线之外，假设 A 集群运行 orders 与 inventory-v1，B 集群运行 inventory-v2。当 A 本地 v1 不可用，希望 A 的读请求经 B 的 v2 得到报价；如果路由跨越网络却绕过身份检查，返回 200 不是合格恢复。两套库存副本的 POST /reserve 合成账本不会自动同步，读路径恢复也不保证订单一致性。 本文冻结 Istio 1.27.0 文档设计拓扑：当时 ambient 多集群为 alpha，官方不同网络安装指南支持的是 multi-primary；不是任意单主/双网络组合都已支持。图里 A/B 分别有控制面和网络，专用 ambient 东西向网关必须互通；源节点 ztunnel 承担入网和 HBONE L4 身份/加密，目标侧路径经远端网关与 ztunnel 到达工作负载。若想按 HTTP 路径作授权，需要目标 Service/workload 正确绑定 waypoint，并核对该版本跨集群时的实际适用范围；ztunnel 本身不解析 /quote。控制面下...

端点换了，监听器为什么还没把请求送过去 独立 Envoy 的静态配置可以把 GET /quote?sku=paper 送到 inventory-v1，但每次换库存地址都要改文件、重载代理，无法看清资源更新过程。教学服务在 examples/service-mesh/cmd/teaching-xds/main.go：用官方 Go go-control-plane v0.13.4 的 SnapshotCache 和 ADS 服务发布一个 listener、一条精确匹配 /quote 的 route、一个 EDS cluster 与一个 endpoint。官方库携带 v3 protobuf（go-control-plane/envoy v1.32.3）；真实 Envoy 1.37.0 已完成本例有限资源的转发、更新、拒绝和重连验证，不据此宣称所有 API 组合都兼容。 图里的资源依赖是 LDS → RDS → CDS → EDS，箭头表示引用或订阅需要，不是四条业务网络跳数。Envoy 读取 deploy/envoy/teaching-xds.yaml 的静态 bootstrap，向...

Git基础.xmind 初始化命令 配置用户、remote 和 branch 12345678910111213141516171819202122232425262728293031323334353637git config --global user.name "magicliang" # 替换为实际用户名git config --global user.email "magicliang@qq.com" # 替换为实际邮箱git config --global push.default simplegit config --global core.autocrlf false # 让Git不要管 Windows/Unix 换行符转换的事git config --global --listssh git@gitlab.abcgit initgit add .git commit -m "First commit"# 对 remote 进行 remove 和 ad...

“个人助理”不是一份由硅谷公司共同签署的技术标准。Google、Microsoft、Meta、OpenAI 使用了 universal assistant、personal agent、personal superintelligence 等不同名称，公开材料也没有给出一条全行业通用的形式化定义。不过，它们在服务关系上已经收敛。系统围绕一个稳定的人组织状态，在这个人的指示和授权下，持续理解目标、调用工具并代表其采取行动。 Personal assistant 的范围更宽：提供建议、提醒或个性化问答也可以叫助理，并不必然代表用户执行。Microsoft 2025 年对 AI Companion 的描述就包含个性化建议、提醒和用户可控记忆。Microsoft AI Companion 为避免把这类产品和长期自主系统混在一起，本文后续的 personal agent 专指“持续型个人代理”，并采用一条可检验的操作性定义： 本文所说的 personal agent，是以一个稳定的人为委托主体，跨会话保存目标、偏好、关系和授权，并能在其指示与边界内，通过工具规划、执行、恢复或主动发起工作...

工程设计巧思：可复用的程序与架构模式 工程设计的难点通常不在于找到某个框架，而在于把本来隐含在口头约定、调用顺序和运维经验里的约束，变成类型、数据约束、状态迁移、接口和可观测证据。设计模式不是可直接粘贴的类图；它是一种把变化压缩到少数边界、让错误尽早暴露的组织方式。 本文把常见的工程问题整理成一组可复用模式。每个模式都给出适用信号、最小实现、边界与迁移方向。重点不在模式名称，而在回答一个问题：当需求变化时，哪一条约束必须继续成立，谁负责守住它。 先画出约束落点 图 1：一条业务规则在类型、存储、状态与运行证据中的落点 flowchart TD R[业务规则] --> I[不变量] I --> T[类型与接口] I --> D[数据库约束与事务] I --> S[状态机与幂等键] I --> O[日志 指标 审计] T --> C[调用方] D --> C S --> C O --> V[故障时可验证] 同一条业务规则往往需要多个落点。例如“订单只能扣减一...