一文了解SOA-Dubbo,RPC,Zookeeper相关

Dubbo，RPC，zookeeper相关

Dubbo流程图

节点角色说明

• Provider：暴露服务的服务提供方。
• Consumer:调用远程服务的服务消费方。
• Registry:服务注册与发现的注册中心。
• Monitor:统计服务的调用次数和调用时间的监控中心。
• Container:服务运行容器。

调用关系说明

• 服务容器负责启动，加载，运行服务提供者。
• 服务提供者在启动时，向注册中心注册自己提供的服务。
• 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

词注

• 0.start:容器-》启动-》提供者

• 1.registry：注册到注册中心

• 2.subscribe:订阅-》所需服务

• 3.notify:通知

• 4.invoke:远程调用

• 5.count:计数

远程调用流程

口述

首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持
睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信
息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继
续进行。

实操

• 准备好注册中心，zookeeper,nacos
• 在需要暴露的逻辑层加上dubbo的@Service(interface=)和@Component注解
• 在需要消费服务的逻辑层加上@Reference(interface=)注解来进行消费
• 正常的编写业务逻辑

RPC 原理

RPC协议(Remote Procedure Call Protocol)

远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。

调用流程

首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC框架

在单机时代一台电脑运行多个进程，进程之间无法通讯，显然这会浪费很多资源，因此后来出现IPC(Inter-process communication：单机中运行的进程之间的相互通信)，这样就能允许进程之间进行通讯，比如在一台计算机中的A进程写了一个吃饭的方法，那在以前如果在B进程中也要有一个吃饭的方法，必须要在B进程中进行创建，但有了RPC后B只需要调用A进程的程序即可完成，再到后来网络时代的出现， 大家电脑都连起来，这时可不可以调用其他电脑上的进程呢，当然可以，这样RPC框架就出现了。严格意义上来讲：Unix的生态系统中RPC可以在同一台电脑上不同进程进行，也可以在不同电脑上进行；而在windows里面同一台电脑上不同进程间的通讯还可以采用LPC(本地访问)。综上：RPC或LPC是上层建筑，IPC是底层基础。

RPC框架有很多：比如 JAVA RMI 、 Thrift 、 Dubbo 、 grpc 等。

RPC与HTTP、TCP/UDP、Socket的区别

TCP/UDP:都是传输协议，主要区别是tcp协议连接需要3次握手，断开需要4次挥手，是通过流来传输的，就是确定连接后，一直发送信息，传完后断开。udp不需要进行连接，直接把信息封装成多个报文，直接发送。所以udp的速度更快，但是不保证数据的完整性。

Http:超文本传输协议是一种应用层协议，建立在TCP协议之上。

Socket:是在应用程序层面上对TCP/IP协议的封装和应用。其实是一个调用接口，方便程序员使用
TCP/IP协议栈而已。程序员通过socket来使用tcp/ip协议。但是socket并不是一定要使用tcp/ip协议，
Socket编程接口在设计的时候，就希望也能适应其他的网络协议。

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。所以RPC的实现可以通过不同的协议去实现。

为什么选择RPC

那RPC最大的优点，或者说它相比简单的HTTP接口，它的优势、更适合它的业务场景是怎样呢？简单的HTTP又哪里不足，哪些场景明显不太适合呢？

http接口是在接口不多、系统与系统交互较少的情况下，解决信息初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销(这个问题在http2.0已经被解决不再算是问题了)；其次就
是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，RPC框架是一个强力的支撑。

RPC是一种概念，http也是RPC实现的一种方式，用http交互其实就已经属于RPC了。

但是我们为什么要应用RPC层呢？

• 灵活部署
• 解耦

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。

zookeeper简介

zookeeper是什么？

zookeeper是一个开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。

它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护，域名服务，分布式同步，组服务等。

在我的工作中，就是当注册中心使用。

服务注册中心，给客户端提供可供调用的服务列表，客户端在进行远程服务调用时，根据服务列表然后选择服务提供方的服务地址进行服务调用。

Zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbo 服务的注册中心，工业强度较高，可用于生产环境。

树型图

注册程序说明：

• 服务提供者启动时：在目录下写入服务URL地址 /dubbo/com.foo.BarService/providers
• 服务使用者启动时：订阅以/dubbo/com.foo.BarService/providers获取提供者的URL地址。同时，在下写入使用者的URL地址/dubbo/com.foo.BarService/consumers。
• 监控中心启动时：订阅/dubbo/com.foo.BarService所有提供者和使用者的URL地址。

支持以下功能：

• 当提供程序意外停止时，注册表服务器可以自动删除其信息。
• 注册表服务器重新启动后，所有注册数据和订阅请求都可以自动恢复。
• 当会话到期时，所有注册数据和订阅请求都可以自动恢复。