深造分布式打败面试官招式一小试牛刀

变成派大星

已于 2022-09-16 13:30:15 修改

阅读量2.8k

点赞数

分类专栏：分布式系列文章标签：分布式大数据

于 2022-09-02 19:45:03 首次发布

本文链接：https://blog.csdn.net/weixin_44994494/article/details/126669066

版权

分布式系列专栏收录该内容

3 篇文章 0 订阅

订阅专栏

分布式系统和单体系统之间到底有什么区别？

前言

无论是传统系统、还是互联网应用，分布式无疑是当下软件设计和实现的主流技术体系。

围绕分布式系统（Distributed System）的基本概念以及实现方式，开发人员需要掌握一系列对应的技术组件。另一方面，我们也需要认识到分布式系统的诞生并不是一蹴而就的，而是从传统的单体系统（Monolith System）发展和演进而来。可以认为，分布式系统是对单体系统的一种改进，但这种改进同样也带来了复杂度和实现难度。

问题

那么，究竟什么是分布式系统？分布式系统和单体系统之间到底有什么区别？本讲内容将围绕这一问题展开讨论。

解答

相信你对单体系统并不陌生，现实中很多单体系统都还运行在生产环境中。那么，什么样的系统是单体系统呢？

所谓的单体系统，简单来说，就是只包含一个物理组件的系统，能够独立进行部署和运行。下图展示的就是一个典型的单体系统结构图，可以看到在单体系统内部可以采用分层的方式合理组织代码结构，但从物理上看就是一个能够独立运行的应用程序,服务都在同一个模块里面所以我们在使用的时候不会出现服务之间的配合系统的复杂度比较低同时整个项目的复杂度相对于分布式相对较低但是单模块的体积比较大容错率比较低。
在这里插入图片描述

演变

现在，让我们往上图中再添加一个单体系统，这样整个系统就有了两个能够独立运行的应用程序。显然，它们可以有自己的数据库，并通过网络通信完成交互，这就构成了一种分布式系统。如下图所示：

在这里插入图片描述

在上图中，虽然我们只是简单把两个独立的单体系统组合在了一起，但是从系统本身而言却发生了本质性的变化。原本一个单体系统可以完成的操作现在就需要两个系统之间的有效协作，这显然增加了系统的复杂度。但在这背后，也为我们更好地利用系统资源、构建合理的架构体系提供了基础。在日常开发过程中，我们在引入分布式系统时需要分析具体的应用场景和需求,等同于用复杂度换资源的合理利用在刚使用分布式系统的时候我们首先感觉的是复杂一个数据可能需要多个服务之间的配合 但是从长远来看等到项目有一定规模分布式的好处就会慢慢的体现出来。

从面试角度讲，关于分布式系统的讨论往往比较发散，属于典型的概念类面试题。但凡概念类的面试题，提问的方式通常是比较灵活的。关于单体系统和分布式系统的相关概念，以下几种提问方式都属于同一类的面试题：

提出问题

为什么系统构建的主流方式会从单体系统演变到现在的分布式系统？
传统单体系统存在哪些核心问题？
相较单体系统，分布式系统具体有哪些优势？
分布式系统的本质特性有哪些？

问题分析

任何系统设计方法和思想的诞生都具有一定的背景和条件，这点对于单体系统和分布式系统同样如此。

Case1: 为什么系统构建的主流方式会从单体系统演变到现在的分布式系统？

在互联网时代还没有到来之前，技术人员主要的工作就是开发单体系统。所以，单体系统本身也是有很多优势的，否则的话就无法成为当时主流的系统构建方式。事实上，时至今日，在线上运行的单体系统也并不少见。

那么，是什么原因导致分布式系统的出现呢？归根结底是因为业务需求的复杂度、用户数据的体量以及系统的开发和维护速度等因素的变化，导致了技术的演进。这是我们首先需要阐述的一点。

那么，为什么上述变化的出现，就会导致单体系统不能适应时代的发展要求呢？原因在于单体系统无论在应对业务复杂度和产品迭代速度，还是在处理高并发、大数据量的用户请求，亦或是在代码维护和团队协作等方面都存在一系列问题。正是单体系统存在的这些问题，促使了我们不得不引入分布式系统。这是我们在面试过程中必须要重点阐述的，也是两者之间差异点的一个重要维度。

另一方面，只要我们采用了分布式系统，就意味着所有这些问题都能得到解决吗？显然不是。任何事物都具有两面性。虽然，和单体系统相比，分布式系统具备优势，但它也引入了新的问题，包括网络传输的三态性、数据的一致性和可用性等。这些分布式系统的本质特性是理解的的另一个重要维度。

