集中式架构与分布式概念,大白话解释

3分钟读懂系统架构演变 了解时下最火的微服务概念

本人将从大到小给你讲授系统架构的演变(此处的大小不是对比项目的大小,而是单个模块的大小)
集中式架构 → 垂直拆分→ 分布式 → (服务治理) → 微服务
咱们先从最大的来:

集中式架构: 用我的话来讲它最大最笨重了,为什么说它笨重呢,因为它的功能啊,服务啊,所有的代码都写进了一个模块里,如果只是一个小的系统只有几百号人使用的,这样写在一起其实也是很方便的,但是当你写一个比较大的系统时,你的功能块多了,代码量多了 在全部都写在一起,耦合度非常的高,一旦某个地方出了错 整个系统全部都宕机,当你需要调错的时候,因为所有的代码都写在一起,你调起来也不方便。

垂直拆分: 与上一个集中式架构不同的是,垂直拆分将系统中的服务单独的拆分了出来形成一个单独的模块,上图:如图所示,垂直拆分呢就是将独立的服务给单拉出来做成一个独立的系统,这样的玩法不但解决了流量分单,并发访问的问题,还可以针对不同的模块进行优化,方便你在添加新的业务,负载均衡,容错率也提高了许多

在这里插入图片描述

分布式: 就是在上一个垂直拆分的拆分下 进一步的对代码进行简化拆分,打个比方,上一个垂直拆分的两个服务模块,一个用户前端,一个后台管理系统,他们的登录都会用到手机号发短信的这段代码,而在垂直拆分中的做法就是每个模块中都有这么一段代码,而分布式就是将重复写的这段代码再细分出来,写成一个单独发短信的模块,别的模块需要用的发短信就可以直接调用这个模块就行,在垂直拆分的基础上更加优化了代码

服务治理: 当前两个拆分细化代码越来越多,到达一定程度的时候,这个时候的系统的模块之间各种相互调用,关系错综复杂,容量的评估以及小服务对于资源的浪费问题也暴露了出来,这个时候你就需要一个服务中心来帮助你管理,就像是你的一个管家,具体点击最下面的链接

微服务: 在分布式的基础上继续往下分,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。

如果这篇博客帮助到了你,请关注我,我会不定时的分享一些干货的

更加详细: 更具体点可以去看猪精的.

  • 5
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
Java分布式事务是指在分布式系统中,多个独立的服务或应用之间进行数据操作时,保证数据的一致性和可靠性的一种机制。简单来说,就是多个服务或应用在进行数据操作时,要么全部成功,要么全部失败,不会出现部分成功部分失败的情况。 在分布式系统中,每个服务或应用都有自己的数据库,它们之间需要进行数据的读取和写入。当多个服务或应用同时进行数据操作时,可能会出现以下问题: 1. 数据不一致:由于网络延迟或其他原因,某个服务或应用的数据操作成功了,但其他服务或应用的数据操作失败了,导致数据不一致。 2. 并发冲突:多个服务或应用同时对同一份数据进行读写操作,可能会导致数据冲突和错误。 为了解决这些问题,Java分布式事务引入了一些机制和技术,例如: 1. 两阶段提交(Two-Phase Commit):在分布式事务中,引入一个协调者(Coordinator)来协调各个参与者(Participant)的数据操作。在第一阶段,协调者询问各个参与者是否可以提交事务;在第二阶段,如果所有参与者都同意提交,则协调者通知各个参与者提交事务;如果有任何一个参与者不同意提交,则协调者通知各个参与者回滚事务。 2. 分布式事务消息:使用消息队列来实现分布式事务,将数据操作和消息发送放在同一个事务中,保证数据和消息的一致性。 3. 分布式锁:通过分布式锁来控制对共享资源的访问,保证在同一时间只有一个服务或应用可以对资源进行操作,避免并发冲突。 以上是对Java分布式事务的简单介绍,希望能帮到你。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值