微服务架构之服务注册与发现(一)

一、服务注册中心的由来

假如没有服务注册中心，我们会干些什么事情呢？

在传统行业的项目架构中以下的方案最为常见了：

这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：

相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。

服务注册中心干些什么事情呢？

上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：

    服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄百度百科的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。

2Euraka

先来看一下euraka的架构图：

Register：服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Renew：服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries：获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

DiscoveryManagergetInstance()shutdownComponent()；

Eviction 服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

自我保护机制：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eurekaserverenableself-preservation: false)

3Consul

consul推荐的架构图：

Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。

4Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka10版本不再维护，euraka20已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul

Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。

Nacos的官方介绍：

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享：

除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。

推荐理由：

Nacos服务注册表结构Map<namespace, Map<group::serviceName, Service>>采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。

什么是服务注册？

首先我们来了解下，服务注册、服务发现和服务注册中心的之间的关系。

举个形象的例子，三者之间的关系就好像是供货商，顾客和商店。

首先各地的供货商会将各种商品提供给商店，然后顾客需要商品的时候会去商店购买。

注册中心就好比是这个商店，供货商的动作就是服务注册，商品就是注册的服务。

当部署的服务启动后，会注册到注册中心，消费者需要什么样的服务，就自己去注册中心拉取。

那么到底什么是服务注册，为什么要将服务注册到注册中心呢？

服务注册指的是服务在启动时将服务的信息注册到注册中心中，由注册中心统一对所有的注册的服务进行管理。

现在我们想想，假如你是消费者，你需要买一个商品，你可以去商店，也可以直接去供货商。

但是如果今天你要买很多商品，而且我们并不知道每个商品对应的供应商的地址，那么你就得挨家挨户的去跑供货商购买商品。

是不是就很麻烦了，倘若此时有一家商店，汇总了多家供货商的商品，那你是不是只需要去这一家商店就能购买到你需要的所有的商品了呢？

这样是不是就方便了。

在我们现实开发中，比如我们需要获取用户信息的时候，而此时，我们的用户服务只部署了一个节点，那我们就可以使用IP+端口的形式访问服务。

当此时我们的服务部署了10个节点后，我们可以通过域名访问，通过nginx转发到某一个节点上，访问该节点的服务。

使用过nginx的小伙伴们都知道，每当我们需要新增一个节点的时候，我们就需要去修改nginx的配置文件，一旦服务部署的节点过多，频繁修改配置文件就变成了一件极其麻烦的事情。

这个时候，我们的注册中心，就应该粉墨登场了。

注册中心一登场，我们就尽管部署服务节点，部署完成后，服务启动，服务的信息就会被注册到注册中心，我们就不需要担心是不是又要去修改配置文件了。

什么是服务发现？

服务发现有两种模式：一种是客户端发现模式，一种是服务端发现模式。Eureka采用的是客户端发现模式。

客户端发现模式就好比我是一个土豪顾客，我去了商店，我把所有的商品都买回家，需要的时候在这些商品里面寻找。

因为我是土豪，所以我当然不能忍受商店里有新品上架，而我却没有，所以我每隔一段时间就会商店增量获取最新的商品。

这就是Eureka中的Fetch Registry，抓取注册信息。

Eureka Client 从 Eureka Server 获取注册表信息并在本地缓存。

这里我们注意一下，Eureka Client并不是直接去服务注册表中获取数据，而是从ReadOnly缓存中获取数据。

并且会通过在上一个获取周期和当前获取周期之间获取增量更新，这些信息会定期更新(每30秒更新一次)。

获取的时候可能返回相同的实例。Eureka Client会自动处理重复信息。

因为我的土豪行为，我已经被商店老板记录在它的VVIP名单上了。可惜天有不测风云，我破产了，我再也不能这么土豪了，没办法，我告诉了老板我破产了，老板听了我的话，想都没想，直接从他的VVIP名单上将我的名字给剔除了，社会就是这么现实。

这就是Eureka中的Cancel，取消。

每一个微服务节点关闭时，Eureka Client会向Eureka Server发送一个取消请求。

Eureka Server收到你的取消请求后，就会将你从服务注册表中给剔除。

商店老板是个傲娇的人，她制定了一个规则，如果你是她VVIP名单上的人，你必须每隔一段时间就要去商店采购商品。

