"/>
侧边栏壁纸
博主头像
PySuper 博主等级

千里之行,始于足下

  • 累计撰写 286 篇文章
  • 累计创建 17 个标签
  • 累计收到 2 条评论

目 录CONTENT

文章目录

微服务架构

PySuper
2023-06-18 / 0 评论 / 0 点赞 / 11 阅读 / 0 字
温馨提示:
所有牛逼的人都有一段苦逼的岁月。 但是你只要像SB一样去坚持,终将牛逼!!! ✊✊✊

微服务组件

微服务架构是一个复杂的分布式系统,包含众多协同工作的组件

这些组件共同解决了服务治理、通信、监控、部署等问题。核心组件通常包括:

1. 微服务本身

  • 定义: 独立的、可部署的业务功能单元,拥有自己的技术栈(语言、数据库)、数据模型和生命周期

  • 职责: 实现特定的业务能力(如用户管理、订单处理、支付服务等)

2. 服务发现

  • 定义: 允许微服务在运行时动态地查找和定位其他服务实例的网络位置(IP和端口)的机制

  • 核心组件: 服务注册中心

  • 功能: 服务实例启动时向注册中心注册自己,下线时注销。消费者从注册中心查询所需服务的可用实例列表

  • 常见实现: Netflix Eureka, HashiCorp Consul, Apache Zookeeper, Nacos, etcd

3. API 网关

  • 定义: 系统的单一入口点,所有外部客户端请求首先经过它

  • 职责:

  • 路由: 将请求转发到对应的后端微服务

  • 聚合: 将多个微服务的响应聚合成一个给客户端的响应(减少客户端请求次数)

  • 认证与授权: 统一处理身份验证和权限检查

  • 限流与熔断: 保护后端服务免受过载影响

  • 负载均衡: 在服务实例间分发请求

  • 日志记录与监控: 记录访问日志,提供监控端点

  • SSL 终止: 处理 HTTPS 解密

  • 请求/响应转换: 修改请求头、响应格式等

  • 常见实现: Spring Cloud Gateway, Netflix Zuul, Kong, Apigee, AWS API Gateway, Envoy (常作为基础)

4. 配置中心

  • 定义: 集中管理所有微服务的配置信息(数据库连接串、功能开关、超时设置等)

  • 优点: 配置与代码分离,无需重新部署即可动态更新配置,配置版本管理

  • 常见实现: Spring Cloud Config, Consul Key/Value Store, etcd, Nacos, Apollo

5. 客户端负载均衡器

  • 定义: 集成在服务消费者(客户端)内部的组件,负责从服务发现获取的服务实例列表中,选择一个实例来发送请求

  • 策略: 轮询、随机、加权、最少连接数、响应时间最短等

  • 常见实现: Spring Cloud LoadBalancer (替代了 Ribbon), Ribbon (Netflix, 已进入维护模式)

6. 容错处理

  • 定义: 防止因单个服务故障导致整个系统级联崩溃的机制

  • 核心模式/组件:

  • 断路器: 当服务调用失败达到阈值时,快速失败(“打开”断路器),直接返回错误或降级响应,避免资源耗尽。一段时间后尝试“半开”以探测服务是否恢复

  • 回退: 当服务调用失败或断路器打开时,执行备用逻辑(如返回缓存数据、默认值或简化响应),保证用户体验

  • 限流: 控制访问速率,防止服务被突发流量压垮

  • 舱壁隔离: 为不同服务或调用分配独立资源(如线程池),避免一个服务的故障耗尽所有资源影响其他服务

  • 常见实现: Resilience4j, Hystrix (Netflix, 已进入维护模式), Sentinel

7. 消息中间件

  • 定义: 实现微服务间异步通信的核心组件

  • 模式: 发布/订阅、点对点队列

  • 优点: 解耦服务、缓冲流量、提高系统响应性、支持最终一致性事务

  • 常见实现: RabbitMQ, Apache Kafka, Apache ActiveMQ/RocketMQ, AWS SQS/SNS, Google Cloud Pub/Sub

