架构解密从分布式到微服务:分布式系统的设计理念

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,182元/月
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
简介: 分布式系统从诞生到现在已经有几十个年头了,其中伴随着一些很重要的基础理论,正是这些影响深远的基础理论,奠定了分布式系统的坚实基础,造就了分布式领域的一座座宏伟大厦。为了练就一身武功,让我们从这些经典的分布式理论开始学起吧。

分布式系统的经典理论

分布式系统从诞生到现在已经有几十个年头了,其中伴随着一些很重要的基础理论,正是这些影响深远的基础理论,奠定了分布式系统的坚实基础,造就了分布式领域的一座座宏伟大厦。为了练就一身武功,让我们从这些经典的分布式理论开始学起吧。

网络异常,图片无法展示
|

从分布式系统的设计理念说起

分布式系统的首要目标是提升系统的整体性能和吞吐量。如果最终设计出来的分布式系统占用了10台机器才勉强达到单机系统的两倍性能,那么这个分布式系统还有存在的价值吗?另外,即使采用了分布式架构,也仍然需要尽力提升单机上的程序性能,使得整体性能达到最高。所以,我们仍然需要掌握高性能单机程序的设计和编程技巧,例如多线程并发编程、多进程高性能IPC通信、高性能的网络框架等。

另外,任何分布式系统都存在让人无法回避的风险和严重问题,即系统发生故障的概率大大增加:小到一台服务器的硬盘发生故障或宕机、一根网线坏掉,大到一台交换机甚至几十台服务器一起停机。分布式系统下故障概率的增加,除了受到网络通信天生的不可靠性及物理上分布部署的影响,还受到X86服务器品质等的影响。

所以,分布式系统设计的两大关键目标是性能与容错性,而这两个目标的实现恰恰是很棘手的,而且相互羁绊!举个例子,我们要设计一个分布式存储系统,出于对性能的考虑,在写文件时要先写一个副本到某台机器上并立即返回,然后异步发起多副本的复制过程,这种设计的性能最好,但存在“容错性”的风险,即在文件写完后,目标机器立即发生故障,导致文件丢失!如果同时写多个副本,在每个副本都成功以后再返回,则又导致“性能”下降,因为该过程取决于最慢的那台机器的性能。

网络异常,图片无法展示
|

由于性能指标是绝对的,而容错性指标是相对的,而且实际上对于不同的数据与业务,我们要求的容错性可以存在很大的差异,比如允许意外丢失一些日志类的数据;允许一些信息类的数据暂时不一致但最终达到一致;对交易类的数据要求有很高的可靠性。所以我们会发现,很多分布式系统的设计都提供了多种容错性策略,以适应不同的业务场景,我们在学习和设计分布式系统的过程中也需要注意这一特性。

下面继续谈谈分布式系统设计中的两大思路:中心化和去中心化。

在分布式架构设计里,中心化始终是一个主流设计。中心化的设计思想很简单,分布式集群中的节点器按照角色分工,大体上分为两种角色:Leader和 Worker。Leader通常负责分发任务并监督Worker,让 Worker一直在执行任务;如果Leader "发现某个Worker 因意外状况不能正常执行任务,则将该Worker 从 Worker队列去除,并将其任务分给其他Worker。基于容器技术的微服务架构Kubernetes就恰好采用了这一设计思路。

在分布式中心化的设计思路中,还有一种设计思路与编程中敏捷开发的思路类似,即充分相信每个 Worker,Leader只负责任务的生成而不再指派任务,由每个 Worker自发领任务,从而避免让个别Worker执行的任务过多,并鼓励能者多劳。

中心化设计存在的最大问题是Leader的安全问题,如果Leader出了问题,则整个集群崩溃。但我们难以同时安排两个Leader 以避免单点问题。为了解决这个问题,大多数中心化系统都采用了主备两个Leader 的设计方案,可以是热备或者冷备,也可以是自动切换或者手动切换,而且越来越多的新系统都具备了自动选举切换Leader 的能力,以提升系统的可用性。中心化设计还存在另外一个潜在的问题,即Leader的能力问题,如果系统设计和实现得不好,问题就会卡在 Leader身上。

