单体架构的缺点：
代码越来越多
部署风险大
项目扩展能力差
技术栈受限
什么是微服务架构？
在传统的单体架构中，一个应用程序的所有功能模块都打包在同一个代码库中，部署在同一个运行环境中。而微服务架构是将一个大型应用拆分成多个小型服务，每个服务独立开发、独立部署、独立运行的架构风格。每个服务围绕特定的业务能力构建，运行在独立的进程中，并采用轻量级的通信机制（HTTP RESTful API 或 RPC）进行交互。
微服务架构的核心特征
单一职责：每个微服务只专注于做好一件事；例如：订单服务只处理与订单相关的业务逻辑。
团队自治：不同的微服务可以由不同的团队独立开发、测试、部署和维护。
技术栈多样性：不同的服务可以根据需求选择最适合的技术栈。例如，订单服务可以用 Java 编写并使用 MySQL，而推荐系统可以用 Python 编写并使用 MongoDB。
独立部署：任何一个微服务的修改和更新都可以独立部署，而不需要重新打包和部署整个系统。
去中心化数据管理：每个微服务通常拥有自己独立的数据库，避免了单体架构中的数据库共享和强耦合。
微服务架构的核心组件
微服务最重要的是如何让多个独立的微服务协同工作，因此需要以下核心组件的支持：
服务注册发现
由于微服务实例的数量和 IP 地址可能会动态变化，服务之间不能写死调用地址。服务注册中心（如 Consul, Eureka, Nacos）负责记录所有可用服务的实例信息。服务调用方通过注册中心查找目标服务的地址，从而实现动态调用。
网关
网关是系统的唯一入口。它封装了系统内部架构，为前端客户端提供统一的 API。网关负责路由转发、权限认证、限流熔断、日志监控、协议转换。常见的网关Spring Cloud Gateway, Kong, Zuul。
配置中心
在微服务环境中，环境配置散落在各个服务中会极难管理。配置中心（如 Spring Cloud Config, Apollo, Nacos）实现了配置的集中式管理和动态刷新。
负载均衡
当某个服务有多个实例运行来应对高并发时，负载均衡（如 Ribbon, Ingress）负责将请求合理地分发到各个实例上。
熔断器与降级
在分布式系统中，服务间调用错综复杂，某个服务不可用可能会导致雪崩效应。熔断器（如 Sentinel, Resilience4j）能在下游服务发生故障时及时切断调用，并提供备用方案（降级），保证核心业务不崩溃。
服务间通信
微服务之间不能像单体应用那样通过内存方法直接调用，必须通过网络进行跨进程通信。
HTTP RESTful API：基于标准的 HTTP 协议，使用 JSON 或 XML 传输数据。跨平台、文本可读性好、门槛低。
RPC（远程过程调用）：像调用本地方法一样调用远程服务。通常基于 TCP 协议，采用二进制序列化（如 Protobuf），性能极高、延迟低。常用的框架是 Dubbo。适合内部微服务之间的高并发、高性能通信。
链路追踪
在微服务架构中，一个用户请求可能需要经过多个服务；如果请求变慢或报错，排查问题会极其痛苦，你不知道请求卡在了哪个服务，也不知道是哪台机器出了问题。链路追踪通常遵循 OpenTelemetry规范，包含两个核心概念：
Trace（追踪）：代表一个完整的请求链路。一个 Trace 由一个唯一的 Trace ID 标识，贯穿请求涉及的所有微服务。
Span（跨度）：代表链路中的一个独立工作单元（例如：一次 RPC 调用、一次数据库查询）。每个 Span 包含 Span ID、开始时间、结束时间、状态以及父 Span ID。通过父子关系，Span 可以组合成一棵调用树。
常见链路追踪组件
SkyWalking：针对 Java 等语言支持非侵入式的字节码注入，不需要修改任何业务代码即可实现链路追踪。同时支持性能指标监控。
Zipkin：开源的经典链路追踪系统，轻量、成熟。但是代码侵入性较强，通常需要引入 SDK 并修改代码配置。
Jaeger：CNCF（云原生计算基金会）托管的开源项目，由 Uber 开源。完美适配 Kubernetes 和云原生生态，使用 Go 语言编写，性能极佳。
好了，微服务相关的内容今天就分享到这里！