一旦你在一段时间内没有来采购，她就觉得你已经没有购买能力，不适合在她的VVIP名单上存在了。

她就会狠心的将你从她的VVIP名单上将我的名字给剔除了。

这就是Eureka中的Renew（更新 / 续借）

Eureka Client 内部具备一个内置的负载均衡器，它使用轮训（round-robin）负载算法。

在服务启动后，每隔一定周期（默认30秒）向Eureka Server发送心跳。

如果Eureka Server在多个心跳周期内（默认90秒）没有收到Eureka Client发送过来的心跳，Eureka Server将会在服务注册表中将该节点剔除。

当然了，服务发现去注册中心拉取的是服务的信息，然后需要从服务信息中获取到服务部署的节点信息，然后通过域名地址访问到该节点的服务。

就好像一家商店，因为空间太小，只是存放了一些商品的微缩模型，模型上写着该商品所属的供货商地址，我们去商店拿到该模型后，看到供货商的地址，然后我们就可以直接去供货商那儿直接购买商品了。

什么是注册中心，注册中心的作用？

注册中心就是一个管理器，各个服务提供者将服务注册到注册中心，由注册中心进行统一的存储和管理。

注册中心同时还有着判断服务是否可用，对于不可用的服务进行剔除的功能。

至于如何判断服务的可用性和如何剔除不可用的服务，后续会有详细的讲解。

什么是 Eureka，有什么作用？

Eureka采用CS架构，它分为两大组件。

一个是Eureka Server,注册中心服务端。

当各个微服务节点启动后，Eureka Server 会存储服务提供者注册上来的服务信息，并且提供二层缓存机制来维护整个注册中心。

另一个是Eureka Client，注册中心客户端。

Eureka Client是一个java客户端，它用来简化和Eureka Server交互。

Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。

因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。

Eureka 架构详解

如下图所示，这是官网提供给我们的Eureka的架构图Eureka 的架构，主要分为 Eureka Server 和 Eureka Client 两部分，Eureka Client 又分为 Applicaton Service 和 Application Client，Applicaton Service 就是服务提供者，Application Client 就是服务消费者。

我们首先会在应用程序中依赖 Eureka Client，项目启动后 Eureka Client 会向 Eureka Server 发送请求，进行注册，并将自己的一些信息发送给 Eureka Server。

注册成功后，每隔一定的时间，Eureka Client 会向 Eureka Server 发送心跳来续约服务，也就是汇报健康状态。如果客户端长时间没有续约，那么 Eureka Server 大约将在 90 秒内从服务器注册表中删除客户端的信息。

Eureka Client 还会定期从 Eureka Server 拉取注册表信息，然后根据负载均衡算法得到一个目标，并发起远程调用，关于负载均衡在后面的课时会详细介绍，也就是 Ribbon 组件。

应用停止时也会通知 Eureka Server 移除相关信息，信息成功移除后，对应的客户端会更新服务的信息，这样就不会调用已经下线的服务了，当然这个会有延迟，有可能会调用到已经失效的服务，所以在客户端会开启失败重试功能来避免这个问题。

Eureka Server 会有多个节点组成一个集群，保证高可用。Eureka Server 没有集成其他第三方存储，而是存储在内存中。

所以 Eureka Server 之间会将注册信息复制到集群中的 Eureka Server 的所有节点。

这样数据才是共享状态，任何的 Eureka Client 都可以在任何一个 Eureka Server 节点查找注册表信息。

Eureka 的工作流程

Eureka 的自我保护机制

什么是自我保护机制

官方定义：自我保护模式正是一种针对网络异常波动时的安全保护措施，使用自我保护模式能使Eureka集群更加健壮稳定的运行。

为什么要开启自我保护机制？

如果Eureka Server在一定时间内（默认90s）（可优化）没有收到某一个服务节点的心跳，Eureka Server将会移除该服务实例。

但是在某些时候，遇到网络分区故障，服务节点实际上是正常存活状态，但是却无法和Eureka Server正常通信，此时如果没有引入自我保护机制，Eureka Server就会将该服务节点剔除。

自我保护模式的工作机制

如果15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就会认为客户端与注册中心发生了网络故障，Eureka Server进入自我保护机制。

自我保护机制的缺点

