- 搭建一个分布式的项目 RPC类型的框架(Remote project conntection)远程服务调用
- RPC webService
特点
- 开源对本原生代码没有入侵性
- 可以搭建分布式的项目的结构
- 完全采用Spring的配置方式
- 调用元辰的方法就像调用本地的代码一样方便
- 解耦合
zookeeper
这个的配置文件中的信息
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=/tmp/zookeeper
# the port at which the clients will connect
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1- 在bin里面 ./zookeerServer.sh
netstat -ano | grep 2181
介绍一下框架的种类:
- 单一的框架:(orm) object relation mapping
- 特点:单一的系统的架构,使得开发的过程中越来越难以维护
- 当网站的流量小时,只需要一个web应用,节省了服务器节点的部署,大大节省成本
- 垂直的应用的框架(mvc) modle view controller
- 这样就将这个web的框架分为了三层的结构,这样 三层的开发的模型,系统的体积可控,而且分结构的开发,大大提升了开发效率
- 但是在垂直架构中相同逻辑代码需要不断的复制,不能复用。
分布式应用的架构 (rpc)
- 当垂直的架构应用越来越多时候应用之间的交互必然增多 ,最后只会形成一个服务中心,我们可以跨越服务器之间的调用
- 这样我们需要考虑几个问题:
- 我们将核心的服务抽取出来,并且让他暴露出来,让其他的服务器进行调用这个服务
- 通信问题:dubbo框架的核心就是zookeeper :zookeepr设置了自身的协议这种的通信tcp类似rpc的协议
- 寻址问题:我们如何去寻中对方服务器的方法
- 序列化和反序列化:跨服务器的调用对象,一定设计到对象的序列化和反序列化
Dubbo框架:
- provider 可以暴露服务作为服务的提供方
- consumer 远程服务的调用服务
- registry 服务的注册于发现的注册的中心
- monitor 统计服务的调用的次数和调用
-Dubbo注册中心: - Multicast 注册中心
- zookeeper注册中心
- redis 注册的中心
- simple注册中心
- 我们这次只使用simple 的注册的方式
- 对于Dubbo的框架的优点:
- 透明的调用远程的方法
- 软负载均衡以及容错机制(可在内网中代替nginx 的硬件的负载均衡)
- 项目的结构分为三大模块:
- dubbo-common dubbo的公共接口
- dubbo-cusummer :调用的远程的服务
- dubbo-provider 提供远程的服务
- 这种结构让我联想到了装饰者模式设计,定义一个公共的接口,两个实现类,一个类作为另 一个类的参数进行修饰(在这里就是调用,只不过没有实现通信以及寻址的访问)
- 项目的结构如下:
- 在公共接口中添加抽象方法:并且在实现类中实现该方法。
接口中的抽象方法:
1
2
3
4
5
6
7
8
9
10package service;
import java.util.List;
public interface UserService {
public List<String> select();
public String insert();
}服务的提供者实现方法,并将方法进行暴露
1 | package service.impl; |
- 服务的消费者进行调用服务:
1 | package test; |
maven的project 的引入的jar :
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> |
- 提供服务spring的配置
1 | <?xml version="1.0" encoding="UTF-8"?> |
- 读取配置文件,当然这个要在web容器里要配置在web.xml里配置servlet进行读取配置
1 | package test; |
- constomer的消费者的Spring的配置文件:
1 | <?xml version="1.0" encoding="UTF-8"?> |
- 通过公共的接口进行调用这个接口中的方法
1 | package test; |
- 通过方法进行调用方法:
1 | package test; |
- dubble框架的实现:
- 通过配至服务器的zookeeper的,将conf的文件下到的simple文件修改为:
- 启动zookeeper,运行本地的程序provider的程序暴露所需要远程的调用 的服务
- 消费者在本地调用服务
- 运行结果:
在服务器添加一个web应用就可以实现对服务的管理,包括设置服务 器的均衡,以及当前的服务的状态以及provider和consummer的状态。
提供者:
- 服务的发布者:
- zookeeper的作用的其实就是:在这个链接两个Spring的容器:对他们的Spring之间通信rcp的协议,这样实现两个接口的调用。而dubbo框架的核心,最后实现一个服务跨服务器之间的调用。