简单的rpc服务, 最基本的有个consumer(消费者), privoder(生产者), zekeper(注册中心)
大致逻辑: 各个privoder将自己的服务注册到zk上 ,从 zk获取服务, 我们消费者根据zk注册的信息,调取服务.
涛哥讲新框架和学生管理思路
rpc,dubbo相关部分
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O5FW0rV6-1624699123567)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210626155326405.png)]
随着流量增大, 并发量增大,
把系统部署到不同服务器, 会有一个问题, 究竟请求到了哪个服务器上, 怎么样管理一堆多服务器?
随着不断设计,出现一个rpc的东西 , rpc叫远程过程调用… 远程过程调用 就像在本地调用一样,去调用远程服务器的东西… 比如由远程服务器计算,处理. 我在本地调用, 很显然是一个网络请求, 是从一个 机器到另外一个机器… 另外一个机器通过网络把数据转发给我们…
如上图例子: 比如A我的电脑作为服务器乙, 消费者, consumer, 作为controller发请求
B电脑, 生产者provider接收到请求,返回响应
C电脑, 生产者,也返回响应
举例子:项目, 我们学生端的cosumer 可以调用老师端,管理员端等各个生产者的接口, 完成业务逻辑.
这样流量由原来的一个服务器支撑,转化为多个服务器支撑, 这种部署形式, 有助于服务对外提供.
也就说 我们学生端能支撑更多的流量, 因为我们本地学生端不参与计算,不参与存储xxx, 把床铺消耗内存的这些行为放到其他服务器上
若每次增加一个服务器,都得在 消费者服务器 增加 ip地址, 要是添加百千台, 会出现各种问题.
于是我们引入zookeper, 这些ip维护等,可以交给中间商zookeper自动处理. 新加几个服务器d,e,f 都会向zookeper注册,自己提供哪些服务… 比如服务器e有上百个方便面服务, 都注册到zookeper 我学生端需要方便面服务, 都拿到根据既定策略 选择我需要的那些方便面.
和redis关联
学生管理项目
consumer类似于基础consumer的一个东西.