第4篇：Eureka设计理念第四篇：Eureka设计理念

74 阅读 0 评论 49 点赞

我是靠谱客的博主迷人画笔，最近开发中收集的这篇文章主要介绍第4篇：Eureka设计理念第四篇：Eureka设计理念，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

第四篇：Eureka设计理念

生产者、消费者、注册中心

Server端、Client端

AP优于CP

P2P节点信息同步

Eureka分区（Region与Zone）

总结

前面几篇文章，我们对微服务概念、服务发现与注册的理论做了简单介绍。这篇文章我们来分析一下Eureka的整体设计理念，具体来看看Eureka是如何实现服务发现与注册的。通过这篇文章希我们希望对Eureka整体框架有个初步的了解，这些都是深入全面、深入学习Eureka的基础。

Eureka 是 Netflix 开源的用于实现服务注册和发现的组件，类似的服务注册的组件还有很多，如：Zookeeper，Doozer等。但是，因为其优异的表现Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。

生产者、消费者、注册中心

之前的文章我们说过，服务发现与注册针对的核心问题是：“服务之间远程调用，彼此要知晓对方的相关信息：如IP、端口、状态、区域等等”。

因此，从服务调用关系的角度来说，Eureka可以划分为三个角色：服务注册中心，服务生产者、服务消费者。这些角色具体是什么含义呢？

假设有一个服务B要远程调用服务A提供的服务，那么服务B就是服务消费者，服务A就是服务生产者。那消费者服务要怎样获取生产者服务的信息呢？对，这就是服务注册中心，消费者（服务B）并不会直接从生成者（服务A）获取服务信息，而是通过第三方的服务注册中心获取。生产者服务（服务器A）将自身的信息登记到注册中心上，服务B再通过注册中心获取服务A的信息。

如上图所示：通过一个第三方的服务注册中心来管理，服务的登记，获取等操作，这是Eureka最顶层，最原始的结构了，当然，Eureka结构不可能这么简单，我们只考虑了注册与服务获取最简单的使用场景，还有许多其他场景问题需要解决如：服务下线了怎么办？服务异常崩溃了怎么办？如何处理网络抖动带来的不确定性？注册中心如何保证高可用？多机房部署如何保证就近调用等等。这些都会在后面的文章中一一解答。

Server端、Client端

刚才是从服务调用关系的角度将Eureka划分为3个角色：注册中心、服务生产者、服务消费者。但是，服务B是消费者，但服务B也可能会被其他的服务调用变成生产者，一个服务是生产者还是消费者，其实是要看从什么角度来说，并且可能既是生产者也是消费者。

因此，Eureka还可以从另一个角度将其划分为：客户端（Client端），服务端（Server端），服务生产者与服务消费者统称为客户端（Client端），注册中心集群叫做服务端（Server端）

如上图所示：Client端之间是相互独立的不进行通信，而是通过Server端进行数据交换。Server端成为了中心枢纽，Server端会运行多个节点，通过节点之间的数据同步，保证系统高可用。

AP优于CP

刚才我们从两个不同的维度对Eureka的顶层结构进行了分析。显然，Eureka是一个典型的分布式架构体系，对于分布式系统，永远绕都不开的一个问题：CAP理论。

CAP理论是指在一个分布式系统中，不可能同时满足以下三点。

一致性（Consistency） （数据在多副本的情况下，对数据进行更改操作时，可能因为机器，网络或其他原因，一部分副本更改成功，一部分副本更改失败，导致数据的不一致）
可用性（Availability）（在任何时候客户端对集群进行读写数据操作时，集群必须在一个规定的延迟内返回结果——但是，不能保证返回的数据是最新的）
分区容错性（Partition tolerance）（所谓分区容忍是指：当网络发生故障，整个集群被划分为多个无法相互通信的区域时，集群任然可用）

对于大部分分布式系统，分区容错性是客观存在，无法避免。所以必须是已保证分区容错性为提前，既常说的分布式系统是CP类型，还是AP类型，在分区容错性基础上权衡一致性（C）与可用性（A）。

为了更好的理解CP与AP之间的差异，可以对比分析一下Zookeeper CP类型的分布式系统的处理方式，看看CP与AP的侧重点是什么？

