2. 服务目录平台架构解析：核心组件介绍、数据流与请求链路、配置中心与注册中心的作用、平台高可用设计原则

服务目录平台作为企业级微服务治理的“元数据中心”，其架构由以下核心组件构成，各组件职责清晰、松耦合协作。

组件名称	核心职责	技术选型参考
API Gateway	统一入口、路由转发、身份认证、限流熔断	Kong / APISIX / Spring Cloud Gateway
Catalog Core	服务元数据管理、版本控制、依赖关系图谱	Spring Boot + JPA / MyBatis
Metadata Store	持久化存储服务定义、接口契约、标签、Owner 信息	PostgreSQL / MySQL + Redis 缓存
Sync Worker	定时或事件驱动同步注册中心、CMDB、监控系统的数据	Celery / Quartz / K8s CronJob
Event Bus	服务变更事件发布与订阅，驱动下游消费	Kafka / Pulsar / RabbitMQ
Config Center	平台自身及接入服务的动态配置管理	Nacos / Apollo / etcd
Registry Adapter	对接不同注册中心（Nacos、Eureka、Consul、K8s Service）	适配器模式 + 插件化 SPI

架构要点：Catalog Core 是平台唯一“写”入口，所有元数据变更必须经过校验与事件发布，避免数据不一致。Sync Worker 只负责“读”外部系统并转换为平台内部模型，不反向写入注册中心。

一次完整的服务查询或变更请求，在平台内部经过以下关键路径。以“开发者查询服务 A 的依赖关系”为例：

配置中心和注册中心是服务目录平台的两大基础设施依赖，二者职责不同但协同工作。

维度	配置中心（Config Center）	注册中心（Registry Center）
管理对象	平台及服务的运行时配置（数据库连接、开关、阈值）	服务实例的网络地址、健康状态、元数据
数据模型	Key-Value / 配置文件 / 命名空间	服务名 → 实例列表（IP:Port + 标签）
变更频率	低～中（按需调整）	高（实例扩缩容、滚动更新、故障剔除）
一致性要求	最终一致性 + 实时推送	强一致性（AP 或 CP 取决于选型）
典型产品	Nacos Config / Apollo / etcd	Nacos Discovery / Eureka / Consul / K8s Service
在平台中的角色	存储 Catalog Core 的动态开关、数据源配置、限流参数	提供实时服务实例列表，供 Catalog Core 健康探测与依赖分析

实践建议：配置中心与注册中心应独立部署，避免互相影响。推荐使用 Nacos 同时承担两个角色以降低运维复杂度，但生产环境建议将 Config 与 Discovery 拆为独立集群，防止配置变更风暴影响服务发现。

服务目录平台作为企业服务治理的“控制面”，其可用性直接影响整个微服务体系的运维效率。高可用设计遵循以下原则：

无状态化：Catalog Core、API Gateway、Sync Worker 均设计为无状态节点，通过负载均衡器分发流量，任意节点故障不影响整体服务。
数据冗余：Metadata Store 采用主从复制或分布式数据库（如 PostgreSQL 流复制、MySQL Group Replication），确保单点故障不丢数据。
缓存保护：Redis 缓存采用 Sentinel 或 Cluster 模式，缓存失效时通过“互斥锁 + 回源限流”防止缓存雪崩。
异步解耦：Event Bus 使用 Kafka 或 Pulsar 等持久化消息队列，确保事件不丢失；消费者支持幂等处理。
多活部署：关键组件跨可用区部署，DNS 或全局负载均衡器实现流量切换，RTO < 60s，RPO ≈ 0。
优雅降级：当注册中心或配置中心不可用时，Catalog Core 使用本地缓存快照继续提供只读服务，待恢复后自动同步。

避坑提醒：不要将所有组件部署在同一个可用区。即使有负载均衡，单可用区故障仍会导致全平台不可用。另外，Redis 缓存必须配置持久化（RDB + AOF），否则重启后缓存雪崩可能压垮数据库。