青海网站建设的企业,网页搭建公司,禅城网站建设报价,福建省住房和建设厅网站1. 分布式的基本概念
1.1 什么是分布式系统#xff1f;
分布式系统#xff08;Distributed System#xff09;#xff1a;由多台服务器#xff08;或节点#xff09;协同工作#xff0c;对外提供一个整体服务。不同节点之间通过网络通信来协同处理请求或共享数据…1. 分布式的基本概念
1.1 什么是分布式系统
分布式系统Distributed System由多台服务器或节点协同工作对外提供一个整体服务。不同节点之间通过网络通信来协同处理请求或共享数据相对于「单体应用」而言可以带来更高的吞吐量、可用性和灵活扩展能力。
1.2 分布式 vs. 单体架构 单体架构 所有业务模块部署在同一应用实例中垂直扩容升级服务器硬件成为主要的扩展方式。优点开发调试较简单部署方便。缺点当应用规模过大时任何一个模块出现故障或性能瓶颈都会影响整个系统并且无法灵活扩容单个模块。 分布式架构 将系统拆分成若干服务或节点每个节点可以独立运行、独立扩容、独立维护。优点更好的可扩展性、可靠性能处理更高并发和数据量。缺点系统变得复杂需要处理 网络通信、数据一致性、运维管理 等问题。
1.3 分布式系统的核心挑战
数据一致性多节点同时修改同一数据如何保证最终数据正确可用性某个节点失败不会影响整体服务。可扩展性需要随业务增长快速增加节点处理能力。网络延迟与可靠性网络抖动、分区故障等异常场景必须做好应对策略如重试、降级。系统复杂度日志监控、调试、部署都更加繁琐。
2. 分布式架构的主要组成部分
Spring Boot 下的分布式架构通常包含以下几个关键部分
组件作用分布式服务微服务业务拆分避免单体架构的复杂性分布式缓存Redis提高查询性能减少数据库压力分布式锁Redis/Zookeeper解决多个节点同时修改数据的一致性问题分布式事务Seata保障数据一致性避免并发冲突分布式消息队列RabbitMQ/Kafka异步处理任务提升系统吞吐量服务注册与发现Nacos/Eureka让服务可以自动发现彼此不需要手动配置分布式配置中心Nacos/Spring Cloud Config统一管理配置提高可维护性负载均衡Nginx/Spring Cloud Gateway把请求合理分配到多个服务实例分布式任务调度ElasticJob/Xxl-Job让多个服务器协同执行定时任务 3. Spring Boot 分布式架构的实现方式 Redis 提供缓存和分布式锁提升性能Nacos/Eureka 让微服务可以互相发现MQ 让服务之间异步通信减少耦合Seata 保证分布式事务一致性负载均衡 API 网关 让服务更高效 3.1 分布式服务微服务
含义把一个庞大的单体应用拆分成若干个服务每个服务只负责一个“相对独立的业务领域或功能”称之为“微服务”。 示例 UserService专注处理用户登录、注册、用户信息管理OrderService负责订单的创建、查询、支付信息对接ProductService管理产品、库存、定价等PaymentService处理支付渠道、账务、对账逻辑 好处 解耦每个服务都可独立部署、升级互不影响。独立扩展哪块业务压力大就扩容对应服务的节点而不是整合到一起。技术栈灵活不同服务甚至可以用不同的语言或框架。
在 Spring Boot 中如何实现微服务 Spring Boot Spring Cloud Spring Cloud 提供了微服务生态包括 服务注册与发现Eureka, Nacos, Consul让各微服务在一个注册中心上登记并获取彼此的地址负载均衡Ribbon 或 Spring Cloud LoadBalancer在调用某个微服务时自动从多个实例中选一台服务调用Feign通过 HTTP/REST 的方式去请求其他微服务熔断、限流Hystrix, Sentinel在调用失效时防止雪崩网关Spring Cloud Gateway统一处理路由、鉴权、流量控制 服务间通信方式 HTTP/REST最常见的形式每个微服务暴露 RESTful API其他微服务通过 HTTP 调用。RPC部分场景需要高性能的调用可以使用 RPC例如 Dubbo、gRPC减少网络开销提升效率。消息队列如果是异步调用场景还会结合 MQ 来实现解耦与异步化。 3.2 服务注册与发现Service Discovery
当我们有了多个微服务之后问题来了如何让它们相互找到对方
传统做法在配置文件里写死每个服务的地址。但一旦服务集群扩容或 IP 地址变动就要重新修改配置非常麻烦。分布式做法服务注册与发现。各个微服务在启动时自动向“注册中心”报到注册中心会保存当前可用的服务实例列表。其他服务要调用它时只需要从注册中心查到目标服务的地址就行。
常见的注册中心
EurekaNetflix OSSNacos阿里巴巴开源功能更强大也能做配置中心ZookeeperApache 基金会项目也能做服务注册但更多用于分布式协调
在 Spring Boot Spring Cloud 中配置服务注册发现大致流程
在 pom.xml 中引入对应的依赖例如 spring-cloud-starter-alibaba-nacos-discovery。在 application.yml 中配置好注册中心地址 server-addr: localhost:8848 等。启动时服务会自动注册到 Nacos或其他注册中心。 3.3 分布式配置中心
配置中心 主要解决的是“在分布式环境中如何统一管理各个微服务的配置”避免每个服务都各自持有不同的配置文件难以维护。
Spring Cloud Config早期常用的配置中心基于 Git 存储配置Nacos ConfigNacos 同时提供注册发现和配置管理Apollo携程开源或 Disconf 等也可以
好处
统一管理所有配置信息都在一个地方配置中心修改后可实时生效。动态更新微服务在运行时能监控到配置变动自动刷新无需重启。区分环境如 DEV, TEST, PROD 环境对应不同配置。 3.4 分布式缓存Redis 等
在分布式环境下数据库通常成为性能瓶颈。为减少对数据库的直接访问和压力需要一个 高性能的分布式缓存。Redis 是最常用的选择它具有以下优势
内存存储读写速度快。丰富的数据结构字符串、哈希、列表、集合、有序集合等。支持 主从复制、Cluster 集群适合分布式部署。常用于 缓存热点数据、分布式 Session、分布式锁 等场景。
使用 Redis 的关键点
设计 合理的缓存键key比如 product:detail:{productId}。设置 过期时间避免缓存数据与数据库数据长期不一致。考虑 缓存穿透、缓存雪崩、缓存击穿 等问题并进行对应的防护如 Bloom Filter, 加互斥锁, 合理限流等。 3.5 分布式锁
在分布式环境中如果多个节点同时对同一个资源进行写操作就容易出现数据不一致或并发冲突。因此需要一种分布式锁来保证 在同一时间只有一个节点可以获取锁进行资源操作。
常见方案
Redis 分布式锁 使用 SETNXset if not exist EXPIRE 或 SET key value NX PX time 命令实现。注意要设置超时时间避免锁无法释放导致死锁。也要考虑锁的续约和解锁时的原子性操作Lua 脚本以避免误删他人的锁。 Zookeeper 分布式锁 利用 ZK 的临时顺序节点来竞争锁监听事件一旦获取锁的节点断开连接就自动删除节点其他节点立即感知到并可重新竞争。
示例基于 Redis 的简易分布式锁代码示例性不是完整生产级
String lockKey lock:order;
String lockVal UUID.randomUUID().toString();// 尝试加锁
Boolean success redisTemplate.opsForValue().setIfAbsent(lockKey, lockVal, 10, TimeUnit.SECONDS);
if (Boolean.TRUE.equals(success)) {try {// 执行业务逻辑} finally {// 解锁时先判断锁是否是自己加的String val redisTemplate.opsForValue().get(lockKey);if (lockVal.equals(val)) {redisTemplate.delete(lockKey);}}
}3.6 分布式事务
在单体应用中事务只需要依赖数据库的本地事务ACID即可。但在分布式系统中可能一个操作需要 跨多个微服务、跨多个数据库这时就出现了 分布式事务 问题
例如在电商场景下创建订单 时要同时扣减库存、生成支付记录等这些操作都在不同微服务里完成如果其中某一步出错就需要回滚之前的操作。
常见分布式事务方案
2PC两阶段提交协调者告诉所有参与者先预提交然后再统一提交或回滚。实现复杂性能损耗大适合对一致性要求极高的场景。TCCTry-Confirm-Cancel业务系统自己实现各个操作的 “Try, Confirm, Cancel”实现灵活但开发成本高。Seata阿里开源的分布式事务框架提供 AT 模式对 JDBC 层做代理也提供 TCC 等模式。
Seata 示例
GlobalTransactional
public void placeOrder(Order order) {// 跨服务调用inventoryService.decreaseStock(order.getProductId(), order.getQuantity());paymentService.processPayment(order);orderMapper.insert(order);// Seata 会在这里把整个调用过程进行管理可做到成功或回滚
}在执行过程中如果其中一个调用报错Seata 就会通知其他服务进行回滚。 3.7 分布式消息队列
消息队列 (Message Queue) 用于解耦系统、异步处理和削峰填谷。常见的 MQ 方案有
RabbitMQ轻量级支持事务与确认机制适合传统企业应用以及对消息可靠性要求高的场景。Apache Kafka高吞吐大规模数据流处理的“事实标准”更多用于大数据、日志收集、流式处理等场景。RocketMQ阿里开源的分布式消息中间件和 Kafka 类似也有较高的吞吐。
MQ 的作用
解耦比如用户下单后需要发送优惠券、通知物流、通知商家等而如果所有这些操作都放在下单接口里会导致耦合过高使用 MQ每个消费者服务负责监听消息并执行相应的业务逻辑。削峰填谷在高峰时段订单系统可以快速写入消息队列后台处理系统再慢慢消费避免直接压垮数据库或其他服务。异步不需要同步等待消息处理完成加快用户请求的响应速度。 3.8 API 网关与负载均衡
当服务拆分越来越多我们往往需要一个统一的 网关 来管理请求
服务网关如 Spring Cloud Gateway、Nginx、Kong 统一对外提供访问入口进行路由分发鉴权限流监控等在微服务复杂时可以屏蔽内部服务接口的变化对外提供稳定的 API。 负载均衡 当某个微服务有多个实例时网关或负载均衡器需要把请求分散到各个实例上避免其中一个实例被打满。常见方式Nginx 反向代理 或 Spring Cloud Ribbon 新版 Spring Cloud LoadBalancer都可实现负载均衡。 四、整体流程与示例
4.1 典型电商微服务调用链
以 电商订单 流程为例来看看分布式系统下的一般调用。
用户 访问 API 网关或 Nginx请求 /api/order/create 接口。网关解析路由规则将请求转发给 OrderService。OrderService 调用 UserService 检查用户信息比如积分、等级等。OrderService 调用 ProductService 检查库存、扣减库存同时查询商品价格。OrderService 写入订单数据库本地事务或分布式事务处理。OrderService 向 MQ 发送消息用于通知其他服务如物流、积分系统等。MQ 的消费者如 LogisticsService消费消息并执行下一步操作。
在这个过程中会用到
服务注册中心保证 OrderService 能动态发现 ProductService 的地址分布式缓存可能在 OrderService、ProductService 的查询环节做缓存分布式锁避免多次重复扣减库存分布式事务如要保证扣库存与下单一致消息队列通知其他异步任务
4.2 部署模式
开发/测试环境一般都是在本地 Docker 或者虚拟机里把注册中心、MQ、Redis、数据库等组件跑起来即可。生产环境会把各个服务独立部署在多台服务器或容器云上 注册中心、配置中心Nacos/Consul/Eureka集群Redis 高可用集群主从哨兵模式或 Redis ClusterMQ 集群RabbitMQ 集群或 Kafka 集群分布式文件系统如 MinIO, FastDFS, OSS 等后端数据存储MySQL 或者多分片数据库需要做读写分离或分库分表若干微服务集群UserService、OrderService...通过容器编排Kubernetes 或 Docker Swarm进行管理
