做网站标准步骤,腰椎间盘突出压迫神经腿疼怎么治,国内最好的分销平台,上海自贸区注册公司流程目录 1.概述
2.单机服务器
单机版的服务器的性能#xff0c;设计上的瓶颈#xff1f;
3.集群
解决瓶颈1#xff1a;
没有解决瓶颈2#xff1a;
没有解决瓶颈3#xff1a;
集群的优点#xff1f;
集群的缺点#xff1f;
4.分布式
分布式的优点#xff1f;
分…目录 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的代码对于用户来说他调用远程的方法就跟调用自己本机的方法一样简单方便不用去关注一些具体的细节
