Spring Cloud 注册中心 Eureka

目录

 

微服务的应用场景和核心竞争力

Spring Cloud 与 Dubbo 的对比

活跃度

架构

模块介绍

Eureka

Eureka Server

Eureka Client

ZK与Eureka对CAP的支持（一致性、可用性、分区容错性）

---

微服务的应用场景和核心竞争力

1. 低耦合：每一个微服务专注于单一功能，并通过良好的接口命名方式清晰表达出服务边界。由于体积小、复杂度低，可将每个微服务拆分为一个独立项目进行开发，易于保持高可维护性和开发效率。
2. 部署：由于每个微服务都是一个可以独立运行的项目，所以当每个服务发布时无需整体打包整个项目，并且方便开发人员和测试人员进行测试单个流程的输入输出数据，同时可降低发布期间对生产环境造成发布期间不可用的风险。
3. 灵活控制：在这样的去中心化的整体项目中，每个微服务都可以根据自己的业务复杂度和需求进行单独的技术方案选型，由此更能提高整体项目的业务处理速度。由此当某个技术方案不满足与业务需求时，可以及时重构某个节点而不会对整体业务造成很大的影响。尤其是当某个节点因业务需求需要处理大量业务逻辑或数据时，可以根据实际业务需求进行针对性的扩展，大大的节约了系统资源的浪费
4. 容错：当其中某个环节出现错误时，故障会被单独隔离在单个服务中，可以通过一些容错机制轻松应对的同时，也可以加快问题的排查定位速度。

Spring Cloud 与 Dubbo 的对比

活跃度

dubbo是一个非常优秀的服务治理框架，并且在服务治理、灰度、分发方便都比Spring Cloud做的更好，单时除了几年前dangdang网在其基础上增加了REST请求方式的DubboX版本外，后续就没有什么更新了。甚至连提交的Issue回复都不会很及时，甚至有些大点的企业在使用过程中，都只在维护自己内部使用的相关版本。从这方面看，Spring Cloud的社区活跃度和代码版本的更新速度都是比较高的，可以预期它在有Dubbo对比的基础上后期会更加的完善和稳定。

架构

dubbo更专注于服务治理，一些其他需要的相关配置和模块都需要自己集成，这样不仅增加了其使用难度，也对开发人员有了更高的要求。而Spring Cloud延续了Spring的兼容性和简单性，在Spring Boot的基础支持下开发过程更为简单和方便。

模块介绍

Eureka

主管服务注册与发现，微服务名称注册到Eureka，然后就可以通过它来找到对应的服务，而不需要修改服务调用的相关配置。

SpringCloud封装了Eureka模块来实现服务注册与发现，采用的是c-s的设计架构，Eureka Server作为服务注册中心。而系统的其他微服务，使用Eureka的客户端连接Eureka Server并维持心跳。这样系统的维护人员可以通过Eureka Server来监控系统中的各个服务是否正常运行。Spring Cloud的其他模块就可以通过Eureka Server来发现系统中的其他微服务并执行相关业务逻辑。

Eureka Server

Eureka Server提供服务注册功能，各个节点启动后，会在这里进行注册，Eureka Server的服务注册表中会存储所有可用服务节点信息，服务节点的信息可以在界面中直观看到。

 

如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）

当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper那样使整个注册服务瘫痪。

Eureka Client

Eureka Client是一个java客户端，用于简化Eureka Server的交互，客户端内部含有一个使用round-robin的负载均衡器。在应用启动后会向Eureka Server发送心跳（默认周期30s），如果在指定时间内未收到心跳响应（默认90s），则将这个节点从注册表中移除。

高可用：当Eureka Server在15中内有85%以上的节点没有正常响应心跳，那么Eureka会默认为与注册中心出现网络故障，从而启动应急措施。

1.不在从注册列表中移除因心跳超时而判断为无法连接的服务。

2.保证当前节点可用，保持接收新的服务注册和查询请求，但不在同步到其他节点中。

3.当心跳反应正常时将当前节点在故障期间接收到的注册请求同步到其他节点中。

Eureka可以更好的应对因网络故障而导致部分节点失联的情况，而不会像ZooKeeper那样使整个注册服务不可用。

ZK与Eureka对CAP的支持（一致性、可用性、分区容错性）

zookeeper保证CP，Eureka保证AP

在正常情况下，我们的系统对于注册中心的需求，高可用更大于数据的一致性，我们能容忍数据同步的速度有延迟，但是不能容忍服务在某一段时间段内不可用。这个部分ZK处理的不是很好，当master节点与其他节点失联时，其他节点会在一定时间后进行重新选举，但是由于选举时间过长，并且在选举过程中ZK集群不可用，导致在选举过程中注册服务瘫痪，尤其是在云部署的情况下，由于网络问题导致master节点失联的现象频频发生，尤其当这个问题产生在业务高峰期时，那么对公司会造成很大影响。

而Eureka在设计时就有限保证了可用性，在Eureka中没有设置master节点，只要不是所有节点同时挂掉，它都可以正常提供注册中心的相关服务。当客户端与某个失联Eureka Server试图链接并失败时，会自动切换到其他节点进行重试。