8. 分布式追踪

  • 定义: 跟踪一个请求(通常由用户操作触发)在分布式系统中流经多个微服务的完整路径和性能数据

  • 核心组件:

  • 追踪器: 集成到服务中,生成和传播跟踪标识符(Trace ID, Span ID),记录跨度信息

  • 收集器: 接收各个服务上报的跟踪数据

  • 存储: 存储收集到的跟踪数据

  • 可视化 UI: 展示追踪链路、分析性能瓶颈

  • 常见实现: Jaeger, Zipkin, SkyWalking, AWS X-Ray, Google Cloud Trace

9. 集中化日志

  • 定义: 将分散在各个微服务实例上的日志集中收集、存储、索引和分析的平台

  • 核心组件:

  • 日志收集代理: 运行在服务实例上,收集日志文件或流(如 Filebeat, Fluentd, Logstash)

  • 消息队列: 缓冲日志流(如 Kafka)

  • 日志存储与索引: 存储海量日志并提供快速搜索(如 Elasticsearch)

  • 可视化与分析 UI: 查询、分析和展示日志(如 Kibana, Grafana Loki)

  • 常见栈: ELK (Elasticsearch, Logstash, Kibana), EFK (Elasticsearch, Fluentd, Kibana), PLG (Promtail, Loki, Grafana)

10. 指标监控与告警

  • 定义: 收集、聚合和可视化微服务的运行时指标(CPU、内存、请求量、延迟、错误率等),并在异常时触发告警

  • 核心组件:

  • 指标收集器/代理: 从服务或基础设施收集指标(如 Prometheus exporters, Micrometer, Telegraf)

  • 时间序列数据库: 存储指标数据(如 Prometheus, InfluxDB, TimescaleDB)

  • 可视化仪表盘: 展示指标趋势(如 Grafana)

  • 告警管理器: 根据预定义规则触发告警通知(如 Prometheus Alertmanager, Grafana Alerting)

  • 常见栈: Prometheus + Grafana。

11. 服务网格

  • 定义: 一种基础设施层,处理服务间通信的复杂性(负载均衡、服务发现、安全、可观测性、熔断等),通常通过在每个服务实例旁部署一个轻量级网络代理来实现

  • 核心组件: Sidecar 代理(如 Envoy, Linkerd-proxy)和控制平面(管理代理配置)

  • 功能: 将通信逻辑(如上面提到的服务发现、负载均衡、熔断、追踪、安全)从应用代码中抽离,由基础设施统一管理

  • 常见实现: Istio, Linkerd, Consul Connect, AWS App Mesh

12. 容器化与编排

  • 容器化: 将微服务及其依赖打包成轻量级、可移植的容器镜像(如 Docker 镜像)

  • 容器编排: 自动化容器的部署、管理、扩展和网络通信

  • 核心组件: 容器编排平台

  • 职责: 调度容器到主机、健康检查、自动伸缩、服务发现、负载均衡、滚动更新、存储管理、网络管理

  • 常见实现: Kubernetes (K8s), Docker Swarm, HashiCorp Nomad

13. 数据库

  • 模式: 通常采用数据库按服务划分模式,每个微服务拥有自己独立的数据库(可以是不同的数据库类型,如 SQL, NoSQL)。这确保了服务的松耦合和自治性

  • 挑战: 跨服务数据查询和分布式事务管理变得复杂(常用 Saga 模式、CQRS、事件溯源等解决)

14. 安全

  • 组件/机制:

  • 认证: 验证用户/服务身份(如 OAuth2, OpenID Connect, JWT)

  • 授权: 控制用户/服务对资源的访问权限(如 RBAC, ABAC)

  • API 安全: 在 API 网关和微服务层面实施安全策略(TLS/SSL, 防注入等)

  • 证书管理: 管理服务间通信的 TLS 证书(服务网格常简化此过程)

  • 密钥管理: 安全地存储和管理应用密钥、凭证

15. 持续集成/持续部署

  • 定义: 自动化微服务的构建、测试和部署流程

  • 核心组件: CI/CD 流水线工具

  • 职责: 代码提交后自动触发构建、运行单元/集成测试、打包镜像、部署到不同环境(开发、测试、生产)

  • 常见实现: Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, Argo CD (GitOps), Spinnaker