如上图所示: ZK集群部署在机房1、机房2两个机房中，ZK Leader部署在机房1，两个机房还部署了ZK Follower、生产者服务与消费者服务，并且，由于某些不稳定原因两个机房的网络中断了。

当机房2中的生产者服务B进行注册时是不会成功的，因为，CP系统要求的是强一致性，ZK要保证数据成功同步到其他的Follower节点，也就是所机房2中Follower的数据要成功同步到机房1 的Leader之后，才认为注册成功，很显然这时是做不到的，因为网络中断了。然而事实上，机房2中的生产者服务与消费者服务之间网络是正常的，它们直接应该是可以注册成功远程调用的。但是，为了整个集群的数据一致性，CP宁愿牺牲掉机房2这部分可用性。

而与之对比的Eureka，AP优于CP的原则，在上面的情况中，Eureka允许机房2内的服务注册成功与可用，其结果是机房1与机房2中的数据会不一致，如果机房1中一个服务也要使用生产者B的话，这时是拿不到生产者B的信息的。

Eureka为什么要选择AP呢？个人认为，集群中的数据是微服务客户端的元数据，元数据并不会像业务数据那样频繁的变化，导致数据不一致的可能性并没有那么高，拿到一份过期或不一致的数据，总比拿不到任何数据要强。如果客户端拿到了不一致的数据，自身也要做异常的处理，比如：重试、熔断、负载等。

P2P节点信息同步

分布式系统中为了保证数据的一致性，各个的节点之间需要进行数据同步，一般分布式系统中的数据同步机制可分为两种：主从模式，对等模式。

主从模式（Master-Slave）：在集群有一个主副本，其他为从副本，所有数据的写操作都提交到主副本上，最后再由主副本更新到其他从副本。在该模式下主副本节点要承担所有的写入压力，可能会成为系统的瓶颈，从副本负责所有的读操作。
对等模式（Peer To Peer）：在集群中不分主从，任何副本都可以进行读写操作，副本与副本直接实现数据同步，这样的优点是，不存储单点的写操作压力，而缺点是每个副本都可以进行写操作，数据同步与解决数据冲突就成了一个棘手的问题。

Eureka正是采对等模式实现集群之间的数据同步，那Eureka具体的同步过程是怎么样，以及如何解决数据冲突的呢？我们会在下一篇Eureka技术实现细节中进行讲解。

Eureka分区（Region与Zone）

当系统规模比较大，并且用户在地理上分布广泛时，一般通过将服务部署到多区域，多个机房，来保证系统高可用、容灾，数据靠近用户等。当微服务调用发生在多个机房之间时，我们希望同一个机房内的服务优先调本机房内的服务，只有同机房服务不可用时，再调用其他机房的服务，这样可以最大限度的降低延迟与开销。

那么，Eureka是如何实现这点呢？对，Eureka通过Region与Zone实现了服务的分区管理，Region与Zone这两个概念都来自亚马逊的AWS。

region：可以简单理解为地理上的分区，比如亚洲地区，或者华北地区，再或者北京等等，没有具体大小的限制。根据项目具体的情况，可以自行合理划分region。
zone：可以简单理解为region内的具体机房，比如说region划分为北京，然后北京有两个机房，就可以在此region之下划分出zone1,zone2两个zone。

对于Eureka的分区管理（Region、Zone）可以先归类如下几点：

Eureka通过分区管理，实现不同区域不同机房服务之间的就近调用，以降低延迟。
Region表示区域、Zone代表机房，它们直接是一对多的关系。
对Eureka Server与Eureka Client配置Region Zone，将服务制定到不同的区域
在服务调用时，根据配置Region与Zone的顺序，再选择不同区域内服务

总结

本篇文章主要是介绍Eureka的整体框架与设计理念，理解这些是后面学习Eureka技术实现的基础；

对于初学者很容易混淆，注册中心，消费者、生产者、服务器端，客户端等这些概念，这些是从不同的角度来描述Eureka组件；

作为分布式系统Eureka选择AP优于CP，Eureka选择AP是由Eureka作为服务注册中心的场景决定的；

Eureka使用Peer To Peer的模式实现服务端集群数据同步，这保证了集群没有单点故障，但是要处理数据冲突问题；

Eureka使用Region与Zone的概念对服务分区进行管理，解决了服务就近调用的问题；