springcloud 微服务新手学习
微服务
强调服务的大小，它关注的是一个点，是解决某一个问题/提供落地对应服务的一个服务应用。
springboot 开发的一个小模块，专业的事情交给专业的模块来做。 强调的是一个一个的个体，每一个个体完成一个具体的任务或者功能。
微服务优缺点
微服务优点
- 每个服务足够内聚，足够小。代码容易理解，这样能聚焦一个指定的业务功能或业务需求。
- 开发简单，开发效率高，一个服务可能就是专一的只干一件事。
- 微服务是松耦合，是有功能意义的服务，无论是在开发阶段或者部署阶段都是独立的。
- 微服务能使用不同的语言开发。
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署集成工具。
- 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一的数据库。
微服务缺点
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度，随着服务的增加，运维的压力也在增大
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
分布式微服务架构需要哪些纬度？
天上飞的理念必定有落地的实现
服务治理
服务注册
服务调用
服务负载均衡
服务监控
...
SpringCloud
springCloud ,基于SpringBoot 提供了一套微服务解决方案，包括服务的注册于发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
SpringCloud利用Springboot的开发便利性巧妙的简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括：配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等。都可以用Springboot的开发风格做到一键启动和部署。
SpringBoot 和SpringCloud 关系
- SpringBoot 专注于快速方便的开发单个个体微服务。
- SpringCloud 是关注全局的微服务协调整理治理框架，它将SpringBoot 开发的一个个单体微服务整合并管理起来。
- Springboot 可以离开Springcloud 独立使用开发项目，但是SpringCloud 离不开SpringBoot ,属于依赖关系。
Eureka 服务注册与发现
它主要包括两个组件：Eureka Server 和 Eureka Client
Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端）
Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）
各个微服务启动时，会通过 Eureka Client 向 Eureka Server 注册自己，Eureka Server 会存储该服务的信息， 也就是说，每个微服务的客户端和服务端，都会注册到 Eureka Server，这就衍生出了微服务相互识别的话题同步：每个 Eureka Server 同时也是 Eureka Client（逻辑上的）多个 Eureka Server之间通过复制的方式完成服务注册表的同步，形成 Eureka 的高可用 识别：Eureka Client 会缓存 Eureka Server 中的信息即使所有 Eureka Server 节点都宕掉，服务消费者仍可使用缓存中的信息找到服务提供者（笔者已亲测）
续约：微服务会周期性（默认30s）地向 Eureka Server 发送心跳以Renew（续约）信息（类似于heartbeat）
续期：Eureka Server 会定期（默认60s）执行一次失效服务检测功能
它会检查超过一定时间（默认90s）没有Renew的微服务，发现则会注销该微服务节点
Spring Cloud 已经把 Eureka 集成在其子项目 Spring Cloud Netflix 里面
关于 Eureka
配置的最佳实践，可参考：https://github.com/spring-cloud/spring-cloud-netflix/issues/203更多介绍，可参考：http://cloud.spring.io/spring-cloud-static/Camden.SR4/#spring-cloud-eureka-server
Eureka 自我保护机制
什么是自我保护模式？
默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。
在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。
在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式。
Eureka 配置
服务端配置
application.yml
在启动类上标注 @EnableEurekaServer //Eureka服务端启动类，接受其他微服务注册进来
server:
port: 7001
eureka:
instance:
hostname: eureka1 #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
# defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址。
defaultZone: http://eureka2.com:7002/eureka/,http://eureka3.com:7003/eureka/ # 配置eureka集群
客户端配置
application.yml
在启动类上标注@EnableEurekaClient 或 @EnableDiscoveryClient 实现服务注册和发现。
eureka:
client: #客户端注册进eureka服务列表内
service-url:
defaultZone: http://eureka1.com:7001/eureka/,http://eureka2.com:7002/eureka/,http://eureka3.com:7003/eureka/
instance:
instance-id: SpringCloudDept # 自定义服务器名称
info:
app.name: YL-WFW
company.name: www.10soft.com
build.artifactId: $project.artifactId$
build.version: $project.version$
消费者端
在服务消费需要在启动类注解 @EnableEurekaClient
yml 配置文件配置
server:
port: 80
eureka:
client:
register-with-eureka: false
service-url:
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
package com.yling.configBean;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;
@Configuration
public class configBean {
/**
* RestTemplate
* RestTemplate是Spring提供的用于访问Rest服务的客户端，
* RestTemplate提供了多种便捷访问远程Http服务的方法,能够大大提高客户端的编写效率。
* @return
*/
@Bean
public RestTemplate getRestTemplate() {
return new RestTemplate();
}
}
package com.yling.controller;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
import com.yling.pojo.Dept;
@RestController
public class ConsumerDept {
private static final String base_url="http://SPRINGCLOUDDEPT/"; //eureka注册服务地址
@Autowired
private RestTemplate restTemplate;
@RequestMapping("/consumer/add")
public boolean add(Dept dept) {
return restTemplate.postForObject(base_url + "dept/add", dept, Boolean.class); //调用post请求
}
@RequestMapping("/consumer/get/{id}")
public Dept get(@ PathVariable Integer id) {
return restTemplate.getForObject(base_url + "dept/get/"+ id, Dept.class); //get请求 RESTfull风格
}
//测试@EnableDiscoveryClient,消费端可以调用服务发现
@RequestMapping(value="/consumer/dept/discovery")
public Object discovery()
{
return restTemplate.getForObject(base_url+"/dept/discovery", Object.class);
}
}
Eureka 和 zookeeper 的区别
作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP,
Eureka则是AP。
4.1 Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
4.2 Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。