分布式和集群 ----- 微服务

本文探讨了分布式系统如何通过任务分解和协作解决中心化问题,集群如何通过负载均衡分担压力,以及微服务架构的特点、优势与挑战。重点对比了分布式与集群的区别,以及微服务在敏捷开发中的应用和潜在问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


分布式

1)我记得在一本讲 tcp/ip 的书上有这样一句话:分布式是指 多个系统协同合作完成一个特定任务的系统。

分布式是解决中心化管理的问题,把所有的任务叠加到一个节点处理,太慢了。

所以把一个大的问题拆分为多个小的问题,并分别解决,最终协同合作。分布式的主要工作是分解任务,将职能拆解。

集群

2) 集群主要的使用场景是为了分担请求的压力,也就是在几个服务器上部署相同的应用程序,来分担客户端请求。

当压力进一步增大的时候,可能在需要存储的部分,mysql 无法面对很多的写压力。因为在 mysql 做成集群之后,主要的写压力还是在 master 的机器上面,其他 slave 机器无法分担写压力,从而这个时候,也就引出来分布式。

分布式的主要应用场景是单台机器已经无法满足这种性能的要求,必须要融合多个节点,并且节点之间是相关之间有交互的。相当于在写 mysql 的时候,每个节点存储部分数据,也就是分布式存储的由来。存储一些非结构化数据:静态文件、图片、pdf、小视频 ... 这些也就是分布式文件系统的由来。

3)集群主要是简单加机器解决问题,对于问题本身不做任何分解;

分布式处理里必然包含任务分解与答案归并。分布式中的某个子任务节点,可能由一个集群来代替;集群中任一节点,都是做一个完整的任务。

集群和分布式都是由多个节点组成,但是集群之间的通信协调基本不需要;而分布式各个节点的通信协调必不可少。

区别:

 将一套系统拆分成不同子系统部署在不同服务器上(这叫分布式),

 然后部署多个相同的子系统在不同的服务器上(这叫集群),部署在不同服务器上的同一个子系统应做负载均衡。 

分布式:一个业务拆分为多个子业务,部署在多个服务器上 。 

集群:同一个业务,部署在多个服务器上 。

什么是微服务?

维基上对其定义为:一种软件开发技术- 面向服务的体系结构(SOA)架构样式的一种变体,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据上下文,选择合适的语言、工具对其进行构建。

微服务架构的优势

使用微服务架构能够为我们带来如下好处:

1)服务的独立部署

每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。

2)服务的快速启动

拆分之后服务启动的速度必然要比拆分之前快很多,因为依赖的库少了,代码量也少了。

3)更加适合敏捷开发

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可,不用整体重新发布。

4)职责专一,由专门的团队负责专门的服务

业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。

5)服务可以动态按需扩容

当某个服务的访问量较大时,我们只需要将这个服务扩容即可。

6)代码的复用

每个服务都提供 REST API,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。

微服务架构的劣势

微服务其实是一把双刃剑,既然有利必然也会有弊。下面我们来谈谈微服务有哪些弊端,以及能采取什么办法避免。

1)分布式部署,调用的复杂性高

单体应用的时候,所有模块之前的调用都是在本地进行的,在微服务中,每个模块都是独立部署的,通过 HTTP 来进行通信,这当中会产生很多问题,比如网络问题、容错问题、调用关系等。

2)独立的数据库,分布式事务的挑战

每个微服务都有自己的数据库,这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务,可以选择适合自身业务的数据,比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。

缺点就是事务的问题了,目前最理想的解决方案就是柔性事务中的最终一致性,后面的章节会给大家做具体介绍。

3)测试的难度提升

服务和服务之间通过接口来交互,当接口有改变的时候,对所有的调用方都是有影响的,这时自动化测试就显得非常重要了,如果要靠人工一个个接口去测试,那工作量就太大了。这里要强调一点,就是 API 文档的管理尤为重要。

4)运维难度的提升

在采用传统的单体应用时,我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了,但这在微服务架构下是行不通的。当业务增加时,服务也将越来越多,服务的部署、监控将变得非常复杂,这个时候对于运维的要求就高了。



参考:微服务是什么?它的优缺点有哪些?

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值