springcloud定义了一系列组件运行在springboot之上。
1:首先先做springboot的配置说明:
连续的两个减号--就是对application.properties 中的属性值进行赋值的标识:--server.port=8888。
区分多环境配置方式:resource下放三个文件——
application-dev.properties:开发环境;
application-test.properties:测试环境;
application-prod.properties:生产环境。
application.properties 文件中指定:spring.profiles.active=test;或者启动命令:java-jar xxx.jar --spring.profiles.active=test;以及其他很多方式比如jar包相同目录下放application.properties 文件。
1.1:第一个组件:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
aoolication.yaml配合:
# actuator 监控配置
management:
#actuator端口 如果不配置做默认使用上面8080端口
# server:
# port: 8080
endpoints:
web:
exposure:
#默认值访问health,info端点 用*可以包含全部端点
include: "*"
#修改访问路径 2.0之前默认是/; 2.0默认是/actuator可以通过这个属性值修改
base-path: /actuator
endpoint:
shutdown:
enabled: true #打开shutdown端点
health:
show-details: always #获得健康检查中所有指标的详细信息
访问:http://localhost:8080/actuator 获取固定信息以及动态信息(/actuator/metrics),比入磁盘信息,内存信息,以及spring容器信息,还提供关闭容器,内存dump,线程快照等功能。
1.2:Eureka(服务注册发现功能,nacos也提供)
eureka-server(spring-cloud-starter-eureka-server):可提供集群模式,供provider和consumer(都依赖eureka-client)直接的服务注册和服务发现,现成产品,提供原生管理页面,如需详细了解各配置请参考:org.springframework.cloud.netflix.eureka.server.EurekaServerConfigBean;
provider(spring-cloud-starter-eureka):启动类加上@EnableDiscoveryClient代表各rest服务向eureka-server注册,application.properties需要配spring.application.name和eureka.client.serviceUrl.defaultZone(地址可以多个用逗号分隔);
consumer(spring-cloud-starter-eureka):启动类加上@EnableDiscoveryClient,以及配置服务访问方式restTemplate:加这两个注解@Bean,@LoadBalanced(ZoneAwareLoadBalancer),访问provier方式:restTemplate.getForEntity("http://HELLO-SERVICE/index",String.class).getBody();,其中HELLO-SERVICE是provider中定义的服务名:spring.application.name=hello-service。它对RestTemplate的请求拦截来实现对依赖服务的接口调用。
其它:服务注册配置(org.springframework.cloud.netflix.eureka.EurekaClientConfigBean),服务实例配置(org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean),失效剔除,自我保护暂不深究。
1.3 Spring Cloud Hystrix(限流熔断框架及配套仪表盘,Spring Cloud Circuit Breaker有四种实现方)
该功能是可选项,前期不要引入,因为熔断后整个服务间断性不可用了,实际场景用户不可接受,宁愿慢一点也不能直接报错。
启动类加上@EnableCircuitBreaker,在consumer的一个类的方法上增加@HystrixCommand(fallbackMethod="helloFallback"),代表调用失败则调用该类下面的helloFallback方法;
Hystrix默认超时时间为2000毫秒,为每一个依赖服务创建一个独立的线程池,对于小部分延迟本身就非常小的请求,9ms的延迟开销还是非常昂贵的;可以使用信号量,但是它不能设置超时和实现异步访问。默认的是线程池模式,本身rest请求已经产生不小的性能损耗,还套一层异步线程池增加开销,不合理。
请求缓存,代码侵入严重,无法使用(用注解相对好点,但功能很单一),而且有个前提:在同一用户请求的上下文中,相同依赖服务的返回数据始终保持一致。其他人改了数据你无法实时看到,业务流程无法保证。很奇怪怎么在调用方加缓存,结果是加到某个consumer的内存里了,个人实践都是在业务实现方加的缓存,个人认为是http请求本身损耗严重,期望在consumer缓存结果后避免一次http调用。
请求合并:用框架的api(HystrixCommand)去并发请求合并结果,整个业务代码都没法看了。无效知识,跳过。
1.4 Spring Cloud Feign(spring-cloud-starter-feign)
主类上增加注解@EnableFeignClients以及@EnableDiscoveryClient和@SpringBootApplication。
通过SpingMVC方式定义接口(服务名不区分大小写):
@FeignClient("hello-service")
public interface HelloService {
@RequestMapping("/hello")
String hello();
}
然后可以像dubbo一样在任何地方引用改接口(@Autowired方式)直接调用方法hello()。其实只是把rest请求接口化,内部也是通过Ribbon轮询调用rest服务,所以配置和ribbon一致,如:HELLO-SERVICE.ribbon.*,连接超时,读取超时等类RestTemplate配置。它和dubbo的区别就是接口在消费方定义,和服务方java api割裂。个人推荐使用这种方式,不推荐通过RestTemplate直接调用。
可以将接口定义抽象成独立的api jar包,provider的RestController直接实现该接口,consumer直接调用。但这样变成显示的项目依赖,那还不如用dubbo。
1.5 spring cloud gateway(已经取代zuul),网关,现成产品。
1.5 spring cloud gateway(已经取代zuul),网关,现成产品。_qq331077064的专栏-优快云博客
提供security(鉴权),monitoring/metrics(监控/度量) , resiliency(弹性)
依赖Netty runtime provided by Spring Boot 和 Spring Webflux,而非servlet容器(非tomcat) Spring Cloud Gateway
1.6 Spring Cloud Config(配置中心,nacos也提供)
服务端:spring-cloud-config-server,现成产品,只是修改基本配置。数据存在git仓库。通过向eurka注册自己实现集群模式。
客户端:spring-cloud-starter-config,各微服务项目,属性必须配置在 bootstrap.properties 中,主流的配置方式:
spring.application.name=hello
eureka.client.serviceUrl.defaultZone=
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server
spring.cloud.config.profile=dev
即通过eruka注册中心获取config-server服务,从该服务获取master分支下的文件:hello-dev.yml
1.7 spring cloud bus(消息总线,依赖RabbitMQ或Kafka)
rabbitMQ 独立产品,非java项目,暂只研究bus和rabbitMQ搭配;
mq基本用法:spring-cloud-starter-bus-amqp及springboot-starter-actuator,AmqpTemplate发送数据,@RabbitListener(queues="hello"),@RabbitHandler
bus客户端:多了该请求{[/bus/refresh],methods=[POST]};
合理方式是在Config Server中也引入Spring Cloud Bus,向配置服务发送刷新请求触发消息总线发送刷新时间到各业务服务方。
1.8 spring cloud sleuth(分布式服务追踪)
业务服务依赖:spring-cloud-starter-sleuth
追踪数据:服务id:traceId,spanId,是否收集,traceId全链路唯一,spanId是当前服务开始结束标识,默认收集10%的数据,spring.sleuth.sampler.percentage=0.1;
ELK平台主要由ElasticSearch、Logstash和Kibana三个开源工具组成,负责日志收集查看。
sleuth整合Zipkin:
服务端,引入zipkin-server和zipkin-autoconfigure-ui,启动类增加@EnableZipkinServer,ZipkinMessageListener为mq实现方式的核心类,默认存在内存中,可通过引入spring-boot-starter-jdbc和mysql-connector-java落库,需要增加配置zipkin.storage.type=mysql;
客户端,即业务端,配置spring.zipkin.base-url=http://localhost:9411,默认通过HTTP的方式提交收集的跟踪信息;也可以通过引入spring-cloud-sleuth-stream和spring-cloud-starter-stream-rabbit用异步消息方式提交,同时服务端也要同步引入spring-cloud-sleuth-zipkin-stream(核心封装,自动引入zipkin-autoconfigure-storage-mysql),spring-cloud-starter-stream-rabbit,zipkin-autoconfigure-ui才可接入mq。启动后会产生默认主题exchange:sleuth(type:topic,durable:true),主题方式可创建服务端的多实例(数据存在内存),但如果是落库方式,那mysql冲突,除非配多个数据库,边缘业务暂不需要考虑集群模式,如果在mq以及存储在mysql,数据也不会丢失,但长期服务不可用可能导致mq堆积。