是否向注册中心注册自己，注册为true反之为false。
2、eureka.t.fetch-registry：
是否需要去检索服务，检索为true反之为false。
3、eureka.t.serviceUrl.defaultZone :
指定服务注册中心的地址。
...
十二、Eureka？
1、Eureka可分为三个角色：
服务发现者、服务注册者、注册发现中心。
但是这三个角色，并不和实际部署的模型，是一对一的关系。
2、所有的网络通信，都是基于http(s)协议的。
3、Eureka和AWS是紧密结合的，无论是配置还是源码...
比如Region、zone…...
Region可以通过配置文件进行配置，如果不配置默认使用us-east-1。
同样Zone也可以配置，若不配置默认使用defaultZone。
...
十三、Eureka的高可用配置？
Eureka Server的高可用，实际上就是将自己作为服务向其它服务注册中心注册自己。
这样就可以形成一组互相注册的服务注册中心...
以实现服务清单的互相同步，达到高可用效果。
...
十四、谈谈微服务？
以前所有的代码，都放在同一个工程中，部署在同一个服务器，这就造成了同一项目的不同模块、不同功能互相抢占资源...
微服务，就是将工程根据不同的业务规则，拆分成微服务，部署在不同的服务器上，实现服务之间相互调用。
实现Java微服务的有Dubbo(只能用来做微服务)...
SpringCloud(提供了服务的发现、断路器等)。
微服务的7个特点：
1、按业务划分为一个独立运行的程序，即服务单元；
2、服务之间通过HTTP协议相互通信；
3、自动化部署；
4、可以用不同的编程语言；
5、可以用不同的存储技术；
6、服务集中化管理；
7、微服务是一个分布式系统。
微服务的6点优势：
1、将一个复杂的业务拆分为若干小的业务，将复杂的业务简单化。
新人只需要了解它所接管的服务的代码，这就减少了新人的学习成本。
2、由于微服务是分布式服务，服务于服务之间没有任何耦合。
微服务系统的微服务单元，具有很强的横向拓展能力。
3、服务与服务之间，采用HTTP网络通信协议来通信...
单个服务内部高度耦合，服务与服务之间完全独立，无耦合。
这使得微服务，可以采用任何的开发语言和技术来实现，提高开发效率、降低开发成本。
4、微服务是按照业务进行拆分的，并有坚实的服务边界...
若要重写某一业务代码，不需了解所以业务，重写简单。
5、微服务的每个服务单元是独立部署的...
即独立运行在某个进程中，微服务的修改和部署，对其它服务没有影响。
6、微服务在CAP理论中，采用的AP架构，具有高可用分区容错特点。
高可用主要体现在系统7x24不间断服务...
它要求系统有大量的服务器集群，从而提高系统的负载能力。
分区容错也使得系统更加健壮。
微服务的4点不足：
1、微服务的复杂度
构建一个微服务比较复杂，服务与服务之间，通过HTTP协议或其它消息传递机制通信。
开发者要选出最佳的通信机制，并解决网络服务差时，带来的风险。
2、分布式事物
将事物分成多阶段提交，如果一阶段某一节点失败，仍会导致数据不正确。
如果事物涉及的节点很多，某一节点的网络出现异常...
会导致整个事务处于阻塞状态，大大降低数据库的性能。
3、服务划分
将一个完整的系统，拆分成很多个服务，是一件非常困难的事...
因为这涉及了具体的业务场景。
4、服务部署
最佳部署容器Docker。
...
十五、微服务和SOA的关系？
微服务相对于和ESB联系在一起的SOA，轻便敏捷得多...
微服务，将复杂的业务组件化，也是一种面向服务思想的体现。
对于微服务来说，它是SOA的一种体现，但是它比ESB实现的SOA，更加轻便、敏捷和简单。
...
十六、SpringCoud是如何实现服务注册与发现的？
服务发布时，指定对应的服务名(IP地址和端口号)，将服务注册到注册中心(eureka和zookeeper)...
但是这一切是SpringCloud自动实现的；
只需要在SpringBoot的启动类上，加上@EnableDisscoveryt注解。
同一服务修改端口，就可以启动多个实例调用方法：
传递服务名称，通过注册中心获取所有的可用实例...
通过负载均衡策略(Ribbon和Feign)调用对应的服务。
...
十七、Ribbon和Feign的区别？
两者有3点具体区别，即启动类使用的注解不同，服务的指定位置不同，调用方式不同。
Ribbon添加的maven依赖是spring-starter-ribbon。
使用@Ribbo(value=“服务名称”)，使用RestTemplate调用远程服务对应的方法。
Feign添加的maven依赖是spring-starter-feign...
服务提供方提供对外接口，调用方使用，在接口上使用Feig(“指定服务名”)。
3点具体区别：
1、启动类使用的注解不同
Ribbon使用的是@Ribbo，Feign使用的是@EnableFeigs。
2、服务的指定位置不同
Ribbon是在@Ribbo注解上声明。
Feign则是在定义抽象方法的接口中使用@Feig声明。
3、调用方式不同
Ribbon需要自己构建http请求，模拟http请求...
然后使用RestTemplate发送给其它服务，步骤比较繁琐。
而Feign，则是在Ribbon的基础上进行了一次改进，采用接口调用的方式...
将需要调用的其它服务的方法，定义成抽象方法即可...
不需要自己构建http请求。
不过要注意的是，抽象方法的注解、方法签名，要和提供方的完全一致。
...
十八、雪崩效应？
分布式系统中的服务通信，依赖于网络...
网络不好，必然会对分布式系统带来很大的影响。
在分布式系统中，服务之间相互依赖，即...
如果一个服务之间出现了故障或者网络延迟，在高并发的情况下...
会导致线程阻塞，在很短的时间内，该服务的线程资源会消耗殆尽，最终使得该服务不可用。
由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。
为了防止此类事件的发生，分布式系统必然要采取相应的措施，如熔断机制（SpringCloud采用的是Hystrix）。
...
十九、熔断机制？
1、服务故障则开启熔断器
当一个服务出现故障时，请求失败次数超过设定的阀值（默认50）之后...
该服务就会开启熔断器，之后该服务就不进行任何业务逻辑操作，执行快速失败，直接返回请求失败的信息。
其它依赖于该服务的服务，就不会因为得不到响应而造成线程阻塞。
这是除了该服务，以及依赖于该服务的部分功能不可用外，其它功能正常。
2、熔断器的自我修复机制
当一个服务熔断后，经过一段时间（5s）半打开熔断器。
半打开的熔断器，会检查一部分请求（只能有一个请求）是否正常...
其它请求执行快速失败；
检查的请求如果响应成功，则可判断该服务正常了，就可关闭该服务的熔断器，反之则继续打开熔断器。
这种自我熔断机制和自我修复机制...
可以使程序更加健壮，也可以为开发和运维，减少很多不必要的工作。
3、熔断组件提供监控
熔断组件往往会提供一系列的监控...
比如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等等。
从而，可以让开发人员和运维人员去了解服务的状况。
...
二十、Eureka的基础架构？
Eureka的基础架构的组成部分是...
1、服务注册中心（失效剔除、自我保护）；
2、服务提供者（服务注册、服务同步、服务续约）；
3、服务消费者（获取服务、服务调用、服务下线）。
...
下面，就来说下具体内容吧！
1、服务注册中心
Eureka提供的服务端，提供服务注册与发现的功能。
1.1、失效剔除
对于那些非正常下线的服务实例（内存溢出、网络故障导致的）...
服务注册中心，不能收到“服务下线”的请求，为了将这些无法提供服务的实例从服务列表中剔除...
Eureka Server在启动的时候，会创建一个定时任务...
默认每隔一段时间（默认60s），将当前清单中超时（默认90s）没有续约的服务，剔除出去。
1.2、自我保护
Eureka Server在运行期间，会统计心跳失败的比例，在15分钟之内是否低于85%...
如果出现低于的情况（生产环境由于网络不稳定会导致）...
Eureka Server会将当前的实例注册信息保护起来，让这些实例不过期，尽可能保护这些注册信息。
但是在这保护期间内，实例出现问题...
那么客户端，就很容易拿到实际上已经不存在的服务实例，会出现调用失败的情况。
所以客户端必须有容错机制，比如可以使用请求重试、断路器等机制。
在本地进行开发时，可以使用 eureka.server.enable-self-preseervation=false参数...
来关闭保护机制，以确保注册中心，可以将不可用的实例剔除。
2、服务提供者
提供服务的应用，可以是SpringBoot应用，也可以是其它的技术平台，且遵循Eureka通信机制的应用。
它将自己提供的服务，注册到Eureka，以供其它应用发现（如service层）。
2.1、服务注册
服务提供者，在启动的时候，会通过发送Rest请求的方式...
将自己注册到Eureka Server（服务注册中心）中，同时带上自身服务的一些元数据；
Eureka Server接收到这个Rest请求后，将元数据存储在一个双层结构Map中；
第一层的key是服务名，第二层key是具体服务的实例名。
2.2、服务同步
若有两个或两个以上的Eureka Server（服务注册中心）时...
它们之间是互相注册的。
当服务提供者，发送注册请求到一个服务注册中心时...
它会将该请求，转发到集群中相连的其它注册中心；
从而实现，注册中心间的服务同步，这样服务提供者的服务信息，可以通过任意一台服务中心获取到。
2.3、服务续约
在注册完服务之后，服务提供者会维护一个心跳，来持续告诉Eureka Server：“我还活着”...
以防止Eureka Server的“剔除任务”将该服务实例，从服务列表中排除出去。
配置：eureka.instance.lease-renewal-in-seds=30(续约任务的调用间隔时间，默认30秒，也就是每隔30秒向服务端发送一次心跳，证明自己依然存活)。
eureka.instance.lease-expiration-duration-in-seds=90(服务失效时间，默认90秒，也就是告诉服务端，如果90秒之内没有给你发送心跳就证明我“死”了，将我剔除)。
3、服务消费者
消费者应用，从服务注册中心获取服务列表...
从而使消费者，可以知道去何处调用其所需要的服务。
比如Ribbon实现消费方式，Feign实现消费方式。
3.1、获取服务
当启动服务消费者时，它会发送一个Rest请求给注册中心...
获取上面注册的服务清单；
Eureka Server会维护一份只读的服务清单，来返回给客户端，并且每三十秒更新一次。
3.2、服务调用
在服务消费者获取到服务清单后，通过服务名...
可以获得具体提供服务的实例名和该实例的元信息，采用Ribbon实现负载均衡。
3.3、服务下线
当服务实例，进行正常的关闭操作时...
它会触发一个服务下线的Rest请求，给Eureka Server，告诉服务注册中心“我要下线了”。
服务端接收到请求之后，将该服务状态设置为下线，并把下线时间传播出去。
...
二十一、Eureka和Zookeeper都可以提供服务注册与发现的功能，而两者的区别是？
简单来说，Zookeeper保证了CP(C：一致性，P：分区容错性)；
Eureka保证了AP(A：高可用，P：分区容错)。
1、Zookeeper
当向注册中心查询服务列表时...
我们可以容忍，注册中心返回的是几分钟以前的信息；
但不能容忍直接down掉，不可用的。
也就是说，服务注册功能对高可用性要求比较高。
但是Zookeeper会出现这样的一种情况...
当master节点，因为网络故障与其它节点失去联系时...
剩余的节点，会重新选leader。
问题在于，选取leader的时间过长(30~120s)，且选取期间Zookeeper集群都不可用...
这样就会导致，选取期间注册服务瘫痪。
在云部署的环境下，因网络问题...
使得Zookeeper集群，失去master节点，是较大概率会发生的事。
虽然服务最终恢复，但是漫长的选择时间，导致的注册长期不可用，是不能容忍的。
2、Eureka
它则看明白这一点，因此在设计上优先保证了高可用性。
Eureka各个节点都是平等的，几个节点挂掉，不会影响到正常节点的工作...
剩余的节点，依然可以提供注册和查询服务。
而Eureka的客户端，再向某个Eureka注册时...
如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在...
就能保证注册服务的可用(保证可用性)，只不过查到的信息，可能不是最新的(不保证一致性)。
除此之外，Eureka还有一种自我保护机制...
如果在15分钟内，超过85%的节点都没有正常心跳...
那么Eureka，就认为客户端与注册中心出现了网络故障。
而此时，就会出现以下几种情况：
2.1、Eureka不再从注册列表移除，因为长时间没收到心跳，而应该过期的服务；
2.2、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(保证当前节点可用)；
2.3、当网络稳定时，当前实例新的注册信息，会被同步到其它节点中。
Eureka还有客户端缓存功能(Eureka分为客户端程序和服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。
所以，即便Eureka集群中所有节点都失效，或者发生网络分隔故障，导致客户端不能访问任何一台Eureka服务器。
Eureka服务的消费者，任然可以通过Eureka客户端缓存，来获取所有的服务注册信息。
甚至最极端的环境下，所有正常的Eureka节点，都不对请求产生响应...
也没有更好的服务器解决方案，来解决这种问题。
得益于Eureka的客户端缓存技术，消费者服务...
仍然可以通过Eureka客户端，查询与获取注册服务信息，这点很重要；
因此Eureka，可以很好的应对网络故障，导致部分节点失去联系的情况。
而不像Zookeeper那样，使整个注册服务瘫痪。
...
二十二、CAP理论？
1、sistency
指数据的强一致性。
如果写入某个数据成功，之后读取，读到的都是新写入的数据；
如果写入失败，读到的都不是写入失败的数据。
2、Availability
指服务的可用性。
3、Partition-tolerance
指分区容错。
...
二十三、Ribbon和Nginx的区别？
1、Nginx性能好，但Ribbon可以剔除不健康节点，Nginx剔除比较麻烦。
2、Ribbon是客户端负载均衡，Nginx是服务端负载均衡。
...
二十四、服务注册与发现？
服务注册，就是向服务注册中心，注册一个服务实例...
服务提供者将自己的服务信息（服务名、IP地址等）告知注册中心。
服务发现，是服务消费另一个服务时，注册中心将服务的实例，返回给服务消费者...
一个服务，既是服务提供者又是服务消费者。
服务注册中心健康检查机制...
当一个服务实例注册成功以后，会定时向注册中心，发送一个心跳证明自己可用；
若停止发送心跳，证明服务不可用将会别剔除；
若过段时间继续向注册中心提供心跳，将会重新加入服务注册中心列表中。
...
二十五、微服务的负载均衡，为何用？怎么用？
1、为什么要用？
微服务是将业务代码拆分为很多小的服务单元...
服务之间的相互调用通过HTTP协议来调用，为了保证服务的高可用，服务单元往往都是集群化部署的。
2、消费者该调用，哪个服务提供者的实例呢？
服务消费者集成负载均衡组件，该组件会向服务消费者...
获取服务注册列表信息，并隔一段时间重新刷新获取列表。
当服务消费者消费服务时，负载均衡组件，获取服务提供者所有实例的注册信息...
并通过一定的负载均衡策略（可以自己配置）选择一个服务提供者实例；
向该实例进行服务消费，这样就实现了负载均衡。
……
以上，就是今天的分享啦！
希望，对你的求职面试，编程工作有那么一点点、一丢丢、一戳戳地帮助哈～
喜欢我分享的，就一键三连于我，可好？！
本章已完 m.3qdu.com