系统架构设计（九）：分布式架构与微服务
基础定义
| 架构类型 | 定义 |
|---|---|
| 分布式架构 | 指将系统部署在多个服务器节点上，通过网络协作完成整体功能。强调物理上的分布与任务协作。 |
| 微服务架构 | 一种分布式架构模式，将系统按照业务维度拆分为多个小型自治服务，每个服务可独立开发、部署、伸缩。 |
核心区别与联系
| 维度 | 微服务架构 | 分布式架构 |
|---|---|---|
| 架构本质 | 构建在分布式基础上的一种架构风格 | 更广义，包含微服务、集群、负载均衡 |
| 拆分粒度 | 服务级别（一个服务一个职责） | 模块或系统级别 |
| 部署方式 | 各服务独立部署、容器化部署 | 可能集中，也可能分散部署 |
| 通信方式 | 主要使用 HTTP/REST、gRPC、MQ | 包括 RPC、远程对象、文件共享等 |
| 数据管理 | 每个服务有独立数据库 | 多个系统可能共享数据库 |
| 开发组织 | 按服务划分开发团队，DevOps 支持明显 | 通常按功能或层次划分 |
| 技术异构支持 | 高（服务间可使用不同语言/技术） | 相对低 |
| 运维复杂度 | 高，需配合服务治理、注册中心、网关等 | 中等，需要配置负载均衡、同步机制 |
联系总结：微服务架构是分布式架构的一种具体实现方式。
微服务架构设计要点
- 服务拆分：按业务边界拆分为独立微服务（如订单服务、库存服务、用户服务）；
- 独立部署：每个服务可独立构建、部署、扩展、维护；
- 服务注册与发现：使用如 Nacos、Consul、Eureka 进行服务注册与自动发现；
- API 网关：统一入口，处理鉴权、路由、限流等（如使用 Kong、Zuul）；
- 服务通信：采用 RESTful API、gRPC、消息队列（如 Kafka、RabbitMQ）等；
- 容错机制：使用断路器、重试、熔断（如 Hystrix、Resilience4j）；
- 监控与日志：实现链路追踪（如 Skywalking、Zipkin）、统一日志、指标监控；
- 数据库隔离：每个服务拥有自己的数据库，避免强耦合；
- 配置管理：支持集中配置，如使用 Spring Cloud Config、Nacos 配置中心。
示例
请说明某企业大型业务系统如何基于微服务架构进行设计，并说明其优缺点。
架构设计概述：
- 系统采用微服务架构，将单体系统划分为多个按业务划分的微服务，如：用户服务、订单服务、库存服务等；
- 每个服务由独立的开发团队负责，具备独立的部署与生命周期管理能力；
- 服务间通过 REST API 或消息队列进行通信，提升服务解耦性和系统弹性。
技术组件选型：
- 注册中心：使用 Nacos/Eureka 实现服务注册与发现；
- 网关：使用 Spring Cloud Gateway 统一对外暴露接口；
- 配置中心：集中式配置管理（如 Nacos、Apollo）；
- 数据库管理：每个服务使用独立数据库，避免耦合；
- 弹性设计：采用断路器、限流、服务降级机制（如 Hystrix）；
- 日志与监控：使用 ELK、Prometheus + Grafana 进行系统观测。
优势分析：
- 系统模块化，易于扩展；
- 各服务独立部署与升级，提升开发效率；
- 服务自治，提高系统健壮性与容错性；
- 支持不同语言和技术，利于团队选择合适工具。
挑战与应对：
- 运维复杂度高：引入 DevOps 工具链（如 Docker、K8s）；
- 数据一致性问题：采用最终一致性策略（如事务消息）；
- 服务调用链复杂：使用链路追踪系统进行监控。