如果在自我保护机制中，刚好某些服务节点非正常下线，但是Eureka Server并不会剔除该服务节点，服务消费者就会获取到一个无效的服务实例。

解决方案

① ：关闭自我保护机制(不推荐)

② ：切换请求或断路器，使用负载均衡的方式，设置当一个请求超过多少秒还未得到响应，速度切换请求到下一个注册服务，例如使用Ribbon+Hystrix配置负载均衡和断路器。

Eureka Server 进入自我保护机制后

1、Eureka Server不再从注册表中剔除因为长时间没有和注册中心续约的服务节点

2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会同步到其他Eureka Server节点上

3、网络正常后，当前Eureka Server节点会将新的服务节点信息同步到其他Eureka Server节点上

如何开启自我保护

通过

eurekaserverenable-self-preservation=true/false来开启或关闭自我保护机制。

其他关键配置：

清理失效服务节点的时间间隔：

eurekaserverevication-interval-timer-in-ms默认60s

续约间隔时间：

eurekainstancelease-renewal-interval-in-seconds默认30s

续约到期时间：

eurekainstancelease-expiration-duration-in-seconds默认90s

通过源码窥探Eureka是如何开启自我保护机制的

第一步，我们引入Eureka Server 依赖。

第二步，我们找到eureka-core jar包下的路径为comnetflixeureka下的registry包

第三步，进入AbstractInstanceRegistry 类，找到evict方法，这个是定期剔除任务的线程最终执行的方法

第四步，我们找到isLeaseExpirationEnabled()方法的实现

第五步，我们注意到

numberOfRenewsPerMinThreshold这个变量很关键，它的含义是每分钟最小的续约次数

在服务注册register和服务下线cancel两个方法中会更新这个变量，更新该变量方法如下：

以上就是Eureka开启自我保护的整个逻辑流程。

解除自我保护机制

1当服务的网络分区故障解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于85%时，则自动解除。

2重启服务

Eureka 的健康检查

其实很多框架的健康状态监控都是通过 actuator 来管理健康状态的，并且扩展了 health 端点。

所以说我们只要在项目中集成Actuator，我们就能管理监控项目的健康状态。

Eureka也是一样，我们可以将某些不健康的服务节点的状态告知Eureka Server，然后Eureka Server 会主动让其下线。

这个就是Eureka的健康检查。

如何实现Eureka-Actuator健康检查？

首先我们要在pom中依赖

spring-boot-starter-actuator。

第二步，配置文件中添加

eurekaclienthealthcheckenabled=true 配置

原理分析：

首先在 EurekaDiscoveryClientConfiguration 中根据 eurekaclienthealthcheckenabled 的值来决定是否要装配 EurekaHealthCheckHandler ，然后在 EurekaClientAutoConfiguration 中会注册 HealthCheck ，但我们注册完成后会有调用任务来进行状态的更新，在 comnetflixdiscoveryInstanceInfoReplicatorrun() 中会进行状态更新。

Eureka 的多级缓存机制

什么是多级缓存机制

Eureka Server 为了避免同时读取内存数据造成的并发冲突问题，采用了多级缓存机制提升服务请求的响应速度。

Eureka Server的缓存是通过一个只读，一个读写缓存来实现的。

一级缓存：concurrentHashMap<key,value>readOnlyCacheMap本质是HashMap，无过期时间，保存数据信息对外输出。

readOnlyCacheMap依赖于定时器的更新，通过与readWriteCacheMap的值做对比，以readWriteCacheMap为准。

responseCacheUpdateIntervalMs：readOnlyCacheMap缓存更新间隔，默认30s

二级缓存：LoaDing<key,value>readWriteCacheMap本质是Guava缓存，包含失效机制，保护数据信息对外输出。

responseCacheAutoExpirationInSeconds：readWriteCacheMap 缓存过期时间，默认180s。

当服务节点发生注册，下线，过期，状态变更等变化时

1在内存中更新注册表信息

2同时过期掉readWriteCacheMap缓存，缓存清除只是会去清除readWriteCacheMap这个缓存， readOnlyCacheMap 只读 缓存并没有更新，也就说当客户端的信息发生变化之后， 只读缓存不是第一时间感知到的。只读缓存的更新只能依赖那个30秒的定时任务来更新。

