集群/分布式的概念

看视频发现集群好像就就是多个服务器发布提供同样的功能,用来分担一些载重,减少崩坏。

于是发现自己以前都是简单听过这些概念,都没有好好研究下呢。

逛知乎:

回答1:

  作者:wistbean
链接:https://www.zhihu.com/question/20004877/answer/252472988
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

有一天,隔壁小王睡前突然有一个大胆的插法,哦不~ 大胆的想法,他要做一个在线B2C的美女网站,突然发现接下来要发了,可以赢取白富美了,不过他又想到了一个问题:

“想法都有了,就差一个程序员了”!

翻了一会通讯录后发现了楼下的小明就是个程序员啊!于是也不管几点就直接从床上跳起来,穿着拖鞋跑到楼下猛敲小明的房门。

小明这时候正在写代码,被连续的敲门声吓得写了一个bug后就去开门了。

“什么事啊?”

“呀,我是你楼上的小王啊,你还没睡啊?有事找你有事找你”

小王不管不顾的走进去,小明一阵错愕!

“小明”,小王放低了声音,“我有一个项目,绝对能发,现在就差开发了,听说你的技术很牛逼!”

“什么项目?”,小明被小王的神秘语气和一种不知哪来的自信引起了兴趣!

“一个B2C的美女网站,用户可以购买美女的时间,比如买11月15号的下午14:00-16:00,然后下订单,美女可以在这两个钟陪用户读书学习 :) ……” 小王绘声绘色,小明却一脸无奈。。

小王知道小明的意思,就继续吹:“到时一定赚钱的,你就是我的合伙人啊,你拿30%”。

小明不为所动…

这时候小王冒出了些许冷汗,转念一想,做出了猥琐的表情说道:“我可是楼上小王哦!”

总之,在小王的威逼利诱下,小明勉强答应了!

小明跟小王聊了5个晚上的需求,有时候聊着聊着就一起睡着了,慢慢理清了思路,就开始干了。

他像以前的开发那样,建立一个web工程,不断往web里边添加功能,比如订单功能,用户管理功能,商品信息管理功能等都丢到web工程里边。

在小王的催促和监督下,经过两个多月,小明终于搞完第一个初始版本!

小明和小王都测试了一遍发现没什么问题,就打算弄个服务器,然后把web项目和数据库都扔到一个tomcat里去。

上线了!!!

小王很开心,看到了自己的想法实现了,并且已经在网上可以找到!

过了好几天,网站的用户量是2,也就是只有他们2个。小王开始急了 - -

小王发现推广很重要,于是去跟他爸爸拿了几百万投放广告,他爸爸刚开始不肯,说不懂互联网,于是小王把网站发给他爸看,他爸就同意了。

小王有钱之后,就去找广告商了,于是慢慢的电视上的综艺节目有了他的美女网站的广告了!

理所当然的用户量开始越来越高了,小明发现,服务器崩了!!

并发量太大,小明觉得一个tomcat已经不行了,于是小明就告诉小王,咱们用户量越来越多了,一个服务器不行,买多两台服务器吧,小王听到用户量增加,开心的答应了。

小明把项目在每个服务器里边都放了一份,然后用nginx代理转发。

就这样可以顶了一段时间…

最近小王在后台上架了一个非常漂亮的美女,导致太多用户访问,服务器又崩了…

小明对小王说:“我们得加强一下服务器配置了,把带宽,内存和cpu都升级吧!”

于是,又顶了一段时间…

过不久又崩了!

小王开始不爽了,对小明说:“怎么搞的?怎么服务器老是不行??”

小明说:“我他妈怎么知道你是个富二代?一开始以为你是闹着玩的,谁知道用户量会增多?”

小王发现小明有点生气了,他想着不能得罪程序员,于是轻声说:“那怎么办?”

“我得重构了!每个tomcat都放着整个web工程,后台访问也就我们两个,没有并发的问题,浪费资源了。模块之间耦合度太高了,其中一个功能升级其他的也都得升级,系统扩展性也差,不能够灵活的去部署”,小明如是说!

小王有点似懂非懂的问:“那怎么重构呢?”

“用分布式!我们把整个项目工程拆分成多个子项目,每个子项目负责自己的功能,例如订单这个功能就是一个单独的系统项目,会员系统也是一个单独的系统。” 小明边说边在纸上画了一张图:

小王依然似懂非懂的问:“这样比之前有多好?”

“这样的话,我们把每个模块都拆分出来,可以灵活的部署了,比如美女商品信息这个模块被访问的量比较大,那么我们就可以单独对这个模块进行服务性能的提升,不用全部都一起提升。也降低了代码的耦合度,模块之间互不影响,这样如果以后有人加入开发,他只要负责他的模块去开发就可以了,合作也高效!” 小明说道。

“那有什么缺点没?”

“有吧,就是各个模块之间需要通信,这时候需要开发接口,增加了些工作量!不过这是值得,总比花钱去买更多服务器配置好吧!”

“恩,有道理有道理!”

于是小明就这样开始重构了他的项目,慢慢的项目的稳定性比之前的好多了。

过了6个月,项目开始盈利了,于是小王开始招兵买马,把小明踢出去。

第二个回答:

作者:大闲人柴毛毛
链接:https://www.zhihu.com/question/20004877/answer/282033178
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

画了一上午,麻烦点个赞~

下面就正经解释下三种结构的区别吧~

单机结构

我想大家最最最熟悉的就是单机结构,一个系统业务量很小的时候所有的代码都放在一个项目中就好了,然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。

那么,单机结构有啥缺点呢?我想缺点是显而易见的,单机的处理能力毕竟是有限的,当你的业务增长到一定程度的时候,单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式,往下接着看。