总结

微服务架构不是单一技术,而是一个由众多组件构成的生态系统。这些组件共同解决了分布式系统固有的复杂性。具体选择哪些组件以及如何组合它们,取决于应用的规模、团队技术栈、性能要求、安全需求和运维能力。常见的生态有 Spring Cloud (Java), Kubernetes + CNCF 生态(更通用),以及云厂商提供的托管服务(如 AWS 的 ECS/EKS, SQS, API Gateway, X-Ray 等组合)。服务网格的出现,正在将很多传统由应用库实现的功能(如服务发现、负载均衡、熔断、追踪、安全)下沉到基础设施层。

微服务概念

在微服务架构中,除了核心组件,还有许多关键的设计模式和技术概念,它们共同解决了分布式系统的复杂性问题。以下是常见概念及其用途的总结:


1. 服务熔断(Circuit Breaker)

  • 用途:防止因单个服务故障引发系统级联崩溃(雪崩效应)。

  • 原理

  • 监控服务调用失败率(如超时、异常)。

  • 当失败率超过阈值时,熔断器进入 "Open"(打开) 状态,直接拒绝后续请求(快速失败)。

  • 经过预设时间后进入 "Half-Open"(半开) 状态,试探性放行少量请求。

  • 若试探成功则关闭熔断器("Closed"),恢复正常调用。

  • 类比:电路保险丝——过载时熔断以保护整体电路。

  • 实现工具:Resilience4j, Hystrix, Sentinel。


2. 服务降级(Fallback)

  • 用途:在服务不可用或高负载时,提供兜底方案,保障核心流程可用性和用户体验。

  • 场景

  • 熔断触发时返回默认值(如推荐商品降级为热门榜单)。

  • 依赖服务超时时返回本地缓存数据。

  • 非核心功能暂时关闭(如关闭商品评论功能)。

  • 关键点:降级策略需提前设计,确保用户体验平滑过渡。

  • 实现:通常与熔断器(如 Hystrix)或网关结合使用。


3. 限流(Rate Limiting / Throttling)

  • 用途:控制服务请求的访问速率,防止突发流量压垮系统。

  • 策略

  • 计数器算法:限制单位时间内的请求总数。

  • 漏桶算法:以恒定速率处理请求,超限请求丢弃或排队。

  • 令牌桶算法:按速率生成令牌,请求需获取令牌才能执行(允许突发流量)。

  • 应用位置:API 网关、服务入口、中间件(如 Redis)。

  • 工具:Spring Cloud Gateway, Nginx, Sentinel, Redis。


4. 舱壁隔离(Bulkhead Isolation)

  • 用途:通过资源隔离限制故障传播范围。

  • 实现方式

  • 线程池隔离:为不同服务分配独立线程池,避免一个服务耗尽所有线程。

  • 信号量隔离:限制并发请求数(轻量级)。

  • 物理隔离:将服务部署到不同集群/可用区。

  • 类比:轮船的防水舱室——一个舱室进水不影响整艘船。


5. 重试机制(Retry)

  • 用途:应对临时性故障(如网络抖动、服务短暂不可用)。

  • 风险:不当重试可能加剧服务压力。

  • 最佳实践

  • 限制重试次数和超时时间。

  • 采用指数退避策略(Exponential Backoff):重试间隔逐渐增加(如 1s, 2s, 4s...)。

  • 针对非幂等操作(如支付)慎用重试。

  • 工具:Spring Retry, Resilience4j.


6. 分布式事务(Distributed Transaction)

  • 挑战:跨多个服务的操作如何保证数据一致性(传统 ACID 事务不适用)。

  • 常见方案

  • Saga 模式

  • 将事务拆分为多个本地事务

  • 每个事务完成后发布事件,触发下一事务。

  • 若某步骤失败,执行补偿操作(Compensating Transaction)回滚。

  • 如:订单创建 → 扣库存 → 支付,若支付失败则补偿释放库存。

  • TCC(Try-Confirm-Cancel)

  • Try:预留资源(如冻结库存)。

  • Confirm:提交操作(确认扣减)。

  • Cancel:释放资源(解冻库存)。

  • 消息队列 + 最终一致性:通过可靠消息异步驱动事务。


