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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 分布式系统从诞生到现在已经有几十个年头了,其中伴随着一些很重要的基础理论,正是这些影响深远的基础理论,奠定了分布式系统的坚实基础,造就了分布式领域的一座座宏伟大厦。为了练就一身武功,让我们从这些经典的分布式理论开始学起吧。

分布式系统的经典理论

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

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

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

分布式系统的首要目标是提升系统的整体性能和吞吐量。如果最终设计出来的分布式系统占用了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给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

相关文章
|
3天前
|
消息中间件 设计模式 数据库
深入探讨后端微服务架构中的分布式事务处理
【2月更文挑战第6天】在当今互联网应用开发领域,后端微服务架构已经成为一种常见的设计模式。本文将深入探讨在后端微服务架构中如何有效处理分布式事务,包括事务管理、一致性保障和异常处理策略,帮助开发者更好地应对复杂的业务场景。
92 4
|
7天前
|
监控 数据可视化 关系型数据库
微服务架构+Java+Spring Cloud +UniApp +MySql智慧工地系统源码
项目管理:项目名称、施工单位名称、项目地址、项目地址、总造价、总面积、施工准可证、开工日期、计划竣工日期、项目状态等。
142 6
|
10天前
|
人工智能 监控 安全
java基于微服务架构的智慧工地监管平台源码带APP
劳务管理: 工种管理、分包商管理、信息采集、班组管理、花名册、零工采集、 现场统计、考勤管理、考勤明细、工资管理、零工签证
199 4
|
1天前
|
监控 负载均衡 Dubbo
|
1天前
|
Java API 调度
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。
30 1
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
|
6天前
|
存储 监控 持续交付
探讨后端微服务架构的演进与优化
【2月更文挑战第4天】随着互联网应用的快速发展,后端微服务架构作为一种灵活、可扩展的架构模式,逐渐成为各大企业和组织的首选。本文将从微服务架构的定义和特点入手,探讨其在实际应用中的演进过程以及优化策略,帮助读者更好地理解并应用后端微服务架构。
32 2
|
22天前
|
开发者 Docker 微服务
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发环境中,微服务架构因其高度解耦和独立性而成为企业首选。然而,微服务的管理和部署可能会变得复杂和繁琐。本文将探讨如何利用Docker,一个轻量级的容器化技术,来简化和加速微服务的部署。我们将从Docker的基础概念入手,详细介绍如何创建、配置和运行微服务容器,最后讨论Docker在微服务架构中的优势和挑战。本文旨在为开发者提供一条清晰的路径,通过容器化技术实现微服务架构的高效部署和管理。
62 0
|
2月前
|
NoSQL Java 测试技术
字节二面:Spring Boot Redis 可重入分布式锁实现原理?
字节二面:Spring Boot Redis 可重入分布式锁实现原理?
121 0
|
2月前
|
存储 缓存 NoSQL
【分布式】Redis与Memcache的对比分析
【1月更文挑战第25天】【分布式】Redis与Memcache的对比分析
|
2月前
|
监控 NoSQL Linux
【分布式】Redis的持久化方案解析
【1月更文挑战第25天】【分布式】Redis的持久化方案解析

相关产品

  • 微服务引擎
  • 服务网格

  • http://www.vxiaotou.com