根据之前的命名服务,重新构建了下服务框架;数据库
结构模式;c-center-s;json
1.服务端:缓存
服务端启动,讲本身的IP,端口注册到注册中心节点(master),而后注册本身的处理类(须要继承对应接口);session
同时须要设置服务类型(是不是主从服务,若是是主从服务还须要设置本身是不是master);负载均衡
若是不是主从服务则中心采用hash负载均衡进行服务调度;框架
同时有心跳给注册中心;工具
2.注册中心大数据
启动注册中心,注册中心是主从方式存在,启动时选举本身为master;而后接收其他注册中心回应,2秒没有收到则认为本身是master进行发布,收到master的回复则更新信息;设计
master节点实时有心跳;blog
主要工做:
1.判断服务状态是否能够用,调度服务;
主从服务时判断master服务,进行数据处理;
多服务认为是须要选择调度,则使用均衡方式;
2.负载均衡服务,调度服务;
3.判断注册中心master节点,随时准备选举新master
3.客户端
客户端直接向注册中心请求:1.请求服务地址,直接与服务通信 2.请求数据传输,直接由中心传递数据 ;同时须要设置是否须要回执数据;
4.通信
整个框架考虑到数据实时传输,大数据量处理,直接采用udp通信;提供了高层封装;
封装的通信层使用了数据分包,按照udp适合的传输包大小设置,你也能够本身调用接口设置分包大小;每包分配了一个ID,同时一次传输认为是一个session,分配seesion的id;
接收端按照数据接收,同时有包丢失时会再次向发送端请求再次发送;
接收端设计了接收发送;
发送端进行了数据缓存,内存中缓存必定时间,接收到接收端完成的ack就清除,不然保持1分钟;直到内存耗尽;
若是是注册中心,数据内存缓存到期还会缓存到本地数据库中(持久化),在本地保持最近10分钟数据;都是timer清除;
采用udp一样也是基于框架功能,不须要链接,能够在使用时能够直接反向发送数据;也能够不发送;
整个通信已经测完成;
5.使用包
本框架使用了goolge工具包guava-22.0,界面库JTattoo-1.6.11,公共序列化包fastjson-1.2.9;持久化数据库BerkeleyDB