云原生社区 > 微服务 > 正文

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

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

分布式系统的经典理论

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

image

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

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

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

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

image

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

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

在分布式架构设计里,中心化始终是一个主流设计。中心化的设计思想很简单,分布式集群中的节点器按照角色分工,大体上分为两种角色: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。

image

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

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

版权声明:本文内容由便宜云服务器实名注册用户自发贡献,版权归原作者所有,便宜云服务器开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《便宜云服务器开发者社区用户服务协议》和《便宜云服务器开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【分部式架构】分布式系统的挑战
【分部式架构】分布式系统的挑战
10 0
架构解密从分布式到微服务:分布式系统的基石:TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol,传输控制协议/互联网络协议)是Internet 的基本协议,简单地说,由底层的IP和TCP组成。TCP/IP的开发工作始于20世纪70年代,该协议是用于互联网的第一套协议。TCP/IP结合 DNS、路由协议等一系列相关协议,最终实现了网络之间任意两点间的数据通信问题。我们来看看在访问百度首页时,数据包是如何从计算机传送到百度的服务器上的。
100 0
分布式系统开发实战:微服务架构,实战:基于CQRS微服务通信
Axon Framework是一个适用于Java的、基于事件驱动的轻量级CQRS框架,既支持直接持久化Aggregate状态,也支持采用EventSourcing。
102 0
分布式系统实战:什么是微服务架构?微服务架构与SOA架构的区别
自2014年业界提出“微服务(Microservices)”的概念以来,微服务架构就不断演进,并且日趋火爆。越来越多的企业拥抱微服务,期望通过微服务的架构来解决大型项目的管理与运维。
140 0
分布式系统核心:REST风格的架构,REST成熟度模型及REST API管理
正如前文所述,正确、完整地使用REST是困难的,关键在于RoyFielding所定义的REST只是一种架构风格,它并不是规范,所以也就缺乏可以直接参考的依据。好在Leonard Richardson补充了这方面的不足。
122 0
单体架构,分布式系统的差别在哪里?
随着技术日新月异的发展,最近几年微服务和分布式技术成为主流。每一个好的解决方案不一定是直接设计出来的,但每一个优秀的架构都必须承受得住业务的考验和需求驱动的积累。最初我们开发系统都是在单个的应用上进行开发、测试、部署和运维等。
80 0
分布式系统架构(一)——Master-Workers 架构
分布式系统架构(一)——Master-Workers 架构
154 0
应用于分布式系统-从单体架构到微服务架构 | 学习笔记
快速学习应用于分布式系统-从单体架构到微服务架构。
82 0
分布式系统架构面试题汇总(下)
这篇文章主要是说在进化的过程中可能会遇到的问题以及如何去解救这些问题。
538 0
分布式系统架构面试题汇总(上)
这篇文章主要是说在进化的过程中可能会遇到的问题以及如何去解救这些问题。
609 0
微服务
+关注
为微服务建设降本增效,为微服务落地保驾护航。
热门文章
热门讨论
+关注
愿天堂没有BUG(公众号同名)
面试真题·进阶教程·职场干货·思维导图免费分享
文章
问答
视频
相关电子书
更多
可视化架构运维实践
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
相关实验场景
更多


http://www.vxiaotou.com