下面一起探讨去中心化设计。

在去中心化设计里通常不区分Leader 和 Worker这两种角色。全球互联网就是一个典型的去中心化的分布式系统,联网的任意节点设备宕机,都只会影响很小范围的功能。去中心化设计的核心是在整个分布式系统中不存在一个区别于其他节点的Leader,因此不存在单点故障问题,但由于不存在 Leader,所以每个节点都需要与其他(所有)节点对话才能获取必要的集群信息,而分布式系统通信的不可靠性大大增加了上述功能的实现难度。

去中心化设计中最难解决的一个问题是“脑裂”问题,这种情况的发生概率很低,但影响很大。脑裂指一个集群由于网络的故障,被分为至少两个彼此无法通信的单独集群,此时如果两个集群各自工作,则可能会产生严重的数据冲突和错误。一般的设计思路是,当集群判断发生了脑裂问题时,规模较小的集群就“自杀”或者拒绝服务。

实际上,完全意义的真正去中心化的分布式系统并不多见。相反,在外部看来去中心化但工作机制采用了中心化设计思想的分布式系统不断出现。在这种架构下,集群中的Leader是被动态选择出来的,而不是人为预先指定的,而且在集群发生故障的情况下,集群的成员会自发地举行“会议”选举新的Leader 主持工作。最典型的案例就是ZooKeeper 及用Go实现的Etcd。

网络异常,图片无法展示
|

本文给大家讲解的内容是架构解密从分布式到微服务:分布式系统的设计理念

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
1月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
2月前
|
存储 安全 Java
管理 Spring 微服务中的分布式会话
在微服务架构中,管理分布式会话是确保用户体验一致性和系统可扩展性的关键挑战。本文探讨了在 Spring 框架下实现分布式会话管理的多种方法,包括集中式会话存储和客户端会话存储(如 Cookie),并分析了它们的优缺点。同时,文章还涵盖了与分布式会话相关的安全考虑,如数据加密、令牌验证、安全 Cookie 政策以及服务间身份验证。此外,文中强调了分布式会话在提升系统可扩展性、增强可用性、实现数据一致性及优化资源利用方面的显著优势。通过合理选择会话管理策略,结合 Spring 提供的强大工具,开发人员可以在保证系统鲁棒性的同时,提供无缝的用户体验。
|
3月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
641 3
|
4月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
1月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
30天前
|
消息中间件 运维 监控
《聊聊分布式》BASE理论 分布式系统可用性与一致性的工程平衡艺术
BASE理论是对CAP定理中可用性与分区容错性的实践延伸,通过“基本可用、软状态、最终一致性”三大核心,解决分布式系统中ACID模型的性能瓶颈。它以业务为导向,在保证系统高可用的同时,合理放宽强一致性要求,并借助补偿机制、消息队列等技术实现数据最终一致,广泛应用于电商、社交、外卖等大规模互联网场景。
|
1月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
1月前
|
算法 NoSQL 关系型数据库
《聊聊分布式》分布式系统核心概念
分布式系统由多节点协同工作,突破单机瓶颈,提升可用性与扩展性。CAP定理指出一致性、可用性、分区容错性三者不可兼得,BASE理论通过基本可用、软状态、最终一致性实现工程平衡,共识算法如Raft保障数据一致与系统可靠。
|
1月前
|
负载均衡 Java API
《深入理解Spring》Spring Cloud 构建分布式系统的微服务全家桶
Spring Cloud为微服务架构提供一站式解决方案,涵盖服务注册、配置管理、负载均衡、熔断限流等核心功能,助力开发者构建高可用、易扩展的分布式系统,并持续向云原生演进。

热门文章

最新文章