标签拓扑

共 22 个标签、22 篇带标签内容。节点大小 ∝ 内容数，虚线为标签共现关系。

笔记 v0.1• 2026-08-30

#dubbo

Dubbo3 应用级服务发现的取舍

Dubbo3 把接口级发现改成应用级（服务自省），本质是用元数据中心换注册中心的压力：注册数据量从 O(接口数) 降到 O(应用数)。

MetadataService.java java

// 应用级发现的关键：Provider 暴露 MetadataService，
// Consumer 先查元数据再建立订阅
ServiceInstancesChangedListener listener =
    serviceDiscovery.createListener(serviceNames);

疑问还没想清楚：元数据版本冲突时 Consumer 的回退策略，在规模上去之后会不会成为新瓶颈。

tagdubbo tag服务发现

双向引用: [[Nacos 服务发现的数据模型速记]] [[Nacos 服务发现的数据模型速记]]

笔记 v0.3• 2026-08-25

#nacos

Nacos 服务发现的数据模型速记

Nacos Naming 的核心数据模型是三层：Service → Cluster → Instance。临时实例走 Distro 协议（AP，节点间分片负责 + 异步同步），持久实例走 Raft（CP）。

判断一个实例是临时还是持久，看 ephemeral 字段；1.x 时代默认临时，2.x grpc 长连接下沉后这个语义没变，只是传输层换了。

待验证：Distro 协议在网络分区恢复后的数据校验轮次，是否能解释我们线上那次「实例列表抖动」。

tagnacos tag服务发现

双向引用: [[Dubbo3 应用级服务发现的取舍]] [[Dubbo3 应用级服务发现的取舍]]

笔记 v1.2• 2026-08-15

#grpc

gRPC 拦截器链与 Context 传递

gRPC 的拦截器（Interceptor）是 AOP 思想的典型应用：客户端/服务端各一条链，按注册顺序嵌套执行。

客户端拦截器适合做：鉴权头注入、调用埋点、重试包装
服务端拦截器适合做：统一异常翻译、限流、审计日志
Context 通过 Contexts.interceptCall 显式传递，异步回调里记得 attach，否则 trace 会断

这条结论在项目里验证过多次，标记为常青。

taggrpc tag微服务

summary 2023-10-29 · 约 1 分钟

临近双十一，集团已经开始陆陆续续的封网，没有大的需求，都是些零零散散的需求在推进，整个人比较轻松。正好自己负责的系统有些历史架构问题可以在这个时候开始做起来了。系统冗余了一份商货关系数据（商品和货品的绑定关系），当然这个份数据是个大宽表，除了绑定关系之外还冗余了商品 SKU 的一些信息供展示和搜索。 DB 的数据量级在1000W+（单表），但是最近业务数据增长的有点快，数据量级很快超过了2000W+，DB搜索的性能已经比较低了，很多走索引的查询也要100ms以上。长期来看肯定要迁移数据，切换到分表。但是业务数据还在不停的增长，因此我的方案是先切换搜索引擎，解决DB查询慢的问题，然后后面找机会再进行分表的切换。背景其实在阿里内部使用搜索有两种备选方案。一种是使用 OpenSearch。好处是，运维简单、开发起来也很方便。但是功能有些限制，比如：最大分页数不能超过 5000。另一种是自建 HA3（openSearch 本质上是在 HA3 的基础上做了一个通用的解决方案，做了很多限制），这个需要人工去运维 HA3 服务，多了些理解、运维的成本，但好处是自由度很高。由于我这个搜索并不需要很多的定制化搜索的能力，因此我用的是 OpenSearch 这套方案。所以接下来的事情就简单多了，直接把 DB 的数据导入到 OpenSearch，然后创建好索引，那就已经完成了搜索引擎的搭建，接下来就是使用 SDK 了，具体细节就不讲了，应该只花了一个星期不到就完成了搜索的切换。（只需要做两件事一是把请求入参转换成 OpeanSearch 的语法，二是把搜索的结果转换成原来的数据对象）当时没有测试资源，我自己测了一个两天，把原来接口的入参都一个个的试了一遍，确保字段都能进行有效的搜索之后，就上线了。当然，为了避免出现问题之后能即使止血，我加了个开关。发布的时候也灰度了5个小时，当然这些并不能避免问题，只是希望出现问题之后能即使止血，及时发现。问题按理说我加了止血方案，同时又灰度了5小时，应该没大问题。但是很不幸，我唯独评估漏了一个项，线上 OpenSearch 所需要的资源。这就导致我的 OpenSearch 搜索服务被限流了。（OpenSearch 有 LCU 的限制，如果 LCU 超了申请时候的配额会引发查询限流）。虽然上游重试下就可以解决这个问题，但是因为临近双十一，大家都希望系统稳定点，所以直接跟老板反馈了。。复盘从表面上看这个是一个很小的问题，查询限流是很常见的事情。但是回顾自己整个迁移的方案，我发现自己漏了两项。一是没有梳理上游依赖这个接口的场景，因为这个接口之前直接查的 DB，之前不会限流迁移之后会限流。所以，如果上游根本没有重试的机制，那会导致上游业务处理失败。这次还好可以让上游手动重试，万一上游还没法手动重试，那只能去订正数据了。二是根本没有做压测和资源评估这件事，当然这跟我不熟悉 OpenSearch 有关，但是压测这事儿是很大的疏漏，因为我的自测只是保障了接口功能上的正常，却忘掉了真实场景下会有突发流量的问题。总结所以我总结总结了下，做迁移还是有些原则性的东西需要去做，否则方案就不完整。上下游依赖梳理。需要弄清楚影响范围，这样可以在上线前做好相应的预案，上线时出了问题也能及时找到相应的人处理。资源评估。系统依赖的中间件需要哪些资源，比如：CPU、磁盘这些东西，最好有个量化的指标，这样也便于去申请。保证功能完整。迁移前后的功能一定是要保证一致的，这只最重要得一个大前提。压测模拟。因为在小流量和大流量的场景下需要保障的东西完全不同，最常见的就是接口限流，RT变高等问题这些情况都是在小流量场景下没法复现的。流量可监控。整个发布过程中我都是被动的等待问题出现，在迁移的过程中一定要有一些接口级别的异常监控，能帮我们主动发现问题。