(注：Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。
首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of partition)，新发布的服务仍然可以被发现与访问。
但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务， 它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时， 这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。
幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源 的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。
维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一个 web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供 了Restful-API接口，方便第三方程序集成Eureka的功能。
结论
关于Service发现服务通过本文我们想说明两点：1、留意服务运行的硬件平台;2、时刻关注你要解决的问题，然后决定 使用什么平台。Knewton就是从这两个方面考虑使用Eureka替换ZooKeeper来作为service发现服务的。云部署平台是充满不可靠性 的，Eureka可以应对这些缺陷;同时Service发现服务必须同时具备高可靠性与高弹性，Eureke就是我们想要的!
http://blog.csdn.net/defonds/article/details/36678783
参考资料
https://github.com/Netflix/eureka/wiki/Building-Eureka-Client-and-Server
https://github.com/Netflix/eureka/wiki/Configuring-Eureka
http://git-scm.com/download/linux
http://www.gradle.org/installation
http://www.javacodegeeks.com/2012/08/how-to-install-gradle.html
http://wiki.openkm.com/index.php/Configure_Tomcat_service_linux
Netflix的Eureka
Eureka是Netflix的中间层，用于负载均衡和服务发现。在应用服务中既存有服务器组件，也有智能客户端。服务器和客户端都采用java语言编写，这就意味着理想的应用场景是用于采用java编写的服务，或者是与JVM兼容的语言编写的服务。
Eureka服务器用于注册服务。他们推荐在AWS每个可用的区域运行一个Eureka服务器，通过它来形成聚簇。服务器通过异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状态是有细微差别的。
服务的注册由客户端组件处理。服务嵌入在客户端应用程序代码中。在运行时，客户端注册服务并周期性的发送心跳来更新它的租约。
服务的发现也由智能客户端来处理。它从服务器端检索当前注册的信息并把它们缓存在本地。客户端周期性能刷新它的状态同时处理负载均衡和失效备援。
Eureka在设计时就考虑了失败时的恢复。它依托强一致性提供良好的可用性，可在运行在多种不同的失败场景中。如果聚簇中有分片，那么Eureka就转入自我保护模式。它允许在分片期间过行服务的发现和注册，当分片结束时，聚簇中的成员会把它们的状态再次合并起来。
http://www.oschina.net/translate/service-discovery-in-the-cloud?cmp&p=1
首先，在Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中;而对于它来说，所有要做的无非是同步一些新的服务 注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个Eureka节点，会持续的对外提供服务(注：ZooKeeper不会)：接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中(same side of partition)，新发布的服务仍然可以被发现与访问。
但是，Eureka做到的不止这些。正常配置下，Eureka内置了心跳服务，用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务， 它的“心跳”变得迟缓时，Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能，但是当网络分割故障发生时， 这也是非常危险的;因为，那些因为网络问题(注：心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。
幸运的是，Netflix考虑到了这个缺陷。如果Eureka服务节点在短时间里丢失了大量的心跳连接(注：可能发生了网络故障)，那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对 于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
最后，Eureka还有客户端缓存功能(注：Eureka分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。
Eureka的构架保证了它能够成为Service发现服务。它相对与ZooKeeper来说剔除了Leader节点的选取或者事务日志机制，这 样做有利于减少使用者维护的难度也保证了Eureka的在运行时的健壮性。而且Eureka就是为发现服务所设计的，它有独立的客户端程序库，同时提供心 跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用ZooKeeper你必须自己来实现这些功能。Eureka的所有库都是开源 的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。
维护Eureka服务器也非常的简单，比如，切换一个节点只需要在现有EIP下移除一个现有的节点然后添加一个新的就行。Eureka提供了一个 web-based的图形化的运维界面，在这个界面中可以查看Eureka所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka甚至提供 了Restful-API接口，方便第三方程序集成Eureka的功能。
结论
关于Service发现服务通过本文我们想说明两点：1、留意服务运行的硬件平台;2、时刻关注你要解决的问题，然后决定 使用什么平台。Knewton就是从这两个方面考虑使用Eureka替换ZooKeeper来作为service发现服务的。云部署平台是充满不可靠性 的，Eureka可以应对这些缺陷;同时Service发现服务必须同时具备高可靠性与高弹性，Eureke就是我们想要的!
http://blog.csdn.net/defonds/article/details/36678783
参考资料
https://github.com/Netflix/eureka/wiki/Building-Eureka-Client-and-Server
https://github.com/Netflix/eureka/wiki/Configuring-Eureka
http://git-scm.com/download/linux
http://www.gradle.org/installation
http://www.javacodegeeks.com/2012/08/how-to-install-gradle.html
http://wiki.openkm.com/index.php/Configure_Tomcat_service_linux
Netflix的Eureka
Eureka是Netflix的中间层，用于负载均衡和服务发现。在应用服务中既存有服务器组件，也有智能客户端。服务器和客户端都采用java语言编写，这就意味着理想的应用场景是用于采用java编写的服务，或者是与JVM兼容的语言编写的服务。
Eureka服务器用于注册服务。他们推荐在AWS每个可用的区域运行一个Eureka服务器，通过它来形成聚簇。服务器通过异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状态是有细微差别的。
服务的注册由客户端组件处理。服务嵌入在客户端应用程序代码中。在运行时，客户端注册服务并周期性的发送心跳来更新它的租约。
服务的发现也由智能客户端来处理。它从服务器端检索当前注册的信息并把它们缓存在本地。客户端周期性能刷新它的状态同时处理负载均衡和失效备援。
Eureka在设计时就考虑了失败时的恢复。它依托强一致性提供良好的可用性，可在运行在多种不同的失败场景中。如果聚簇中有分片，那么Eureka就转入自我保护模式。它允许在分片期间过行服务的发现和注册，当分片结束时，聚簇中的成员会把它们的状态再次合并起来。
http://www.oschina.net/translate/service-discovery-in-the-cloud?cmp&p=1
316
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
