微服务化的大坑之一：当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端一定要实现一个，并且不通过请求生产者的服务获得秘钥。