微服务化的大坑之一:当dubbo神器碰上共用注册中心和错误的暴露接口

  dubbo是国内用比较多的微服务化系统,非侵入(意思就是说不用自己写代码,把xml配置好就可以用了,这个xml的引用注解就注在springboot的开启main类里面就可以了),提供好用的均衡和容错机制,使用RPC通信加快响应速度(适用于多次小数据请求,如果是大的用rmi或http交互更好),对中小网站的优化还是好用的。

  但是不是什么系统和什么接口都可以放dubbo上微服务化,以及不要错误地使用dubbo。

  举个例子,有个springboot+dubbo系统在SVN上使用的是服务器的zookeeper注册中心,由于SVN上的代码会被jenkins实时部署到服务器上,这个zookeeper注册中心就有了服务器的那些服务。放在本地测试的话,由于本地的系统用的是服务器的注册中心,本机和服务器的消费者(api)都有可能被分配到对方的生产者(service),导致返回错误数据。

  那时我就碰到这个问题。。。还想着用redis做注册中心,结果没注册成。把本地系统的数据库链接改到服务器上后,数据不统一的问题解决了,但是token错误还是没解决。

  这个问题一直困扰着我,直到自己在本地搭zookeeper并把注册中心搭在本地zookeeper才解决。

  打开本地的dubbo-admin,看服务列表才发现了问题。

  系统验证用户登录和授权用户秘钥,都是使用redis这个数据库储存的token,而验证token的接口,com.heiho.redis.common.RedisCommand,它的实现是放在service端,不是直接接收http请求的api端,这个操作也开了接口给dubbo,结果验证这个操作也是要经过dubbo,会被随机请求到不同地址。服务器端的redis地址和本地的redis地址都设的localhost,这导致了这2个生产者请求的redis数据源不同,同样的帐户密码,在不同数据库储存的密钥是不同的。

  解决方法:要么像我一样开zookeeper在本地,然后把注册中心改到本地;要么这个系统的dubbo配置文件要改,至少com.heiho.redis.common.RedisCommand在api端一定要实现一个,并且不通过请求生产者的服务获得秘钥

原文地址:https://www.cnblogs.com/dgutfly/p/10482671.html