spring cloud的入门总结

本篇的总结文档是19年初的时候看了springcloud之乐优商城学习资料写的一点总结

一.Eureka注册慢问题

默认情况下，服务注册到Eureka Server过程较慢。在开发或测试时，常常希望加速这一过程，从而提高工作效率。
服务注册涉及到周期性心跳，默认30秒一次。只有当实例、服务端和客户端的本地缓存中的元数据都相同时，服务才能被其他客户端发现（所以可能需要3次心跳）。
可以使用参数eureka.instance.leaseRenewalintervalInSeconds修改时间间隔，从而加快客户端连接到其他服务的过程。在生产环境中最好坚持使用默认值，因为在服务器内部有一些计算，它们会对续约做出假设。
综上，要想解决服务注册慢的问题，只须将eureka.instance.leaseRenewalintervalInSeconds设成一个更小的值。该配置用于设置Eureka Client向Eureka Server发送心跳的时间间隔，默认是30，单位是秒。在生产环境中，建议坚持使用默认值。

二 已停止的微服务节点注销慢或不注销

1 原因

在开发环境下，常常希望Eureka Server能快速有效地注销已停止的微服务实例。然而，由于Eureka Server清理无效节点周期长（默认90秒），以及自我保护模式等原因，可能会遇到微服务注销慢甚至不注销问题。

2 解决方法：

Eureka Server端：配置关闭自我保护，并按需配置Eureka Server清理无效节点的时间间隔。

eureka.server.enable-self-preservation  #设为false，关闭自我保护，从而保证会注销微服务
eureka.server.eviction-interval-time-in-ms #清理间隔（单位毫秒，默认是60*1000）

Eureka Client端：配置开启健康检查，并按需配置续约更新时间和到期时间。

eureka.client.healthcheck.enabled #设为true，开启健康检查（需要sping-boot-start-actuator依赖）
eureka.instance.lease-renewal-interval-in-seconds #续约更新时间间隔（默认30秒）
eureka.instance.lease-expiration-duration-in-seconds #续约到期时间（默认90秒）

注意：这些配置仅在开发或测试时使用，生产环境建议坚持使用默认值。
3 实例
Eureka Server配置：

eureka:
  server:
    eureka.server.enable-self-preservation: false
     eureka.server.eviction-interval-time-in-ms: 4000

Eureka Client配置：

eureka:
  client:
    healthcheck:
      enabled: true
  instance:
    lease-expiration-duration-in-seconds: 30
    lease-renewal-interval-in-seconds: 10

三 如何自定义微服务的Instance ID

Instance ID用于唯一标识注册到Eureka Server上的微服务实例。
在Eureka Server首页可以直观地看到各个微服务的Instance ID。
在Spring Cloud中，服务的Instance ID默认值是

${spring.cloud.client.hostname}:${spring.application.name}:${spring.application.instance_id:${server.port}}

如果想要自定义这部分内容，只须在微服务中配置eureka.instance.instance-id属性即可，例如：

spring:
  application:
    name:  microservice-prodider-user
eureka:
  instance:
    #将Instance ID设置为IP:端口的形式
    instance-id: ${spring.cloud.client.ipAddress}:${server.port}

这样，就可将微服务microservice-prodider-user的Instance ID设为 IP:端口的形式。

四 Eureka 的UNKNOWN问题总结与解决

注册UNKNOWN问题，一般分两种情况，一种是应用名称UNKNOWN，另外一种是应用状态UNKNOWN。下面分别讨论这两种情况。

1 应用名称UNKNOWN

未配置spring.application.name或者eueka.instance.appname属性。如果这两属性都不配置，就会导致应用名称UNKNOWN问题。

2 微服务实例状态UNKNOWN

微服务实例的状态UNKNOWN同样很麻烦。一般来讲，只会请求状态是UP的微服务。该问题一般由监控检查导致。
eureka.client.healthcheck.enabled=true必须设置在application.yml中，而不能设置在bootstrap.yml中，否则一些场景下会导致UNKNOWN的问题。

五、搭建springcloud的环境时，客户端在启动时自动停止

解决方法：在pom.xml文件中加入依赖：

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
</dependency>

六、Spring Cloud Ribbon

1. Spring Cloud Ribbon的概念

是一个基于HTTP和TCP的客户端负载均衡工具，它基Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容实际上都是通过Ribbon来实现的，包括后续我们将要介绍的Feign，它也是基于Ribbon实现的工具。所以，对Spring Cloud Ribbon的理解和使用，对于我们使用Spring Cloud来构建微服务非常重要

2. 微服务之间的调用

在Spring cloud 中服务之间通过restful方式调用有两种方式

• restTemplate+Ribbon
• feign 网上推荐使用feign

七、Nginx与Zuul的区别

相同点：Zuul和Nginx都可以实现负载均衡、反向代理（隐藏真实ip地址），过滤请求，实现网关的效果。
不同点：Nginx–c语言开发
Zuul–java语言开发
Zuul负载均衡实现：采用ribbon+eureka实现本地负载均衡
Nginx负载均衡实现：采用服务器实现负载均衡
Nginx相比zuul功能会更加强大，因为Nginx整合一些脚本语言（Nginx+lua）
Nginx适合于服务器端负载均衡
Zuul适合微服务中实现网关

八、微服务架构的框架有哪些？

四种常用的微服务架构方案，分别是ZeroC IceGrid、Spring Cloud、基于消息队列与Docker Swarm。

九、@EnableDiscoveryClient与@EnableEurekaClient的区别

spring cloud中discovery service有许多种实现（eureka、consul、zookeeper等等），@EnableDiscoveryClient基于spring-cloud-commons, @EnableEurekaClient基于spring-cloud-netflix。
可以说使用其他的注册中心后，都可以使用@EnableDiscoveryClient注解，但是使用@EnableEurekaClient的情景，就是在服务采用eureka作为注册中心的时候，使用场景较为单一。

十、服务发现框架选型，Consul还是Zookeeper还是etcd。

当时它并没有研究Consul，放到表格中，Consul则应该是General、CP、Go、No dependency、Http/DNS Library。

下面我就zookeeper、etcd、consul这三款进行下比较。

总结：为了以后支持多数据中心，同时为了快速支持不同的语言比如nodejs、python服务，我会选择consul作为我们的服务发现框架，但是实时获取服务信息变化通知的问题需尽可能减小。