集群、分布式及微服务间的区别与联系

目录


单体架构介绍

早期很多创业公司或者传统企业会把业务的所有功能实现都打包在一个项目中,这种方式就称为单体架构

以我们都很熟悉的电商系统为例, 电商系统包括:用户管理, 商品管理, 订单管理, 支付管理,库存管理,物系流管理等等,项目早期我们会把这些模块都写在一个web项目中,然后统一部署到一个Web服务器中

这种架构开发、部署简单,一个项目就包含了所有的功能,省去了多个项目之间的交互和调用消耗.直接部署在一个服务器即可.


集群和分布式架构

当网站的用户量越来越大,需求也会越来越多,流量也会越来越大,服务可能就会面临以下问题:

  • 后端服务器的压力就会越来越大,负载越来越高,甚至出现无法访问的情况 .
  • 业务场景逐渐复杂.为了满足用户的需求,单体应用也会越来越大.
  • 各个业务代码之间的耦合度也会越来越高.任何一个问题,都需要整个项目重新构建,发布一个微小的问题,可能会导致整个应用挂掉

我们从两个方面进行优化:

  • 横向:添加服务器,把单台机器变成多台机器的集群.

  • 纵向:把一个应用,按照业务进行拆分,拆分为多个项目.此架构也称为垂直架构.

以单体结构规模的项目为单位进行垂直划分.也就是将一个大项目拆分成一个一个单体结构项目.项目和项目之间相对比较独立,接口多为数据同步功能.

集群和分布式

集群 (cluster) 是将一个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个服务器通过负载均衡调度完成任务.每个服务器称为集群的节点(node)

分布式是将一个系统拆分为多个子系统,多个子系统部署在多个服务器上,多个服务器上的子系统 协同合作完成一个特定任务.

比如

一个饭店只有一个厨师,这个厨师负责备菜,洗菜,切菜,炒菜

随着这个饭店的生意越来越好,这个厨师忙不过来了,饭店又请了一个厨师,新厨师和老厨师做一样的事情,也是洗菜,切菜,炒菜这两个厨师的关系就是集群

为了让厨师专心炒菜,饭店又请了一个配菜师,负责备菜,洗菜,切菜,厨师和配菜师的关系就是分布式,

后来一个配菜师也忙不过来了,又请了一个配菜师,这两个配菜师的关系就是集群

集群和分布式区别和联系

  1. 从概念上.集群是多个计算机做同样的事 ,分布式是多个计算机做不同的事
  2. 从功能上.集群的每一个节点功能是相同的,并且可以替代的 .分布式也是多个节点组成的系统,但是每个节点完成的业务是不同的,一个节点出现问题,这个业务就不可访问了
  3. 从关系上.分布式和集群在实践中,很多时候是互相配合使用的 .比如分布式的某一个节点,可能由一个集群来代替,分布式架构大多是建立在集群上的.所以实际的分布式架构设计中并不会把分布式和集群单独区分,而是统称:分布式架构

微服务架构的引入

在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,服务的调用关系也会越来越复杂我们可以把一些通用的,会被多个上层服务调用的共享业务,提取成独立的基础服务,组成一个个微小的服务,这就是微服务

简单来说,微服务就是很小的服务.小到一个服务只对应一个单一的功能,只做一件事,这个服务可以单独部署运行,微服务之间可以采用RESTRPC协议进行通信

从这个角度来看,微服务架构是分布式架构的一种拓展,这种架构模式下它拆分粒度更小,服务更独立.可以理解为:微服务是一种经过良好架构设计的分布式架构方案

微服务带来的挑战

随着产品的复杂性和流量的增加,技术架构也在不断的发生变化.不论是早期的单体架构,还是现在广泛使用的微服务架构,都是为了更好的服务产品,解决问题

微服务架构带来好处的同时,也面临着一些挑战,从单体服务转向微服务意味着管理更加复杂.下面我们从优势和挑战两个方面分析一下微服务架构

优势

  • 易开发和维护.每个微服务负责的业务比较清晰,体量小,开发和维护成本降低
  • 容错性高.一个服务发生故障,可以使故障隔离在单个服务中,不影响整体服务故障
  • 扩展性好.每个服务都是独立运行的,我们可以结合项目实际情况进行扩展,按需伸缩
  • 技术选型灵活.每个微服务都是单独的团队来运维,可以根据业务特点和团队特点,选择适合的技术栈

挑战

虽然微服务具备很多的优势,但由于服务数的增加,服务治理也是我们面临的巨大挑战

  • 服务依赖.随着服务的数量增多,服务之间的关系也会变得更加复杂.一个服务的更改,需要考虑对其他服务的影响.
  • 运维成本,一个业务流程会涉及多个微服务共同完成,有更多的服务需要编译,部署,运行,甚至可能是不同的编程语言,不同的运行环境,当然也需要集群来处理故障转移等.这对于运维人员而言,挑战是巨大的
  • 开发和测试一个业务流程可能涉及多个微服务共同完成,服务调用引入网络延,不可靠的网络,如可进行容错处理等问题,这对开发和测试而言,难度也会提升
  • 服务监控.在一个单体结构中,很容易实现服务的监控.因为所有功能都在一个服务中,微服务架构下,不仅需要对整个链路进行监控,还需要对每一个服务实现监控
  • 负载均衡,微服务架构中的服务实例数量可能非常庞大,因此需要有效的服务发现和负载均衡机制采管理请求流量和保证高可用性
  • ...

总结

分布式架构侧重于压力的分散,强调的是服务的分散化.微服务侧重于能力的分散,更强调服务的专业化和精细分工.从实践的角度来看,微服务架构通常是分布式服务架构,反之则未必成立.所以,选择微服务通常意味着需要解决分布式架构的各种难题

相关推荐
mumu2lili28 分钟前
k8s namespace绑定节点
java·容器·kubernetes
mikey棒棒棒31 分钟前
基于Redis实现短信验证码登录
java·开发语言·数据库·redis·session
Wanna71541 分钟前
后端开发基础——JavaWeb(Servlet)
java·后端·servlet·tomcat
生产队队长43 分钟前
项目练习:若依后台管理系统-后端服务开发步骤(springboot单节点版本)
java·spring boot·后端
m0_7482368344 分钟前
【wiki知识库】08.添加用户登录功能--后端SpringBoot部分
java·spring boot·后端
nbsaas-boot44 分钟前
Java 在包管理与模块化中的优势:与其他开发语言的比较
java·开发语言
沉默的煎蛋1 小时前
前后端交互过程
java·开发语言·ide·vscode·eclipse·状态模式·交互
Wanna7151 小时前
后端开发基础——JavaWeb(根基,了解原理)浓缩
java·后端·servlet·tomcat
Joeysoda1 小时前
Java数据结构 (链表反转(LinkedList----Leetcode206))
java·linux·开发语言·数据结构·链表·1024程序员节
小扳2 小时前
博客之星2024年度-技术总结:技术探险家小板的一年的征程
java·大数据·spring boot·elasticsearch·搜索引擎·spring cloud·微服务