3. 服务目录概述
3.1 服务目录的定义
服务目录(Service Catalog)是微服务架构中的核心元数据管理中心,它维护了所有已注册服务的实例信息、接口契约、健康状态以及依赖关系。在蓝绿发布场景中,服务目录充当了流量路由的“交换机”——只有通过门禁验证的服务实例才会被标记为“可接入”,从而被目录推送到网关或负载均衡器。
关键定义:服务目录 = 服务注册表 + 健康检查引擎 + 元数据仓库。它不处理业务请求,但决定了请求能到达哪些服务实例。
3.2 核心功能
| 功能模块 | 职责描述 | 蓝绿发布中的关键作用 |
|---|---|---|
| 服务注册 | 服务实例启动时向目录上报 IP、端口、版本、协议、健康检查端点等信息 | 蓝组/绿组实例上线时自动注册,门禁通过后标记为“就绪” |
| 服务发现 | 消费者或网关通过目录获取目标服务的可用实例列表,支持轮询/加权/一致性哈希等策略 | 门禁未通过时,目录不返回该版本实例;通过后立即加入路由池 |
| 健康检查 | 定期探测服务实例的存活状态(TCP/HTTP/gRPC),自动摘除异常实例 | 蓝绿发布期间,健康检查与门禁联动,防止流量进入未就绪实例 |
| 元数据管理 | 存储版本标签、部署时间、灰度比例、环境标识等扩展属性 | 门禁规则依赖元数据(如 version=2.0.1-blue)做流量筛选 |
实践建议:在蓝绿发布门禁中,服务目录的元数据字段应至少包含
deploy.group(蓝/绿)、deploy.status(init/ready/draining)、gate.passed(true/false)三个标签,便于自动化门禁系统快速决策。
3.3 在微服务架构中的位置
服务目录位于基础设施层与业务服务层之间,是服务间通信的“交通指挥中心”。下图展示了服务目录在典型微服务架构中的核心位置及其与蓝绿发布门禁的交互关系。
3.4 服务目录与蓝绿发布门禁的协作流程
- 实例注册:蓝组/绿组服务启动后,向服务目录发送注册请求,携带
deploy.group、version、health.endpoint等元数据。 - 初始标记:服务目录将新实例的
gate.passed默认设为false,deploy.status设为init,此时网关不会路由流量到该实例。 - 门禁验证:门禁系统从服务目录拉取待验证实例列表,执行测试用例(冒烟、集成、性能、安全扫描)。
- 状态更新:门禁通过后,调用服务目录 API 将
gate.passed更新为true,deploy.status更新为ready。 - 流量切换:网关通过服务发现获取最新实例列表,仅返回
gate.passed=true的实例,完成蓝绿切换。
常见陷阱:服务目录的健康检查与门禁检查不能混为一谈。健康检查只验证进程是否存活(Liveness),门禁检查验证业务功能是否正确(Readiness + 业务正确性)。蓝绿发布必须依赖门禁标记,而非仅靠健康检查。
3.5 主流服务目录实现对比
| 实现方案 | 注册方式 | 健康检查机制 | 元数据扩展性 | 蓝绿门禁适配 |
|---|---|---|---|---|
| Consul | HTTP/gRPC 注册 | TTL + 主动探测 | 支持 Key-Value 元数据 | 通过 Service Meta 标记门禁状态 |
| Eureka | REST 心跳注册 | 心跳超时摘除 | 元数据字段有限 | 需配合自定义健康检查端点 |
| Nacos | HTTP/gRPC 注册 | 主动探测 + 心跳 | 支持扩展元数据 + 配置中心 | 原生支持权重路由,适合蓝绿 |
| Kubernetes Service | API Server 注册 | Readiness Probe | Label/Annotation 丰富 | 通过 Label Selector 实现蓝绿隔离 |
选型建议:如果团队已有 Kubernetes 基础设施,优先使用原生 Service + EndpointSlice + Readiness Probe 实现蓝绿门禁;若需要跨集群或混合云部署,Consul 或 Nacos 的元数据扩展性更适合复杂门禁规则。