集群结构

集群模式在程序猿界有各种装逼解释,有的让你根本无法理解,其实就是一个很简单的玩意儿,且听我一一道来。

单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍(有几个节点就相当于提升了这么多倍)。

但问题是用户的请求究竟由哪个节点来处理呢?最好能够让此时此刻负载较小的节点来处理,这样使得每个节点的压力都比较平均。要实现这个功能,就需要在所有节点之前增加一个“调度者”的角色,用户的所有请求都先交给它,然后它根据当前所有节点的负载情况,决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。

集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展,当前的系统又支撑不住了,那么给这个集群再增加节点就行了。但是,当你的业务发展到一定程度的时候,你会发现一个问题——无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用微服务结构了。

分布式结构

先来对前面的知识点做个总结。

从单机结构到集群结构,你的代码基本无需要作任何修改,你要做的仅仅是多部署几台服务器,每台服务器上运行相同的代码就行了。但是,当你要从集群结构演进到微服务结构的时候,之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议,系统设计之初就采用微服务架构,这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话,那就得对代码大动干戈了。所以,对于老系统而言,究竟是继续保持集群模式,还是升级成微服务架构,这需要你们的架构师深思熟虑、权衡投入产出比。

OK,下面开始介绍所谓的分布式结构。

分布式结构就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在分布式结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间通过RPC方式通信。

举个例子,假设需要开发一个在线商城。按照微服务的思想,我们需要按照功能模块拆分成多个独立的服务,如:用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目,可以独立运行。如果服务之间有依赖关系,那么通过RPC方式调用。

这样的好处有很多:

    1. 系统之间的耦合度大大降低,可以独立开发、独立部署、独立测试,系统与系统之间的边界非常明确,排错也变得相当容易,开发效率大大提升。
    2. 系统之间的耦合度降低,从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促,下单量可能会大大提升,因此我们可以针对性地提升订单系统、产品系统的节点数量,而对于后台管理系统、数据分析系统而言,节点数量维持原有水平即可。
    3. 服务的复用性更高。比如,当我们将用户系统作为单独的服务后,该公司所有的产品都可以使用该系统作为用户系统,无需重复开发。
 
第三个回答:
小饭店原来只有一个厨师,切菜洗菜备料炒菜全干。后来客人多了,厨房一个厨师忙不过来,又请了个厨师,两个厨师都能炒一样的菜,这两个厨师的关系是集群。为了让厨师专心炒菜,把菜做到极致,又请了个配菜师负责切菜,备菜,备料,厨师和配菜师的关系是分布式,一个配菜师也忙不过来了,又请了个配菜师,两个配菜师关系是集群
 
谢谢提醒,我的例子确实强调了先后顺序,但是分布式讲的是协作,一个事件发生可以触发多个事件同时进行不同的业务运算,集群中的成员功能是一样的,,分布式中的成员功能不一样。至于依赖要看具体业务,比如银行转账,短信通知模块就不是必须的通知失败也不影响转账
 
问一下,对于这种注重前后关系的情况,分布式的意义体现在哪里,感觉和不分开没多大变化。
 
1.稳定业务和多变业务分离:比如转账业务不会变,但转账完成后续动作多变,可能发短信,可能发邮件,还有别的奖励,也可能有个短期活动需要处理,如果每次变化都直接加到转账业务里,那就要频繁改动主业务,甚至需要重启,更甚至直接给主业物代码引入了新的bug
2.新业务老业务分离:一块成熟的业务,拓展出来一块新业务,新的业务只需要从老业务里面获取小部分数据或功能,剩下大部分都是很独立的逻辑,老业务模块根本不需要了解新业务模块,如果都堆积到老业务模块里面,笨重又混乱
3.团队隔离:核心业务系统由核心团队管理和维护,非核心业务系统由另外一个独立团队维护,互相暴露少量接口互通,互有边界控制
4.不同硬件需求:有的业务需要大内存,有的需要大硬盘,有的需要更强cpu,有的需要更多集群,根据不同需求分布到更适合的物理设备上,而不是统一配置爱用不用
5.还有更多理由需要分布式,即便是有先后顺序,也会把业务拆分成多个独立子系统,更多知识请百度“分布式”“微服务”“组件化”“模块化”
6.如果你的业务本来就很简单,拆分反而成了负担,也有拆分不合理后面重构合并到一起的
7.“分布式架构”在一体化系统里面相对应的概念是“接口分离原则”,对应的问题就应该是“一个方法就能解决问题,为什么要分开好几个方法或接口”
以上不知道是不是你要的答案


作者:张鹏飞
链接:https://www.zhihu.com/question/20004877/answer/112124929
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
 
 
总结:  
架构的转变就如同回答1,最开始是单击结构;用户量增多,负载压力太大,于是就使用了集群(集群就是将同样的功能发布在不同的容器上面,复制一个同样的对象做同样的事情);你增加了服务器进行了集群处理,但是高峰期的波动往往使得你的服务器崩溃,这个时侯全部再次集群的成本过高,你需要将压力部分抽取出来特殊处理,干脆,你就将项目进行拆分,多个子项目进行协作完成这个功能,这就是分布式了,然后针对薄弱的地方进行集群或者其他处理,对症下药,较为完美的解决问题。
集群的好处:
  集群提升了处理能力,拓展方便。
分布式的好处:
  降低耦合,方便排错,开发,测试等
  组件拼接,更易于拓展
  服务易于重复使用
  业务分离:1.稳定业务和多变业务分离;2:新业务老业务分离
  方便团队隔离,保护性
  不同服务不同配置不同处理,针对性开发
 
 
原文地址:https://www.cnblogs.com/aigeileshei/p/8317006.html