通过上述分析，我们明确了这类问题背后的要点所在，开发人员往往只关注于具体分布式开发工具和框架的应用，关于分布式系统背后的设计思想和理念并不十分清楚

接下来，我们具体来分析一下背后的知识体系。

Case2:传统单体系统存在哪些核心问题

在分布式系统成为主流的系统构建形式之前，开发人员在很长的一段时间里构建的都是单体系统。单体系统的主要优势就是简单。例如，如果我们使用 Spring Boot 框架来构建一个单体系统，那么它的表现形式就是一个能够独立运行的 JAR 包。开发人员通过简单几个步骤就可以开发出基于 HTTP 协议的 Web 服务。

但是，这种简单性是相对的。如果业务需求变化很快、用户请求体量巨大，那么通过构建一个简单的单体系统就无法应对系统发展的要求。

在接下来的内容中，我们先来具体分析单体系统所存在的核心问题。
单体系统的核心问题表现在三个方面，即业务扩展性、性能伸缩性和代码复杂度，如下图所示：

在这里插入图片描述

我们先来看业务扩展性。所谓扩展性，指的是当系统的业务需求发生变化时，我们对现在系统的改动程度的一种控制能力。改动程度越大，扩展性就越差。显然，对于单体系统而言，任何改动都会导致整个系统进行重新构建和发布，所以它的扩展性是比较低的。

另一方面，单体系统的可伸缩也不高。和扩展性关注业务变化的角度不同，伸缩性关注的是性能指标。如果通过简单扩容就能确保系统的性能得到等比例的提升，那么我们就认为该系统具备较好的伸缩性。对于单体系统而言，由于内存密集型和 CPU 密集型的代码都位于同一个服务器上，所以很难做到对资源的充分利用。

下图展示的就是一个典型的例子，可以看到系统中的 A、B、C 组件的资源利用率是不同的。因为我们无法对单体系统中的这些组件进行拆分，所以也就无法单独对图中的 B、C 组件进行资源利用率的提升。
在这里插入图片描述

至于第三点的代码复杂度问题，我们也不难理解。由于我们无法对单块系统中的代码进行物理上的拆分，所以不同组件之间的代码边界往往很难清晰划分，这就无法有效控制代码结构的复杂度。久而久之，因为代码复杂度引起的系统缺陷就会难以维护。

上述三点是任何单体系统所普遍存在的问题。为了解决这些问题，分布式系统就应运而生了。

Case3:相较单体系统，分布式系统具体有哪些优势？

什么是分布式系统？所谓分布式系统，区别于单体系统，会将整个系统拆分成多个能够独立运行的服务，这些服务在物理上是隔离的，相互之间基于网络进行通信和协调。

下图展示的就是现实场景中常见的一种分布式系统，可以看到这里有专门针对业务处理的业务服务 1 和业务服务 2 这两个独立的服务，也存在 Web 服务、消息中间件、缓存等提供技术能力的独立组件。
在这里插入图片描述

显然，想要实现分布式系统，首要的就是完成对系统中各个服务的合理拆分。通常，我们有两种主流的拆分方式，即纵向（Vertical）拆分和横向（Horizontal）拆分。

可以认为纵向拆分的目的就是更好地完成对系统中业务服务的合理组织。围绕一个完整而复杂的业务执行流程，我们通常可以根据不同的业务场景以及数据属性来完成对业务服务的拆分。例如，在常见的互联网医院系统中，具备最基本的医生、患者以及问诊等业务处理场景和数据，这时候我们就可以基于这些场景和数据来分别提取独立的业务服务，如下图所示：

在这里插入图片描述

介绍完纵向拆分，我们再来看横向拆分。横向拆分的切入点在于复用，即我们在提取一系列独立服务的同时，还需要考虑通过一定的手段将它们高效地整合在一起。这样，整个系统就可以像是在搭积木一样对各个服务进行排列组合，如下图所示：

在这里插入图片描述

在上图中，我们注意到引入了一个分布式服务框架。通过该框架，系统中的医生服务、患者服务等一系列独立服务就可以进行合理地编排和整合，从而构建业务 A、业务 B 等不同的业务场景。显然，分布式服务框架在这里扮演了重要作用，而本小册后续内容中所要介绍的 Dubbo 和 Spring Cloud 就是目前主流的分布式服务框架。

请注意，分布式系统相较于单体系统而言具备优势的同时，也存在一些我们不得不考虑的特性，包括以下。