JFinal 中使用 Dubbo —— 3 集群
博客专区 > 糊搞 的博客 > 博客详情
JFinal 中使用 Dubbo —— 3 集群
糊搞 发表于3年前
JFinal 中使用 Dubbo —— 3 集群
  • 发表于 3年前
  • 阅读 10917
  • 收藏 245
  • 点赞 22
  • 评论 25

【腾讯云】如何购买服务器最划算?>>>   

摘要: 很多人认为,既然有了JFinal,为什么还要Spring。殊不知一些基于Spring的很牛X的东东集成到JFinal中能够事半功倍。比如Dubbo这个高性能优秀的服务框架,它基于Spring,于是JFinal提供的Spring插件就能更方便地将Dubbo集成进咱们的程序中,成为高大上的程序...

1. 集群

1.1. 部署结构

下面是一个简单的Cunsumer端服务器和Provider端服务器分别集群的部署图:

在个人开发机上,实现Cunsumer端服务器集群难以实现,所以此Demo中只实现Provider端服务器集群,Cunsumer端服务器集群请读者在有条件的情况下自行实践。

 

1.2. 部署Dubbo管理控制台

Dubbo管理控制台的部署相当简单,由于开发机是Windows 7系统,所以此处也只介绍Windows环境下的部署过程。

具体步骤如下:

  • 独立出一个Tomcat环境,将“dubbo-admin-2.5.3.war”(文件放在JFinalDubboDemoApi项目)中所有的文件解压到新Tomcat的“webapps\ROOT”下(原ROOT文件夹下的所有文件都要删除)。

  • 编辑“webapps\ROOT\WEB-INF\dubbo.properties”文件。

dubbo.registry.address=multicast://224.5.6.7:2181

dubbo.admin.root.password=root

dubbo.admin.guest.password=guest

修改第一个配置项就好,设置的值要与consumer.xmlprovider.xml中“dubbo:registry”标签的“address”值相同。后面两行分别是root用户和guest用户的密码。

提示,可以是RedisDubboMultiCatZooKeeper之间的一种。

  • 启动控制台

    执行Tomcat.bat


1.3. 启动Cunsumer和多个Provider

  • 首先按前面非集群的方式分别启动CunsumerProvider端的Tomcat

注意:加上Dubbo管理控制台就是3Tomcat实例被启动,不要让端口冲突。

  • 用一般Java应用方式启动多个Provider

到了这里,Provider中创建启动类的作用就显现出来了。修改provider.xml中“dubbo:protocol”的“port”属性为“20881”(一定要确保修改后立即保存),右键点击“DemoProviderApp.java”,以“Run As - Java Application”方式启动Provider

 

重复上面,再次修改“port”属性为“20882”(再加1),启动Provider

打开Java控制台,可以看到,2Tomcat应用和2个一般Java应用在运行:

 

再修改,再启动。。。。。。随读者意,只要电脑能承受即可。

 

  • 访问Dubbo管理控制台

浏览器中打开“http://192.168.1.100:8080/”,输入用户名和密码均为“root”后,进入主页面:

 

 

  • 查看提供者、消费者

点击主页中的菜单:

 

进入提供者信息页:

 

可以看到3提供者,它们的端口与启动配置相同。读者自行点击消费者页面,这里就不再浪费篇幅了。

 

  • Provider的集群配置

点击“负载均衡 新增”:

 

在打开的页面中如下配置:

 

完成后可看到一条负载均衡配置:

 

细心的读者可能就已经发现了,负载均衡配置居然是细到每个接口上的。没错,Dubbo不亚于Spring一类的存在,它有太多强大的东东没有在此文中出现,等待各位去发掘。

我们回头再来看看Dubbo存在的背景,瞬间再次觉得高大上啊~~~

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

·单一应用架构

· 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。

· 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

· 垂直应用架构

· 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。

· 此时,用于加速前端页面开发的 Web框架(MVC) 是关键。

· 分布式服务架构

· 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。

· 此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

· 流动计算架构

· 当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。

· 此时,用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

Ø 验证负载均衡

验证就简单了,在JFinal DemoBlog List页面中,频繁刷新。可以看到,每个Provider服务都在刷新3次时出现操作Sql,说明轮询方式的负载均衡策略已经起作用了。读者可切换不同的负载均衡策略再试试看效果,条件好的还可用测试工具测试下性能,那感觉,一定爽。

 

provider中通过配置方法也可以实现集群,而不用在Dubbo管理控制台中手动设置,此问题就留给读者自己摸索。笔者就不再教了,授人以鱼不如授人以渔,瞬间觉得自己好高大。。。。。。

 

1.4. 问题及解决方案

1.4.1. 多网卡问题

笔者的开发机多网卡时上遇到了问题,因为装了VMWare,所以有了虚拟网卡,在使用集群时,被IP不正确的问题搞得灰头土脸。

不打算在这里说明如何解决,因为不要期待他人帮你解决所有问题,很多问题得靠自己。。。。。。(好吧,笔者承认真实原因是不想打字了)


源码地址:

JFinalDubboDemoApi.zip

JFinalDubboDemoConsumer.zip

JFinalDubboDemoProvider.zip



Dubbo文档:

Dubbo 的文档镜像


找了一阵没找到dubbo-admin-2.5.3.war,因为太大没有直接上传到OSC。下面是CSDN分享的dubbo-admin-2.5.4.war,笔者没验证过,应该是可用的:

dubbo-admin-2.5.4.war


系列文章:

JFinal 中使用 Dubbo —— 1 改造JFinal Demo

