比喻
小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群,一个配菜师因故请假了,但是其余的配菜师还是该啥就干啥,可能没请假的配菜师任务会被均匀的加量了,但是他们的任务和职责是不变的。
问:可以理解为,一起干同样的事叫集群,分工合作的叫分布式?
答:是的。
问:例子很形象,但是想请教,分布式的几个角色之间是否一定要有前后关系,比如是不是备菜备料的没完成后面的任务就无法开始进行。还是说只是一件事分成多个部分,前后没有依存关系,但是各自无法替代其他人的职务?
答:上述例子确实强调了先后顺序,但是分布式讲的是协作,一个事件发生可以触发多个事件同时进行不同的业务运算,集群中的成员功能是一样的,,分布式中的成员功能不一样。至于依赖要看具体业务,比如银行转账,短信通知模块就不是必须的通知失败也不影响转账。
问:问一下,对于这种注重前后关系的情况,分布式的意义体现在哪里,感觉和不分开没多大变化。
答:1.稳定业务和多变业务分离:比如转账业务不会变,但转账完成后续动作多变,可能发短信,可能发邮件,还有别的奖励,也可能有个短期活动需要处理,如果每次变化都直接加到转账业务里,那就要频繁改动主业务,甚至需要重启,更甚至直接给主业物代码引入了新的bug
2.新业务老业务分离:一块成熟的业务,拓展出来一块新业务,新的业务只需要从老业务里面获取小部分数据或功能,剩下大部分都是很独立的逻辑,老业务模块根本不需要了解新业务模块,如果都堆积到老业务模块里面,笨重又混乱
3.团队隔离:核心业务系统由核心团队管理和维护,非核心业务系统由另外一个独立团队维护,互相暴露少量接口互通,互有边界控制
4.不同硬件需求:有的业务需要大内存,有的需要大硬盘,有的需要更强cpu,有的需要更多集群,根据不同需求分布到更适合的物理设备上,而不是统一配置爱用不用
5.还有更多理由需要分布式,即便是有先后顺序,也会把业务拆分成多个独立子系统,更多知识请百度“分布式”“微服务”“组件化”“模块化”
6.如果你的业务本来就很简单,拆分反而成了负担,也有拆分不合理后面重构合并到一起的
7.“分布式架构”在一体化系统里面相对应的概念是“接口分离原则”,对应的问题就应该是“一个方法就能解决问题,为什么要分开好几个方法或接口”。
问:这样理解,对于分布式来说,系统中某个服务器上的子任务出现问题,整个任务就无法完成。但是分布式技术不是可以避免由于单个节点失效而使整个系统崩溃的危险吗?
答:每个节点都可以通过集群或其他手段保证高可用, 非核心的子业务可以通过熔断或降级手段,让一部分业务短时间不可用,不至于整个系统崩溃,如果分布式两个服务组件是强依赖关系,并且都是核心业务,又没有高可用架构,一定会出问题的。
单体架构
家里生小宝宝啦,由于自己没有照顾小宝宝的经验,所以请了位经验丰富的月嫂。 这位月嫂从买菜,到做饭,洗衣,拖地,喂奶,哄睡,洗澡,换纸尿裤,擦屁股,做排气操,夜间陪护,给奶妈做月子餐等等,全部都做。 这种叫做单体架构。
集群:
什么都做,一个月嫂怎么够呢,肯定忙不过来呀,那就请两个月嫂吧,这叫做集群。
高可用:
有一个月嫂过生日,想请假回去和亲戚打一天麻将。如果只有一个月嫂,她走了,就叫做服务中断了。 但是因为做了集群,有两个月嫂,走了一个,另一个还是能用,虽然相比较吃力一些,但是毕竟还是能用的,这个现象叫做高可用。
分布式:
一个月嫂,一个月的费用基本上都要1万多,还有房贷,还有车贷,生活费用还高,实在是请不起两位啊,那就还是请一位吧。 可是事情那么多,她实在忙不过来,怎么办呢? 那就把爷爷请过来买菜,把奶奶请过来做饭。 这样服务本来仅仅是由月嫂一人提供的,变成了和宝宝相关的由月嫂负责,采购由爷爷负责,餐饮由奶奶负责。 这就叫做分布式了。
低耦合:
做宝宝服务的月嫂去打麻将了,不影响做饭的奶奶。 做采购的爷爷去喝酒了,也不影响月嫂的宝宝服务,这叫做低耦合。
高内聚:
和宝宝相关的事情都是月嫂在做,月嫂兑奶方式快慢,只会影响自己,对爷爷和奶奶的服务没影响. 这叫做高内聚。
集群+分布式:
奶奶一个人做饭,做久了也烦啊,也累啊,也想打麻将呀。 那么就把姥姥也请过来吧。 这样做饭这个服务,就由奶奶和姥姥这个集群来承担啦。她们俩,谁想去汗蒸了,都有另一位继续提供做饭服务。 这就叫做集群+分布式。

网友评论