啃了n天eureka，其实我个人对他的理解：用起来简单，理解起来抽象。喏，手打不易，大家动动小手分享转发点赞评论啥的~~~~
打个比方：我们知道太阳东升西落是因为地球的自转。但是我们知道为什么地球会自传么？而且为什么是沿着一个方向转而不是来回来去转？好吧~这个我也不知道~~所以谈下一话题，eureka集群是怎么实现的。
电脑自带的画图用不明白~~手画吧。。三个server，两个client，关系如下：
箭头指注册关系
这里说一下server怎么相互注册：
其实每一个服务端（这里指实例）都内置了一个Eureka Client，也就是说一个服务端可以接受其他Client的注册，也可以作为一个Client注册到其他Server上，被其他Client发现和调用。一个服务端实例你可以理解为由一个Server+Client组成。也可以理解为两个容器，他们仅仅在初始化时是一样的ip，端口号，名字等。没有什么其他的联系。
然后我们设置的两个属性：registerWithEureka和fetchRegistry也是对这个实例的client端的配置。
-registerWithEureka：是否要注册到其他Server上。如果我的Server上有一些对外开放的接口，那肯定需要注册啦~这样其他的Client才能发现我的服务。如果我的Server没有提供对外接口，那么这个参数可以设置为false。
-fetchRegistry：是否需要拉取服务信息。和是否注册一样，如果我的Server需要以客户端的身份调用其他的Client的接口，那么就需要获取相应的服务发现信息，这样才能正常的调用。同时这个参数还有一个重要的作用，就是决定Server在初始化时是否立即全量同步其他节点的服务信息！！！Server初始化时会先初始化其内置的Client。若配置了fetchRegistry=true，那么Client在初始化时会从其他Server全量拉取服务信息，放进Client容器中。Server在初始化时会尝试同步Client容器里的服务信息，如果fetchRegistry=false，服务信息不存在，只能被动的等其他Server节点以增量的形式同步过来(Client在执行注册和心跳时对应的注册Server节点会广播此事件，同步给其他的Server节点。当其他Server节点还没有此服务信息时，改为注册此服务信息)。当然正常的通过心跳来同步也可以，是否需要设置此参数就看各自的需求了。
Server和Client节点配置全部的Server地址和部分Server地址区别：
这涉及到了Server节点间的同步机制——Client在与Server交互时，只会与其中的一个Server进行交互。
是个比较绕的事，所以我这里还是用图来解释。
箭头指注册关系
因为上个图节点间关系比较简单不能说明问题，所以我这加了两个客户端和一个服务端。如图上关系。
-首先Server4与Server1互相注册了。所以我们可以通过Server1调用Client3（这是是指直接通过）。也就是Client4可以发现Client3。
-然后注意，重点来了！Server1与Server3，Server4都相互注册了，但是Server3和Server4没有相互注册，所以Client3和Client2是互相发现不了的。
-刚刚图片画的各种问题，我还得加一笔。（看下图理解我说的话）如果client2也在Server1上注册了，因为Server节点间的同步机制所以Client2只能会与1，3中一个交互。
——如果它与Server1交互，这个时候是可以发现Client3的。
——但是如果它与Server3交互，则发现不了Client3.
-还有一种情况。Server4down了。理论上讲Client3就失联了。不过因为Server1中还有c3的信息，所以在Server1中还是可以暂时用用Client3的但是因为client3不会续约所以时间到了就会被踢了（默认90s不续约就踢了）。至于Client3自己，如果在那之前它用过谁还可以继续用~~不过就不动态了，别人发生的变化它得不到通知，而且后续新增的其他服务它也发现不了。
其实这个用一种现实关系打比喻：Server是人。Client是东西。然后东西的给予规则就是只能给信任的人”自己“的东西。所谓的发现就是在讲个东西在一个人家里。
这么想，S1信任S2,S3,S4.所以C4可以在任何人家里。所以C4可以与C1,C2,C3都交互。
然后S4只信任S1，所以C3只会在S4或者S1家里出现。所以C3只能与S1家里的C4,C2交互（反过来想也可以，反正就这个意思）。
然后通俗理解可以这么理解。但是其实形成的原因是：Server之间的服务同步是异步执行的。同时Server之间的同步只会传播一次，它们通过Header里的一个参数来表名是来自Client的请求还是Server的请求。如果是Server的请求，那么接收到此请求后不会再进行传播。所以可以理解是一条线走下来的。这也是client2与Server3交互，则发现不了Client3的原因。
言语表达太无能了~~原谅我语文不好。差不多一天才把语言组织好~~然后我也是看官网做demo还有看各种帖子得出的结论。如果哪里理解错了或者说错了有偏颇欢迎指出纠错~~~欢迎各位留言探讨~~
Server回收服务信息的自我保护机制：
咋说呢，从概念上首先你要明白什么是自我保护机制。如果有不懂的可以戳我前两篇文章：
什么是自我保护机制： eureka术语详解
设置自我保护机制： eureka配置详解
这里要说明的是一个很容易出现又容易被人忽略的问题：我们的微服务可能就几个。比如说5个，然后其中一个down了。eureka的默认阙值是85%。也就是低于百分之八十五的正常率就触发自我保护机制开始怀疑人生了~~所以说五个down一个直接到百分之八十。完了，eureka也不提人了~你说这个服务信息回收不是用来搞笑的么？所以说这个时候我们要自己设置阙值了。可以修改成适当的值，比如0.5之类的！要根据具体情况来判断。（这个其实和集群实现关系不大，主要是为我在这坑了~所以提出来说一下~~本来都预计收尾了又想起来这么个事~我这可怜的排版啊）
全文手打，连图片都是手画的~~~这么不容易的写个文~~如果你觉得用到了理解了~不留个言点个赞转个发什么的合适么？~
网友评论