目录
1.概述
2.单机服务器
单机版的服务器的性能,设计上的瓶颈?
3.集群
解决瓶颈1:
没有解决瓶颈2:
没有解决瓶颈3:
集群的优点?
集群的缺点?
4.分布式
分布式的优点?
分布式面临的问题
编辑1、大系统的软件模块该怎么划分?
2、各模块之间该怎么访问?
1.概述
集群:每一台服务器独立运行一个工程的所有模块。
分布式:一个工程拆分了很多模块,每一个模块独立部署运行在一个服务器主机上,所有服务器协同工 作共同提供服务,每一台服务器称作分布式的一个节点,根据节点的并发要求,对一个节点可以再做节 点模块集群部署。
以服务聊天器为例,来讲解单机,集群,分布式
2.单机服务器
我们把这个单机聊天服务器取名为server。
把用户管理,好友管理,群组管理,消息管理,后台管理等模块构成我们的聊天服务器。每个模块都包含了很多特定的业务。特定的业务:用户管理模块有用户登录,用户注册,用户注销,用户退出等功能业务。好友管理有添加好友,删除好友等功能业务。群组管理有添加群,创建群,解散群,群里踢人等功能业务。消息管理有离线消息,一对一的消息,群组消息等和功能业务。后台管理有广播消息,公告消息,活动消息等功能业务。这些功能业务都对应了一个或多个完成这些业务的相关的函数。
单机版的服务器的性能,设计上的瓶颈?
1、受限于硬件资源。因为我们只有一台服务器,聊天服务器所能承受的用户的并发量是有限的。假设我们使用32位linux操作系统做一个聊天服务器,给一个进程把资源开满,最多支持2万多人的在线。用户量上不去了。硬件资源不够,socket资源不够,客户端无法与服务器建立连接,不可能给更多的客户端提供服务。
2、任意模块的修改都会导致整个项目代码重新编译,部署。假设这个服务聊天器有5个模块,每个模块有几十上百个功能业务,这一套项目编译得花2个小时,部署得花3个小时。现在如果我们突然发现用户管理模块有个注销的业务里面有bug,但是改起来特别简单,就几行代码。但是这是一整套系统,得把整个项目的所有代码全部重新编译!这样又得花2个小时编译,运维部署3个小时!成本较大,耗时。理想状态是,某个模块的代码出问题了,修改后只把这个模块编译一下就行。
3、系统中有些模块是属于CPU密集型(计算量大的),有些模块是属于I/O密集型的(这些模块会接触输入输出,网络I/O),造成各模块对硬件资源的需求是不一样。 有些模块是CPU密集型的,这些模块应该部署在CPU资源非常好的机器上,有些模块是I/O密集型的,应该部署在内存大,带宽好的机器上,不需要太强的CPU资源。不同模块属于不同的密集型(CPU密集型、IO密集型等),对硬件的需求不一样,把它们都打包在一套机器上,只能综合所有模块,提出平衡的供给需求,没办法针对性部署硬件资源。
3.集群
前端需要一个负载均衡器,直接扩充机器数量。每一台服务器独立运行一个工程的所有模块。
解决瓶颈1:
我们扩充了硬件资源。在水平方向上直接扩充成3台机器。每个机器独立运行着一台聊天服务器程序。
没有解决瓶颈2:
但是每一台机器都还是独立运行着一套聊天服务器系统程序,现在对任意模块的修改,得把整套代码重新编译,因为模块根本没有分开去部署,都是在一个项目中部署,运行在一个服务器进程中。
编译一套代码,做多次部署。因为我们扩充成3台机器了!更加头疼
没有解决瓶颈3:
集群只是水平的去扩展了硬件的机器,每一台机器还是运行着一台独立的聊天服务器程序。假如server2出问题,不影响聊天,因为server1和server3还可以独立地提供聊天服务,因为是独立的服务器。
集群的优点?
1、操作简单,在一台机器上部署和在多台机器上部署的方式是一样的,再加一个负载均衡器就行。
性能提升了,用户的并发量提升了,因为水平扩充了硬件资源。
集群的缺点?
1、项目代码还是需要整体重新编译,而且需要进行多次部署。
2、并不是说机器多,并发量就上来,性能就高。像后台管理模块,这个模块使用的用户是不多的,能在聊天系统上发布公告,只有管理员,像学校的校长才能发布公告,而且后台管理员根本不需要高并发,但是把这个模块部署在3台服务器上,就太浪费了!,像这些不常用的模块只需要部署在一台机器上就好啦。
4.分布式
分布式:把这些管理模块抽出来,单独部署在不同的机器上。
从集群上看的话,server2挂掉,还有完整的聊天服务器系统server1,server3。
但是在下图的分布式上,对于红色圈,3台机器上分别运行着不同的模块,少了这3台机器的任意台,聊天系统就缺失了相应的业务了!所有机器共同构成一个聊天服务器系统。这就是分布式。
一个工程拆分了很多模块,每一个模块独立部署运行在一个服务器主机上,所有服务器协同工作共同提供服务,每一台服务器称作分布式的一个节点,根据节点的并发要求,对一个节点可以再做节点模块集群部署。
集群:每一台服务器都运行了一个独立的系统。
分布式:所有的机器共同构成了一套系统,一套系统被分成了不同的模块,不同的模块根据具体的需求被部署在不同的机器上。
分布式的优点?
解决瓶颈1
用户登录成功,为了支持登录的并发量,我们可以把分布式节点1集群,扩充机器来部署运维用户管理,消息管理。
比如说后台管理这个模块不需要高并发,一台机器足以!
甚至我觉得用户管理模块(登录,退出)需要更多的并发量,没有人整天加好友删好友,建群,解散群。登录,退出,聊天应该做的是最多的,我们可以在server2节点上再部署用户管理,消息管理这2个业务功能。
在server2中,当好友管理和群组管理无法使用完server2的网络I/O资源的时候,用户管理和消息管理可以再享受多余的server2的网络I/O资源提供给更多的客户端进行登录登出的聊天服务。
解决瓶颈2
2、因为分布式将模块从总体的进程中,拆分出来了,每一个模块编译成了独立部署,独立运行的一个小的服务,假设后台管理模块出问题,只需要将后台管理模块重新编译就行了,我只需要把server3这台机器的后台模块重新更新就可以了,其他模块不需要更新。
由此可知,模块拆分出来了,解决瓶颈3
3、把CPU密集型的模块部署在CPU资源好的机器上。把I/O密集型的模块部署在CPU不是很好的机器上。
解决集群缺点2
有的模块要求并发能力高,可以进行多机器集群部署。有的模块并发能力小,部署在一台机器就足以。
配置着高可用,容灾的主备服务器,不用担心就一套系统挂掉了怎么办。
分布式面临的问题
1、大系统的软件模块该怎么划分?
各模块可能实现大量重复的代码!
模块和模块之间的界线不清晰(有的模块里面的函数调动另一个模块的函数代码)。
处理不好,造成大量重复代码。而且你改你的,我改我的,重复的公共代码就出问题了,变成不可控制了。
2、各模块之间该怎么访问?
因为现在各模块可能运行不在一个机器上,或者不在一个进程上。
如果用户登录成功了,想展示好友列表,但是用户管理模块只负责用户的登录,退出,注册、修改密码等业务功能,它并不知道好友列表,负责管理好友的是好友管理模块。通过传入用户id,得出好友列表。在单机或者集群中,这些模块是运行在一个服务器进程当中,相当于自己调用自己。但是在分布式中,用户管理和好友管理部署在不同的进程中,用户管理进程如何调用另一个模块上的业务呢?
机器1上的模块怎么调用机器2上的模块的一个业务方法呢?(软件设计师通过经验来解决)
机器1上的一个模块进程1怎么调用机器1上的模块进程2里面的一个业务方法呢?
涉及网络传输,携带区分函数的标识,包括函数的参数,函数命名等一些数据,全部通过网络发送过来,另一台机器便知道有别的机器想要调用我的方法,将传递过来的参数等数据代入执行,执行之后将返回值通过网络返回。
通过网络! 处理网络请求。网络是否有问题?如何告诉调用者网络的情况?
我们这个项目要做的就是把这些封装成一个分布式的通信框架,然后把这套框架给到用户,用户如果想要进行一个模块分布式的部署,在不同的分布式节点1,想要调用分布式节点2的代码,对于用户来说,他调用远程的方法就跟调用自己本机的方法一样简单方便,不用去关注一些具体的细节