JFinal 中使用 Dubbo —— 2 部署及运行

标签: JFinal Dubbo Spring Druid
共有 人打赏支持
粉丝 79
博文 5
码字总数 10741
评论 (25)
chencliff
dubbo最新的版本也是2012年的,应该是已经不更新了吧
糊搞

引用来自“chencliff”的评论

dubbo最新的版本也是2012年的,应该是已经不更新了吧
应该还在维护吧,但是很久没看到更新了
lims
可用dubbox
Tom-Lin
到这里看看:https://github.com/alibaba/dubbo,20天前,还修改过 README ,所以估计还是有维护的。只是很多人问问题,没人回答了
糊搞

引用来自“Tom-Lin”的评论

到这里看看:https://github.com/alibaba/dubbo,20天前,还修改过 README ,所以估计还是有维护的。只是很多人问问题,没人回答了
在国内做开源很难,因为绝大多数人只想索取而不知回报。。。 关注和推动都需要人,但大家都在拼命赚钱,没有时间搞这些。另外,阿里的开源很多,人手也不够呀。毕竟人家是商人,不是搞慈善的。。。
糊搞
Dubbo还真没有人维护了,下面的链接里已经说了原因。。。
http://www.oschina.net/news/55059/druid-1-0-9
千峰
现在
干死it
支持下,想用
秦利明
糊搞叔叔,21
紫电清霜

引用来自“秦利明”的评论

糊搞叔叔,21
么么哒
uknow8692

引用来自“秦利明”的评论

糊搞叔叔,21
小明,知道我是谁吗,我可知道你是谁。
秦利明

引用来自“秦利明”的评论

糊搞叔叔,21

引用来自“uk8692”的评论

小明,知道我是谁吗,我可知道你是谁。
鑫酱
还是相信爱过
可以通过host指定发布服务的ip
糊搞

引用来自“还是相信爱过”的评论

可以通过host指定发布服务的ip
指定了Host,但还是出问题,不知道是不是虚拟网卡才这样。。。
CapJes
很不错。
云端之泽
博主,我在按照你的流程整合jfinal和dubbo的时候,发生了spring插件启动报错:
Plugin start error: com.jfinal.plugin.spring.SpringPlugin. |Error creating bean with name 'cn.gh.duboo.demo.service.BlogService': Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError

尝试替换spring或者dubbo的版本,没有效果。请问你有遇到过这类问题吗?
糊搞

引用来自“云端之泽”的评论

博主,我在按照你的流程整合jfinal和dubbo的时候,发生了spring插件启动报错:
Plugin start error: com.jfinal.plugin.spring.SpringPlugin. |Error creating bean with name 'cn.gh.duboo.demo.service.BlogService': Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError

尝试替换spring或者dubbo的版本,没有效果。请问你有遇到过这类问题吗?
是用文章中提供的源码试验的么?
zxdouzx
hello, 我在用到这个dubbo admin 发现如果我手动把某一个provider的进程删了,但是dubbo- admin上不会有实时的响应, 还是展示出来有这个provider, 但是如果我把dubbo admin这个tomcat 重启一下 就看不到了, 我没看源代码, 是不是他的信息不是实时的?刷新页面不是实时的获取zookeeper下最新的节点信息么?
糊搞

引用来自“zxdouzx”的评论

hello, 我在用到这个dubbo admin 发现如果我手动把某一个provider的进程删了,但是dubbo- admin上不会有实时的响应, 还是展示出来有这个provider, 但是如果我把dubbo admin这个tomcat 重启一下 就看不到了, 我没看源代码, 是不是他的信息不是实时的?刷新页面不是实时的获取zookeeper下最新的节点信息么?
这个我没有研究过,不过,据我了解的远程服务类软件,并不是说在你刷新监控页面时实时获取远程服务的状态。因为,远程服务由于网络原因或机器资源占用的原因,响应很慢,是不是监控页面需要等待更长时间?明显不合理。。。 一般都是有一种类似定时检测的手段,也就是每隔一定时间去Ping一下远程服务,或由服务提供方每隔一定时间将自己的状态告知。Dubbo明显用的是后者,在你将某一个provider的进程删除时,provider已经不存在了,无法通知给Admin,于是你看到的监控页面上还是存在有这个provider。。。
zxdouzx

引用来自“zxdouzx”的评论

hello, 我在用到这个dubbo admin 发现如果我手动把某一个provider的进程删了,但是dubbo- admin上不会有实时的响应, 还是展示出来有这个provider, 但是如果我把dubbo admin这个tomcat 重启一下 就看不到了, 我没看源代码, 是不是他的信息不是实时的?刷新页面不是实时的获取zookeeper下最新的节点信息么?

引用来自“糊搞”的评论

这个我没有研究过,不过,据我了解的远程服务类软件,并不是说在你刷新监控页面时实时获取远程服务的状态。因为,远程服务由于网络原因或机器资源占用的原因,响应很慢,是不是监控页面需要等待更长时间?明显不合理。。。 一般都是有一种类似定时检测的手段,也就是每隔一定时间去Ping一下远程服务,或由服务提供方每隔一定时间将自己的状态告知。Dubbo明显用的是后者,在你将某一个provider的进程删除时,provider已经不存在了,无法通知给Admin,于是你看到的监控页面上还是存在有这个provider。。。
其实这个admin 就是去读取zookeeper下面的节点信息? 应该是要实时的才对呀, 要不然我删掉某个provider 他都还有显示,而且还可以对它进行操作, 是不是这个是一个阉割版的原因?
×
糊搞
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: