非对等模式下各自独立Eureka集群间的通信及负载…

在Service Mesh还不能再生产上铺开的今天，大部分微服务都是基于SpringCloud构建。SpringCloud很好用，Eureka也很好用，但是有个关键问题，Eureka只支持Peer对等模式，也就是说多个Eureka Server之间只能是主备关系，而不能做到分层。

为什么会提到这个问题呢？跨部门协作常常会遇到这样的问题：

部门A和部门B都各自拥有自己的Eureka做服务管理。某天领导拍脑袋说：A啊，B有个公司大力推广的特性，你去对接一下。

A跑去和B商量，B说你调我的服务没问题，但是我不想管理你的服务，你也不会希望我的鉴权、路由影响你的业务，

所以不要把服务挂到我的Eureka上来，并且远程调用的时候你得做负载，要是怼着我一个节点疯狂发请求，我就得嗝屁。

在这样的背景下，两个eureka集群是相互独立的，但又希望A中的服务调B中的服务做到负载均衡，调用方式如A内部调用一样--你是不是想跟领导、B打一架呢？

俗话说双拳不敌四手，况且如果你家里没有矿，我建议还是看看这个项目：https://github.com/wangchaobin/waterfall

Waterfall项目实现的就是这样的场景，大致架构如下：

这个项目是想讲这样一个故事：

1.近卫阵营有两个人Mirana和Jugger开黑，但他们不是两个人在战斗，他们派了Sven去天灾阵营卧底，Sven私下里可以与近卫的人互通信息，悲剧主角Purge是个实实在在的以上分为目标的路人；

2.开局五分钟，下路的Sven对中路的Purge说，我要去中路游走，你磨磨对方血，Purge表示收到；

3.Sven私下对近卫的Mirana说Purge上当了，他以为我要去游走，你们去搞他；

4.中路对位的Mirana收到消息后喊来下路的Jugger帮忙；

5.Jugger绕后，Sven为了不让Purge起疑，告诉Purge说我腿断了，去不了了；

6.Purge无奈表示知道了，然后被Mirana和Jugger击杀。

这个故事的关键在于Sven的实现，由于他本身是eureka client，注册在天灾阵营，包含的common-traitor包又让他可以与近卫阵营互通消息。

 

简单描述一下设计（霁月晚风凉原创，转载请注明来源：https://github.com/wangchaobin/waterfall）：

1.四位玩家都注册在各自的Eureka上，源生的代码逻辑没有修改，因此他们内部可以自由通话：Sven与Purge、Mirana与Jugger；

2.Eureka Server公开了Rest接口，用于获取所有注册信息：http://eureka_address/eureka/app，这是Sven能与Radiant众人通话的基础，实现类是common-traitor的EurekaRepository.java；

3.Eureka上注册信息的模型是Applications，将其转化为了自定义模型EurekaConfig，主要目的是为了让自定义的RibbonLoadBalancer能够复用：在2中获取注册信息时也不能只怼着一个eureka server；

4.对于只在阵营内部通信的Hero：Purge、Mirana、Jugger，他们在手机上加装的设备是SimpleRetryInterceptor，使得他们可以用http://ip:port/context/path和http://serviceId/context/path两种方式访问对应接口；

5.对于需要向近卫阵营通风报信的Sven，他在手机上加装的设备是TraitorRetryInterceptor，它是SimpleRetryInterceptor的升级版，不仅保有SimpleRetryInterceptor的功能，还能以http://serviceId/context/path方式向近卫阵营报信；

6.故事的入口是Sven里的TestController，可以用浏览器试一下，然后观察各微服务日志和统一日志story.log。

 

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有