3一段时间后（默认30s），后台线程发现readWriteCacheMap缓存为空，于是也将readOnlyCacheMap中的缓存清空

4当有服务消费者拉取注册表信息时，会调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。

在Eureka Server 中会有两个线程，一个是定时同步两个缓存的数据，默认30s，一个是定时检测心跳故障，默认90s。

服务拉取

1服务消费者，默认每30s，拉取注册表信息

2从readOnlyCacheMap中获取信息，如果获取为空

3从readWriteCacheMap中获取，如果还是为空

4调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。

Eureka的区域配置

当用户地理分布范围很广的时候，比如公司在上海、杭州、青岛等都有分公司的时候，一般都会有多个机房。

那么对于用户而言，当然是希望调用本地分公司的机房中的微服务应用。

比如：上海用户A，调用OAuth2服务，用户A当然希望调用上海机房里面的微服务应用。如果上海用户A调用杭州机房的OAuth2服务，就增加的延时时间。

所以我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用的时候，再去调用其它机房的服务，以达到减少延时的作用。

为此，eureka提供了region和zone两个概念来进行分区，Eureka基于Amazon设计的，所以对于地域的区分也与Amazon一致，Amazon分为多个region，每个region包含多个zone，所以Eureka设计时也是可以设置region与zone，请求时可以优先选择与请求服务在同一个zone的服务。

基本配置

此时无论我们调用多少次，调用的都是shanghai下面的zone1下面的服务。

一般来说我们都会结合Ribbon来实现微服务的负载均衡，而Ribbon内部会有一些专门的负载策略算法，虽然刚刚我们说过会优先请求的是指定region下指定 Zone 区域的服务实例。

但有些时候比如当在Region=shanghai下没有可用的zone，系统会默认加载 DEFAULT_ZONE，或者说或者同区域的服务负载过高等等，也会自动切换成其他区域的服务。

Eureka的重试机制

由于 Spring Cloud Eureka 实现的服务治理机制强调了 CAP 原理中的 AP，即可用性与可靠性，牺牲了一定的一致性（在极端情况下它宁愿接受故障实例也不要丢掉"健康"实例，如同如我们上面所说的自我保护机制）。

但不论是由于触发了保护机制还是服务剔除的延迟，引起服务调用到这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！

这显然不是我们愿意看到的，我们还是希望能够增强对这类问题的容错。所以，我们在实现服务调用的时候通常会加入一些重试机制。

从 Camden SR2 版本开始，Spring Cloud 就整合了 Spring Retry 来增强 RestTemplate 的重试能力，对于开发者来说只需通过简单的配置，原来那些通过 RestTemplate 实现的服务访问就会自动根据配置来实现重试策略。

开启Eureka的重试机制很简单，首先我们在pom中引入Spring Retry的依赖：

然后在配置文件中配置

springcloudloadbalancerretryenabled参数来控制重试机制的开关，因为 Spring Retry默认是开启的，所以说我们只要引入依赖即可，如果说我们想要关闭的话只需要将 springcloudloadbalancerretryenabled设置为false即可。

其实在SpringCloud的架构组件中无论是Fegin，Ribbon，还是Zuul都提供了重试机制，这些暂且不论，后续再讲到具体的组件时再进行具体的分析。

实战 Eureka 注册中心的部署

Eureka Server 项目搭建

1、创建一个 springcloud-eureka-server 的项目，然后在 pom 中增加

spring-cloud-starter-netflix-eureka-server 的依赖。

2在pomxml文件中新增

spring-cloud-starter-netflix-eureka-server依赖

3在启动类

SpringcloudEurekaServerApplication上使用 @EnableEurekaServer 开启 EurekaServer 的自动装配功能。

4添加配置文件applicationproperties

5启动项目，然后访问 >

Eureka源码采用172版本

本人小白，此文为本人阅读源码笔记，如果您读到本文，您需要自己甄别是否正确，文中的说明只代表本人理解，不一定是正确的！！！

自我保护机制设计的初衷是防止服务注册服务因为本地网络故障，长时间未接受到心跳请求，造成错误的移除大量服务实例，其实调用服务还是可用的

自我保护机制是和自动故障移除联系在一起的，针对的移除实例也是自动故障移除