7. 服务网格(Service Mesh)

  • 用途:将服务间通信(负载均衡、熔断、认证等)从业务代码中解耦,下沉到基础设施层

  • 核心架构

  • 数据平面(Data Plane):Sidecar 代理(如 Envoy),处理实际流量。

  • 控制平面(Control Plane):统一管理代理配置(如 Istio)。

  • 优势:无需修改代码即可实现流量治理、可观测性、安全策略。


8. 事件驱动架构(Event-Driven Architecture, EDA)

  • 核心:服务间通过事件(消息) 异步通信。

  • 关键组件:消息中间件(Kafka, RabbitMQ)。

  • 模式

  • 发布/订阅(Pub/Sub):事件发布到主题,多个消费者订阅。

  • 事件溯源(Event Sourcing):用事件序列记录状态变更,而非直接存储当前状态。

  • 优势:解耦服务、支持最终一致性、提高系统弹性。


9. CQRS(Command Query Responsibility Segregation)

  • 用途:分离写操作(Command)读操作(Query) 的模型。

  • 实现

  • 写模型:处理数据更新,触发事件。

  • 读模型:异步同步数据,提供高效查询(可独立优化)。

  • 适用场景:读写负载差异大、需要复杂查询的微服务。


10. API 组合与聚合(API Composition / Aggregation)

  • 问题:客户端需调用多个服务获取完整数据。

  • 方案

  • API 网关聚合:网关调用多个服务,合并结果返回。

  • 后端 BFF(Backend for Frontend):为特定客户端定制聚合接口。

  • 替代方案:CQRS + 读模型预聚合数据。


总结

这些概念解决的核心问题

概念

核心目标

典型场景

服务熔断

防止级联故障

依赖服务高失败率时快速失败

服务降级

保障核心功能可用性

依赖服务不可用/高负载时提供兜底

限流

保护系统不被突发流量压垮

秒杀活动、API 防刷

舱壁隔离

限制故障影响范围

避免一个服务拖垮整个线程池

分布式事务 (Saga)

跨服务数据最终一致性

订单创建涉及库存、支付等多服务操作

事件驱动

解耦服务,异步通信

订单状态变更通知其他服务

CQRS

优化读写分离场景性能

高频查询与低频写入分离

这些概念和模式是构建高可用、可伸缩、可维护微服务架构的基石,实际应用中需根据业务需求组合使用(如熔断+降级+限流共同保障服务韧性)

微服务优缺点

优点

  1. 模块化强:每个服务都是独立的模块,便于开发、测试、部署和维护

  2. 技术多样性:不同服务可以使用不同的编程语言、数据库和技术栈,选择最适合的工具

  3. 独立部署:单个服务的更改可以独立部署,不影响其他服务,提高了发布效率和系统可用性

  4. 可扩展性好:可以针对系统的不同部分单独扩展,资源利用更高效

  5. 容错性强:单个服务故障不会影响整个系统,易于实现高可用和灾备

  6. 团队协作灵活:不同团队可以负责不同的服务,减少团队间的依赖,提高开发效率

缺点

  1. 系统复杂度提升:服务间通信、数据一致性、分布式事务等问题带来更高的系统复杂度

  2. 部署和运维难度大:需要自动化部署、服务注册与发现、监控、日志收集等完善的运维体系

  3. 网络开销增加:服务间通过网络通信,带来延迟和带宽消耗

  4. 数据一致性难以保证:分布式环境下,强一致性难以实现,通常只能保证最终一致性

  5. 测试复杂:集成测试、端到端测试难度大于单体应用

  6. 开发门槛高:开发人员需要掌握分布式系统相关知识

微服务使用

