微服务的核心组件
1. 服务注册与发现（Service Registry & Discovery）
服务实例动态启停、扩缩容，调用方不可能硬编码 IP。注册中心负责让服务"上线时登记、下线时注销"，调用方按服务名查询可用实例。常见实现有 Consul、Nacos、etcd，以及 Go 生态里 go-micro、kratos 的内置方案。
2. 配置中心（Config Center）
把数据库连接、限流阈值、开关等配置从代码里抽离，支持动态下发和热更新。常见有 Nacos、Apollo、etcd。否则改一个配置就要重新部署所有实例。
3. API 网关（API Gateway）
系统的统一入口，承担路由转发、鉴权、限流熔断、协议转换、聚合等职责。常见有 Kong、APISIX、Spring Cloud Gateway，Go 里也常用自研网关或 APISIX。
4. 服务间通信（RPC / 消息）
同步调用一般用 gRPC 或 HTTP；异步解耦用消息队列 Kafka/RabbitMQ
5. 负载均衡（Load Balancing）
分客户端负载均衡（如 gRPC 内置的 round-robin、一致性哈希）和服务端负载均衡（网关/Nginx 层）。微服务多用客户端负载均衡配合注册中心。
6. 熔断、限流、降级（Resilience）
防止级联雪崩。熔断器（如 Sentinel、Hystrix 思路、Go 的 sony/gobreaker）、限流（令牌桶/漏桶）、降级兜底。
7. 分布式链路追踪与可观测性（Observability）
包含三大支柱：链路追踪（Jaeger、Zipkin、OpenTelemetry）、指标监控（Prometheus + Grafana）、日志聚合（ELK、Loki）。一个请求跨多个服务，没有 TraceID 串联根本没法排查。
8. 分布式事务（Distributed Transaction）
跨服务的数据一致性。常见方案有 Saga、TCC、本地消息表 / 事务性发件箱（你已经实践过 Outbox 模式），以及 Seata 等框架。
9. 容器编排与部署（Orchestration）
Docker + Kubernetes 负责服务的部署、调度、自愈、滚动更新。Service Mesh（Istio、Linkerd）则把治理能力下沉到 Sidecar，让业务代码更纯粹。
通信 + 注册发现 + 配置 + 网关 + 容错 + 可观测 + 部署，就是微服务跑起来的骨架。
微服务划分的依据
业务领域驱动（DDD，最核心的依据）
按**限界上下文（Bounded Context）**划分。识别业务中的领域和子域，每个高内聚的业务能力对应一个服务。比如 IM 系统可以拆成：用户/账号服务、消息服务、好友关系服务、音视频信令服务、推送通知服务。这是目前最被推崇的方法论——拆分边界跟着业务语义走，而不是技术层次。
单一职责与高内聚低耦合
每个服务只做一件事并做好。判断标准：服务内部的变更原因应该单一。如果两个功能总是一起改、一起发布，说明它们其实属于同一个服务，不该拆开。