在服务故障移除的方法中有这样一个判断，当返回false时候，直接返回，不进行故障实例的摘除

进入该方法

关于获取上一分钟心跳总数，Eureka Server内部采用的是定时线程进行统计，使用两个AtomicLong进行保存当前和上一分钟的心跳总数

该方法初始化了运行了定时调度的线程进行统计，默认执行间隔为1min，执行流程：

那么当前的心跳总数是怎么计算的呢，直接看心跳的renew()方法，是否嵌入了计数器累计 *** 作

如上所示，当接收到心跳时，当前心跳计数器进行了递增 *** 作

而getNumOfRenewsInLastMin()获取上一分钟心跳总数就是获取lastBucket数量，再找下该定时任务启动的入口

和自动故障移除的定时同时启动的，那么lastBucket代表了上一分钟的心跳总数

接下来，我们需要看看期望每分钟最小心跳总数的由来：

numberOfRenewsPerMinThreshold最开始的初始化计算是在Eureka Server初始化计算的，使用当前Server拉取到的服务实例总数 085

在openForTraffic()方法中使用初始化拉取的服务实例总数作为基数标准进行计算，(int) (thisexpectedNumberOfRenewsPerMin serverConfiggetRenewalPercentThreshold()) -> count 2 085,

集群模式下，count为其他节点中已注册的服务实例总数，单节点就为0

下面我们看看在注册中心接收到注册，下线等请求执行时，维护numberOfRenewsPerMinThreshold

注册，当前实例数量+2，下线，当前实例数量-2，然后再次085，计算期望每分钟最小心跳数

在Eureka Server中有专门的定时任务进行更新numberOfRenewsPerMinThreshold,默认每15min执行一次

主要流程如下：

注意，自动服务故障移除没有进行numberOfRenewsPerMinThreshold的更新

<font color= 'blue'>服务故障实例的摘除需要判断当前是否处于自我保护模式，而自我保护模式的默认是开启(isSelfPreservationModeEnabled)，需要判断上一分钟的心跳总数是否大于期望每分钟最小心跳数，如果在15分钟内，累计丢失了15%以上的节点心跳，那么Eureka Server就会认为当前所处的网络环境异常，从而处于自动保护模式，故障实例将不会移除，再等待15min后，进行expectedNumberOfRenewsPerMin的基于当前服务实例的重新计算后，自我保护模式才会关闭!</font>

自我保护服务开启模拟：

Spring Boot框架是由Pivotal团队提供的全新框架，其设计目的是用来简化基于Spring应用的初始搭建以及开发过程。SpringBoot框架使用了特定的方式来进行应用系统的配置，从而使开发人 员不再需要耗费大量精力去定义模板化的配置文件。

Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务注册，服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等 *** 作提供了一种简单的开发方式。

Spring Boot通过@SpringBootApplication注解标识为Spring Boot应用程序。所有的应用都通过jar包方式编译，部署和运行

每个Spring Boot的应用都可以通过内嵌web容器的方式提供>

Apollo默认自带了Eureka作为内部的注册中心实现，该Eureka-server就Config Service上，在一般情况下不需要考虑为Apollo单独部署注册中心。

不过有些公司自己已经有了一套Eureka，如果希望把Apollo的Config Service和Admin Service也注册过去实现统一管理的话，可以按照如下步骤 *** 作：

本人用的Apollo是：150版本的。

修改打包好的 apollo-configservice 和 apollo-adminservice 安装包下的 application-githubproperties 文件

修改 ApolloConfigDBServerConfig 表中的 eurekaserviceurl ，指向自己的Eureka地址。

比如自己的Eureka服务地址是 19216810126:8001 和 19216810126:8002 ，那么就将 ApolloConfigDBServerConfig 表中设置 eurekaserviceurl 为：

启动 apollo-configservice 和 apollo-adminservice 以及 Eureka-Server 后，访问eureka：

apollo-configservice 和 apollo-adminservice 都注册到了我们的Eureka，还需要验证 apollo-configservice 是否启动了自己的Eureka-server：

访问： 19216810126:8080 ，不会显示eureka管理页面。

以上就是关于微服务架构之服务注册与发现(一)全部的内容，包括:微服务架构之服务注册与发现(一)、字节三面：到底知不知道什么是Eureka、Eureka源码浅读---自我保护机制等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！