适用

  1. 大型复杂系统
    当系统业务复杂、模块众多,单体架构难以维护和扩展时,微服务可以将系统拆分为多个小型服务,降低复杂度

  2. 需要高可用和弹性扩展的系统
    例如电商、金融、在线教育等对高并发、高可用有要求的系统,可以通过微服务实现按需扩展和故障隔离

  3. 多团队并行开发
    当有多个开发团队协作时,微服务可以让不同团队负责不同服务,减少团队间的依赖,提高开发效率

  4. 需要技术多样性的项目
    某些系统的不同模块适合用不同的技术实现,微服务允许各服务采用最合适的技术栈

  5. 持续集成与持续部署(CI/CD)需求强烈的项目
    微服务支持独立部署,便于频繁发布和快速迭代

  6. 对服务可维护性和可扩展性要求高的系统
    随着业务发展,系统需要灵活扩展和维护,微服务架构更易于适应变化

不适用

  • 小型、简单、业务变化不大的项目,采用微服务会增加不必要的复杂度和运维成本

  • 团队技术能力有限,缺乏分布式系统开发和运维经验时,不建议直接采用微服务

微服务误区

  1. 一开始就上微服务
    很多团队在项目初期、业务尚不复杂时就盲目采用微服务,结果导致开发和运维复杂度大幅提升,得不偿失。微服务更适合业务发展到一定规模后再逐步拆分

  2. 服务拆分过细或过粗
    拆分过细会导致服务数量过多,管理和通信成本高;拆分过粗则失去了微服务的灵活性。合理的服务划分需要结合业务边界和团队实际情况

  3. 忽视分布式系统的复杂性
    微服务带来了分布式事务、服务间通信、数据一致性、网络延迟等新问题。如果没有充分的技术储备和运维能力,容易导致系统不稳定

  4. 以为微服务能解决所有问题
    微服务不是银弹,不能解决所有架构和业务问题。它只是应对复杂系统演进的一种手段,核心还是要解决实际业务痛点

  5. 缺乏自动化运维和监控体系
    微服务数量多,手动部署和运维不可行。没有完善的CI/CD、服务注册与发现、日志和监控体系,微服务很难落地

  6. 服务间耦合依然严重
    有些团队虽然拆分了服务,但服务间依赖紧密,接口频繁变动,导致整体系统依然脆弱,失去了微服务的独立性和灵活性

  7. 忽视数据管理和一致性问题
    微服务通常要求服务拥有独立数据库,但很多团队还是让多个服务共享数据库,或者没有设计好数据同步和一致性策略,埋下隐患

  8. 过度追求技术多样性
    虽然微服务支持多技术栈,但如果每个服务都用不同语言和数据库,会导致维护和招聘难度大增,降低团队效率

架构对比

1. 单体架构(Monolithic Architecture)

定义
所有功能模块都集成在一个应用程序中,通常部署为一个整体。

优点

  • 架构简单,开发、测试、部署都较为方便。

  • 性能较好,模块间调用为本地调用,效率高。

  • 适合小型项目或初创阶段。

缺点

  • 随着业务增长,代码量庞大,维护困难。

  • 部署不灵活,任何小改动都需整体打包上线。

  • 扩展性差,难以针对单一模块进行扩展。

  • 容错性差,单点故障影响整体系统。

2. 分布式架构(Distributed Architecture)

定义
系统由多个独立的组件(进程/服务)组成,这些组件分布在不同的服务器上,通过网络通信协作完成业务。

优点

  • 资源利用率高,可横向扩展。

  • 容错性好,单个节点故障不会影响整体。

  • 适合大规模、高并发场景。

缺点

  • 系统复杂度高,涉及网络通信、数据一致性、分布式事务等问题。

  • 部署和运维难度大。

  • 调试和测试复杂。

说明
分布式架构是一个广义概念,微服务架构其实是分布式架构的一种实现方式。

3. 微服务架构(Microservices Architecture)

定义
将应用拆分为一组小型、独立部署的服务,每个服务围绕特定业务能力构建,服务间通过API通信。

优点

  • 每个服务可独立开发、部署、扩展,灵活性高。

  • 支持多技术栈,适合多团队协作。

  • 容错性和可维护性好。

缺点

  • 服务数量多,系统治理、运维、监控复杂。

  • 服务间通信、数据一致性、分布式事务等问题突出。

  • 对团队技术和运维能力要求高。

0
  1. 支付宝打赏

    qrcode alipay
  2. 微信打赏

    qrcode weixin

评论区