springCloud和springBoot 项目区别
1,SpringCloud 它将SpringBoot开发的一个个单体微服务整合并管理起来,关注全局的服务治理框架。为各个微服务 之间提供,配置管理 Springboot 可以单独开发项目 但是springcloud 离不开 springBoot
2,springcloud 开发的项目每个 模块是一个独立的微服务,springBoot 项目启动我们的项目后就可以访问我们的dao层,但是springCloud 数据访问层是一个一般设置为一个微服务每一个微服务必须注册进 Eureka 中先启动Eureka 在启动我们的 数据访问层的服务,controller 控制器微服务,都注册进Eureka 进行管理(eureka server 监控么一个状态)
3,使用Feign能让编写Web Service客户端更加简单,,Spring Cloud对Feign进行了封装,使其支持了Spring MVC标准注解(那些注解作用)和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。
@FeignClient(name="fs-service")
@FeignClient(name="fs-service")
public interface AttributeFeignService {
//自定义操作
@PostMapping("/attribute/attribute/getList")
List<AttributeEntity> getList(@RequestParam("page") Integer page, @RequestParam("rows") Integer rows, @RequestBody Map<String, Object> maps);
@GetMapping("/attribute/attribute/find/{id}")
public AttributeEntity find(@PathVariable("id") String id);
}
Dubbo 是rpc
Cloud 是 Restful 通信
Microservicecloud-eureka-7001
1, 假如需要引入cloud 的一个新技术基本上有两步
1.1 新增一个相关的maven 坐标
Eureka
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
如果么有server 全部是eureka 的客户端
1.2 在主启动类上面,标注的启动该新技术组件技术的相关注解标签
@enableeurekaServer
Zuull
@EnableZuulProxy
1.3 java业务逻辑代码
EurekaServer ok
CAP
RDBMS(mysql/orcale/sqlServer) ===== ACIP
NOSQL (redis,mongdb) ---> CAP
理论+实践同样重要
因为,你去面试的时候需要谈薪资!!!!
你需要先进去才能有动手干活的机会,耐性
API 工程师、调用师、码农都不到,你可能只是
码神>码龙>马牛>码工>码农> 码畜> 码渣
面试高大上,面试造飞机,工作拧螺丝
负载均衡
Feign
之前大家用ribbon进行负载均衡,功能很强大,甚至可以自定义算法
Feign 是怎么出来的
1, 大部分的大家都可以,直接调用我们的服务费来进行访问
Private static final String REST_URL_PREFIX = http://localhost:8081; 修改为
Private static final String REST_URL_PREFIX = http://MIROSERVICECLOUD-DEPT;
2, 我们目前习惯面向接口编程,比如WebServie接口,比如我们的DAO接口,这个已经是我们的规范
2.1 微服务名字获得调用地址
2.2 就是通过接口+注解, 获得我们调用服务,
适应社区其他程序员提出的,还是统一的面向接口编程的套路 ----》 Feign
只需要创建一个接口,然后在上面添加注解即可。
@Mapper
Public interface DeptDao{
}
使用Feign能让编写Web Service客户端更加简单,,Spring Cloud对Feign进行了封装,使其支持了Spring MVC标准注解(那些注解作用)和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。
采用feign的方式更优雅(feign内部也使用了ribbon做负载均衡)。
springMVC注解:
我们只需创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解,现在是一个微服务接口上面标注一个Feign注解即可)
Ribbon
供客户端的软件负载均衡算法, 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA。
Irule(核心组件):根据特定算法中从服务列表中选取一个要访问的服务()
自定义后要在启动类中加入才能 注解才能起作用
@RibbonClient(name="MICROSERVICECLOUD-DEPT",configuration=MySelfRule.class)
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。
LB,即负载均衡(Load Balance),在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA。
常见的负载均衡有软件Nginx,LVS,硬件 F5等。
相应的在中间件,例如:dubbo和SpringCloud中均给我们提供了负载均衡,SpringCloud的负载均衡算法可以自定义。
什么是springCloud
基于SpringBoot提供了一套微服务解决方案, 包括服务注册与发现,配置中心,全链路监控,服务网关,负载均衡,熔断器等组件。SpringCloud为开发人员提供了快速构建分布式系统的一些工具,包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等,
SpringCloud和springBoot的关系
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud 它将SpringBoot开发的一个个单体微服务整合并管理起来,关注全局的服务治理框架。为各个微服务 之间提供,配置管理 Springboot 可以单独开发项目 但是springcloud 离不开 springBoot
RestTemplate
提供了多种便捷访问远程Http服务的方法,
是一种简单便捷的访问restful服务模板类,是Spring提供的用于访问Rest服务的客户端模板工具集
Eureka是什么
Eureka是Netflix 。Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转有了服务发现与注册,只需要使用服务的标识符,就可以访问到服务( 1,启动ureka服务, 血药注册的服务中引入 依赖),而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心,比如Zookeeper
Netflix在设计Eureka时遵守的就是AP原则
Service Provider服务提供方将自身服务注册到Eureka,从而使服务消费方能够找到
Eureka Server 提供服务注册和发现
Service Consumer服务消费方从Eureka获取注册服务列表,从而能够消费服务
Eureka包含两个组件:Eureka Server和Eureka Client
Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块(比如Zuul)就可以通过 Eureka Server 来发现系统中的其他微服务
各个节点启动后,会在EurekaServer中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到
著名的CAP理论
指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。
Eureka保证AP
Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。
Hystrix
分布式系统面临的问题:雪崩现象
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。 (ha yi si chai ka si)
服务熔断, 熔断机制的注解是@HystrixCommand。
服务降级
整体资源快不够了,忍痛将某些服务先关掉,待渡过难关,
1,根据Fegin接口 新建一个实现FallbackFactory
2,@FeignClient中添加fallbackFactory属性值
@FeignClient(name="cloud-user",fallbackFactory=FeignFallBackFactory.class)
服务降级
1, 整体资源快不够了,忍痛将某些服务关掉,待度过难过,在开启回来
2,所谓降级,一般是从整体负荷考虑。就是当某个服务熔断之后,服务器将不再被调用,
此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值。这样做,虽然服务水平下降,但好歹可用,比直接挂掉要强得多
服务熔断
一般是某个服务故障或者异常引起, 类似现实世界中的 “保险丝” 当某个异常条件被触发,直接熔断此服务,而不是一直等到该服务超时。
Zuul包含了对请求的路由和过滤两个最主要的功能:
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预,是实现请求校验、服务聚合等功能的基础.Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中获得其他微服务的消息,也即以后的访问微服务都是通过Zuul跳转后获得。
注意:Zuul服务最终还是会注册进Eureka
提供=代理+路由+过滤三大功能
Spring Cloud Gateway
http://www.yuqiyu.com/spring-cloud-gateway-predicate.html
Spring Cloud Gateway
是SpringCloud
的全新子项目,该项目基于Spring5.x
、SpringBoot2.x
技术版本进行编写客户端向Spring Cloud Gateway
发出请求。如果网关处理程序映射确定请求与路由匹配,则将其发送到网关Web处理程序。
https://www.jianshu.com/p/f55661e26d18
总结
通过本章的讲解,我们已经对SpringCloud Gateway
的转发有一个简单的理解,通过从服务注册中心拉取服务列表后,自动根据serviceId
映射路径前缀,同名服务多实例时会自动实现负载均衡。
使用springcloud 和 ZipKin进行分布式链路跟踪
Zipkin 是一个开放源代码分布式的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
每个服务向zipkin报告计时数据,zipkin会根据调用关系通过Zipkin UI生成依赖关系图,显示了多少跟踪请求通过每个服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如用户每次请求服务的处理时间等,可方便的监测系统中存在的瓶颈。
Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra以及Elasticsearch。接下来的测试为方便直接采用In-Memory方式进行存储,生产推荐Elasticsearch。
创建zipkin-server项目
项目依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>
</dependencies>
启动类
@SpringBootApplication
@EnableEurekaClient
@EnableZipkinServer
public class ZipkinApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinApplication.class, args);
}
}
配置文件
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
server:
port: 9000
spring:
application:
name: zipkin-server
在项目其他服务中加入
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
可以显示服务之间的关系
请求其他服务后服务的处理时间以及跟踪显示的服务
springCloud配置中心config
可以有一个非常轻量级的集中式管理来协调这些微服务,可以使用不同的语言来编写这些服务,也可以使用不同的数据来存储
把每个微服务的所有配置文件统一起来管理
- 分布式系统面临的---配置问题
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,上百个配置文件的管理....../(ㄒoㄒ)/~~
Config Server得到Git库中的配置,统一管理每个微服务的配置文件
- 是什么
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
- 怎么玩
SpringCloud Config分为服务端和客户端两部分。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
具体实现
1,在github上创建一个创建一个 fs-cloud-config 存放配置文件 application.yml
spring:
profiles:
active:
- dev
---
spring:
profiles: dev #开发环境
application:
name: microservicecloud-config-atguigu-dev
---
spring:
profiles: test #测试环境
application:
name: microservicecloud-config-atguigu-test
# 请保存为UTF-8格式
server 端
添加依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
</dependencies>
配置文件
server:
port: 3344
spring:
application:
name: microservicecloud-config
cloud:
config:
server:
git:
uri: git@github.com:18893703708/fs-cloud-config.git #GitHub上面的git仓库名字
3、启动类
启动类添加@EnableConfigServer
,激活对配置中心的支持
@SpringBootApplication
@EnableConfigServer
public class FsCloudConfigApplication {
public static void main(String[] args) {
SpringApplication.run(FsCloudConfigApplication.class, args);
}
}
测试server
启动微服务3344 http://config-3344.com:3344/application-dev.yml http://config-3344.com:3344/application-test.yml
读取配置规则
- /{application}/{profile}[/{label}]
- /{application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{label}/{application}-{profile}.properties
client 端
在git文件管理库中 添加配置文件 fs-config-client.yml
spring:
profiles:
active:
- dev
---
server:
port: 8201
spring:
profiles: dev
application:
name: microservicecloud-config-client
eureka:
client:
service-url:
defaultZone: http://eureka-dev.com:7001/eureka/
---
server:
port: 8202
spring:
profiles: test
application:
name: microservicecloud-config-client
eureka:
client:
service-url:
defaultZone: http://eureka-test.com:7001/eureka/
客户端添加依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
客户端项目配置文件 bootstrap.properties
#需要从github上读取的资源名称,注意没有yml后缀名
spring.cloud.config.name=fs-service
#和git里的文件名对应
spring.cloud.config.profile=test
# 远程仓库的分支
spring.cloud.config.label=master
#本微服务启动后先去找3344号服务,通过SpringCloudConfig获取GitHub的服务地址
spring.cloud.config.uri = http://localhost:3344
测试客户端
启动Config配置中心3344微服务并自测 http://config-3344.com:3344/application-dev.yml
启动3355作为Client准备访问 bootstrap.yml里面的profile值是什么,决定从github上读取什么
假如目前是 profile: dev ,dev默认在github上对应的端口就是8201 http://client-config.com:8201/config