SpringCloud学习笔记

最新推荐文章于 2024-05-16 01:26:03 发布

qq_1003669233

最新推荐文章于 2024-05-16 01:26:03 发布

阅读量107

点赞数

分类专栏： spring

本文链接：https://blog.csdn.net/qq_27295923/article/details/100555172

版权

spring 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Eureka
（一）服务发现组件Eureka
1．Eureka概念
Eureka是Netflix的一个子模块,也是核心模块之一,Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移

功能类似注册中心,注册中心就是将一些服务的服务信息注册到注册中心上面去(不要想的多难),其实就是把你要提供的接口信息,放到系统里面可以查询出来,可以知道有多少个接口

注册中心有很多,比如zookeeper,redis,SpringCloud的Eureka

Eureka客户端是可以互相交互的,是轮询负载算法,如果哪个服务挂了,不会立即消失,因为你在服务一启动之后,就注册到Eureka里面,服务不知道你挂了,就用了心跳模式(轮询模式)

2．Eureka解决的问题

像上面RPC架构,我怎么知道提供了多少个接口,我怎么知道调用接口是什么情况?

通过注册中心,两套系统当项目一启动的时候,先注册到注册中心上面来,必须标识一下注册中心,注册中心知道系统有没有启动.
然后会员系统和订单系统调用就是直接从注册中心那里获取对方的接口信息,

3．创建EurekaService注册中心

@EnableEurekaServer: 该注解表明应用为eureka服务，有可以联合多个服务作为集群，对外提供服务注册以及发现功能

//*********
1.将依赖拷贝到父工程的pom.xml里面

org.springframework.cloud spring-cloud-dependencies Finchley.M9 pom import

2.创建子模块 jiagoushi_eureka 后将依赖放在这个模块的pom.xml里面

org.springframework.cloud spring-cloud-starter-netflix-eureka-server

这样它就是Eureka的服务端了
3.在resources新建配置文件application.yml
配置application.yml

4.编写启动类并且启动

4．创建EurekaClient服务提供着

@EnableEurekaClient: 该注解表明应用既作为eureka实例又为eureka client 可以发现注册的服务

（二）把其它服务注册到微服务里面
在pom.xml里面添加依赖,它本身的依赖正常加,再额外加这个依赖,这个依赖没有server结尾表示它就是一个client

org.springframework.cloud spring-cloud-starter-eureka 在启动类添加注解(红色部分是添加的注解)

@SpringBootApplication
@EnableEurekaClient /专属的注解,表示我是EurekaClient/
public class MicroserviceSimpleProviderUserApplication {

public static void main(String[] args) {
SpringApplication.run(MicroserviceSimpleProviderUserApplication.class, args);
}
配置自己微服务的application.yml 文件

（三）案例使用RPC实现两个服务通讯

很早以前就是用HTTPClient来实现的,
（四）错误信息解释

1．Cannot excute request on any known server
注册中心没有启动

项目一启动的时候会先连接注册信息,如果注册中心没有启动起来就会报错, 所以项目启动先启动注册中心(EurekaServer)
（五）EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE
如果看到这个,就说明Eureka开启了自我保护机制了

Ribbon(负载均衡)
（一）概念
1．什么是负载均衡

（二）建立负载均衡项目(消费端)
1．使用RestTemplate模版
spring-cloud-starter-eureka 依赖自带客户端调用工具,比如RestTemplate模版

Feign
（一）概念
1．基本介绍
Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只需要创建一个接口并注解。它具有可插拔的注解特性，可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。
2．Feign和RestTemplate比较
RestTemplate

Feign

feign默认开启负载均衡
/**
*

Feign的使用是穿件一个接口然后使用 @FeignClient(“cloud-config-service”)方法去链接ribbon

*/
// cloud-config-service = ribbon的application.yml中 application:name: cloud-config-service的名字
@FeignClient(“cloud-config-service”)
public interface AboutFeignClient
{
// @RequestMapping(value = “/user”) = ribbon中的/user方法名
@RequestMapping(value = “/user”)
public User findCameraInfos();
}

（二）使用

Hystrix(断路器)
（一）概念
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
为了解决这个问题，业界提出了断路器模型。

简单说
就是发送http请求出现异常了怎么处理,但是SpringCloud官方非得装逼说高大上名词断路器!!!

举例:
订单服务调用商品服务, 但是商品服务需要调用会员服务来完成订单服务的需求

如果调用会员服务连接超时了会怎么办呢?Hystrix就是调用失败了返回一些信息.比如错误信息

（二）使用
1．改造RestTemplate模版项目

org.springframework.cloud
spring-cloud-starter-hystrix

在接口上加入注解@HystrixCommand

/**

使用SpringCloud自带的RestTemplate 模版来调用别的服务
*/
@Service
public class HelloService {

@Autowired
private RestTemplate restTemplate;
/*加入断路器注解.
fallbackMethod表示失败时候调用什么方法方法需要的在下面书写
*/
@HystrixCommand(fallbackMethod = “error”)
public String hi(String name) {
/**调用别的服务
* url :写Eureka面板的Application名
* 第二个字数是返回值类型,比如Spring类型
*
*http://127.0.0.1:8763/hi?name=111 原来是这么调用的,但是我们需要给名字替换成Eureka名字
*/
return restTemplate.getForObject(“http://SERVICE-HI/hi?name=” + name, String.class);
}

/**
- 调用失败的方法
  */
  public String error(String name){
  return “参数为:”+name+",调用SERVICE-HI 失败啦!";
  }

}

在启动类加入注解@EnableHystrix/表示启动断路器/

@SpringBootApplication
@EnableEurekaClient
@EnableHystrix/表示启动断路器/
public class App {

public static void main(String[] args) {
SpringApplication.run(App.class, args);
}

/**
* 如果想使用 RestTemplate需要注入进来
*/
@Bean
@LoadBalanced /表示支持负载均衡/
RestTemplate restTemplate() {
return new RestTemplate();
}

}

演示断路器是否生效,可以停止掉被调用的服务(人为造成错误),这时候就会出现调用服务失败出现错误信息

2．改造Feign项目
不需要引入依赖,Feign自带断路器,默认不打开,需要在配置文件打开

在原有的功能只需要建立一个类并且实现你原有的接口

新建的类
@Component
public class SchedualServiceHiHystric implements FeignService {
/**
* 发生异常返回的一句话
*/
public String hi(String name) {
return “feign … name:” + name + " 系統錯誤,调用接口失败~!!";
}

}
原来的接口
/*
value是指定调用的服务
*fallback 执行的是失败时候返回的错误信息

*/
@FeignClient(value = “SERVICE-HI”, fallback = SchedualServiceHiHystric.class)
public interface FeignService {
@RequestMapping("/hi")
public String hi(String name);
}
yml文件

feign:
hystrix:
enabled: true #开启断路器

概念
（一）架构模式
1．单体架构以及缺点
所有的功能和程序都打到一个war包,就是单体架构程序.
很多项目都是从单体应用开始的。单体应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐减低，维护成本越来越高。

1业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
2随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
3、测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来一定的影响，导致测试难度增加。
4、部署时间长
5、某个应用坏了可能会导致整个程序崩溃
6、扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。
7、阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。例如，一个使用Struts2构建的、有百万行代码的单体应用，如果想要换用Spring MVC，毫无疑问切换的成本是非常高的。

2．08 09年的架构模式

缺点多人项目开发出现缺点代码冲突

3．SOA服务化架构模式
大型互联网公司会将项目拆分成多个项目,分配到不同的项目组进行开发的,根据业务模块拆分分给不同的项目小组,
大公司都是6个人左右一个团队,一个团队只是负责一个模块,比如只是登录模块,只是搜索模块.

拆分是根据业务需求拆分项目,由架构师来完成,每个项目都有自己单独的数据库,由不同的团队进行开发.

项目直接会暴露接口供别的项目调用,这个过程就叫RPC远程调用,比如订单服务需要调用商品服务.
RPC一般都是HTTP ,Dubbo,SpringCloud 等等.

现在大公司都是SpringCloud +Resuftl+Json
微服务
优点:就是解耦,一个服务挂了不影响别的服务,假如淘宝双十一订单模块挂了,但是首页不会挂.
分子项目互不影响
缺点:拆分成本高(适合大公司),开发效率低(RPC通信要写接口)

4．什么是微服务

微服务是一种架构风格,这个架构风格提倡我们在开发应用的时候,应该是作为一系列小服务的组合,它应该是一组小型的服务.而这些小型服务都运行在自己的进程之内,这些小型服务可以通过http的方式进行沟通.

就是将一个项目进行拆分成多个模块,多个模块之间通讯使用RPC远程调用技术

架构设计概念,各服务间隔离（分布式也是隔离）,自治（分布式依赖整体组合）其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行
SOA到微服务架构的演进过程
作用：各服务可独立应用，组合服务也可系统应用(巨石应用[monolith]的简化实现策略-平台思想)

单体项目缺点,慢慢项目越来越大,项目问题,非常臃肿,改一个模块整个项目都要全部发布,每次发布都有不同问题,解决办法就是把项目进行拆分.

微服务定位

好处:
每个模块功能都是单一的,代码量不如整到一起多,项目维护方便,每个微服务启动比较快(因为代码少).

技术栈不受限,单一项目只能是一个技术,(一个工程)而微服务架构(多个工程)每个小微服务都可以用自己想要的技术栈(A微服务是java语言,B微服务是PHP语言,哪个微服务的功能适合哪个语言做就用什么语言).你修改的只是你自己的微服务.

假如微服务A 要求运算能力高,你可以给这个微服务部署到性能好的机器, 微服务B是IO那种的,就给他部署到磁盘好的,单一的就不行了,如果一个微服务性能到了瓶颈了可以单独优化,比如A服务运算到瓶颈了,你可以只给A微服务的cpu进行升级.可以每个服务针对性的改进,

不会因为一个模块崩溃而所有的功能都崩溃.用户微服务出问题了不影响搜索微服务的使用.

缺点:
测试复杂,多个团队需要坐在一起联调(大公司沟通成本太高,毕竟好几个部门沟通)

需要使用分布式事务

接口调整的成本高,微服务之间接口通信,如果修改了一个微服务API,可能所有用该微服务的接口都需要调整.

运维要求比较高,微服务是多个war包,维护起来比单体项目(一个war包)难

分布式系统的复杂性,容错性,网络延迟等等都需要处理

重复劳动: 多个微服务的工具类可能因为语言不通用而工具类不通用

5．微服务设计原则
单一职责原则

服务自治原则
每个微服务都得有自己独立运行的能力,要有自己的数据库.可以单独运行,尽量不依赖其它的服务.
接口
每个服务对外接口应该明确定义,并且尽量保持不变

（二）基本概念
1．什么是分布式和集群
分布式
不同模块部署在不同服务器上,
作用：分布式解决网站高并发带来问题
集群
多台服务器部署相同应用构成一个集群
作用：通过负载均衡设备共同对外提供服务

2．SpringCloud基本概念
传统的http通信是用HTTPClient等等,缺点就是不安全,重复代码特别多,地址管理起来很麻烦.
SpringCloud解决了上面的问题

传统的http通信(RPC远程调用): !!!不是SpringCloud

远程调用，类似dubbo，
每一个springboot项目起来就是一个项目，多个项目起来就是多个tomcat，

SpringCloud目的是让这些微服务调用起来，实现原理就是给多个SpringBoot项目放在一个盒子里面。
第一个要解决的问题就是让这些微服务互相认识，
第二个要解决的问题就是能让这些微服务互相调用。(调用是通过访问Restful风格的url来实现的,换句话说,我们要调用的时候就是想办法要调用一个RestURL)
第三个问题:比如多个微服务互相乱七八糟调用(A微服务调用B微服务,B微服务调用C微服务,C微服务调用D微服务),假如一个D微服务挂了,那么C微服务也就不能用了(因为C调用D,)如果C微服务不能用了,B微服务也不能用了… 最后所有不能用了,这种情况在工作中不能发生, 你就得想办法去解决这个调用传递引发的雪崩效果 (就是你跺脚,发生震颤,震颤传递后就崩塌了.) 就是一个微服务不能用了最后导致整个微服务都不能用了. 解决办法就是给不能用的微服务剔除出去,让它不影响其它的功能
第四个问题:实际开发是前后端分离开发的,端口太多,记录太混乱,端口在页面只能写死,我们需要统一的入口,让前端只需要这个统一的入口即可(微服务统一入口)前端只需要记住微服务统一入口的端口号.
统一端口怎么知道访问的是A微服务还是B微服务,只需要在访问的路线上,需要提供对应的访问映射,比如A微服务就是 /base B微服务就是 /article C微服务就是 /qa D微服务就是 /search 这些不影响你原来的微服务,这些就叫路由规则,对于前端人员来说不用记住乱七八糟的端口号
第五个问题这些配置写在xml里面的, xml写在我们的工程里面, 但是我们是团队开发,团队开发存在的问题就是配置文件只有一个,你也改,我也改,他也改,改完之后就提交上去了,提交会冲突,还有可能会把别人的配置顶了.
这种情况不能发生.应该我们改的时候就是同一份,还有就是不能是我们改完了提交成同一份.
我们可以把有具体功能的配置文件放在Git,在修改的时候,所有开发人员都到Git修改.好处就是配置文件始终只有一份.就这一份.
还需要考虑配置文件从本地删除之后,得从Git从网上下载在本地上才行. 如果修改本地配置文件了你还需要同步,不能重启服务来更新配置文件,(互联网项目最忌讳这个问题,因为你重启了项目所有网民的暂时不能使用可能会造成金钱的损失)
思路:修改配置文件需要让微服务知道,发送请求让微服务加载它,选择用异步的思路,用消息队列(发送请求往队列里面写个消息,准备加载配置文件,从消息里面读出来就加载配置文件)

两个应用之间怎么互相调用，如果不用SpringCloud的情况下，就用
1.httpclient(其中之一). 就是发送一个请求,
2.2.表单自动提交
3.重定向
这三个相同的地方就是得知道地址(发请求地址,重定向地址等等,都是地址)

SpringCloud六个部分
1.注册发现中心Eureka (让微服务互相认识)
2.调用中心 Feign (让微服务互相认识)

3.熔断器Hytrix
4.微服务网关 Zuul
5.配置中心 Config
6.消息总线 Bus

3．SpringCloud组件
SpringCloud就是一个RPC微服务框架,提供注册服务,发现服务,断路器,网关,自动配置.
Eureka(注册中心),Ribbon(负责均衡),Rest,Feign(http协调调用工具),断路器Hystrix ,Zuul(网关系统) 分布式配置中心

底层通过Http Client进行封装.

前面介绍了很多Spring Cloud的组件，本篇按照自己的角度来做一次归纳。

Spring Cloud技术应用从场景上可以分为两大类：润物无声类和独挑大梁类。

润物无声，融合在每个微服务中、依赖其它组件并为其提供服务。

Ribbon，客户端负载均衡，特性有区域亲和、重试机制。

Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。

Feign，声明式服务调用，本质上就是Ribbon+Hystrix

Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。

Bus，消息总线，配合Config仓库修改的一种Stream实现，

Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

独挑大梁，独自启动不需要依赖其它组件。

Eureka，服务注册中心，特性有失效剔除、服务保护。

Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

Zuul，API服务网关，功能有路由分发和过滤。

Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，

每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。

Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。

Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。

Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。

Turbine是集群收集器，服务于Dashboard的。

Feign是方便我们程序员写更优美的代码的。

Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。

Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。

Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。

Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。

Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。

特殊成员Zipkin，之所以特殊是因为从jar包和包名来看它不属于Spring Cloud的一员，但是它与Spring Cloud Sleuth的抽样日志结合的天衣无缝。乍一看它与Hystrix的Dashboard作用有重叠的部分，但是他们的侧重点完全不同。Dashboard侧重的是单个服务的统计和是否可用，Zipkin侧重的监控环节时长。简言之，Dashboard侧重故障诊断，Zipkin侧重性能优化。

4．什么是服务
服务其实就是接口

什么是提供服务
其实就是提供接口
什么是消费服务
其实就是调用接口

5．创建调用关系的微服务
创建存在调用关系的微服务，调用关系如下

服务消费者调用别的微服务的微服务
服务提供者提供API的微服务

6．为什么需要注册中心
由于在分布式开发中，每个服务都是分开部署，甚至于在多台服务器之中，这个时候每隔服务之间的通信以及服务器的稳定性的管理，所以我们需要将这些服务全部注册到一个地方然后将他们管理起来，

所以用到了我们的注册中心，那么注册中心能给我们提供哪些帮助呢？
1、加强服务与服务之间的通信
2、加强服务与服务之间的管理
3、及时处理服务器宕机以及其他问题

7．注册中心的（简单）结构是什么样的呢？

我们是将服务都注册到注册中心之中，其实注册中心也是一个服务不过它是用来管理其他的服务的,我们可以在注册中心当中注册多个服务端然后通过客户端来调取服务端的服务，这样就能加强服务与服务之间的通信了,然后因为如果代理了很多服务如果其中一个发生了宕机或者崩溃或者其他的不确定因素导致的不能正常运行，那么均衡负载器还是会继续的发送服务这样的话就会返回错误或者卡死或者崩溃，那么这将会是一场灾难性的故障，所以我们用到注册中心来管理，如果发现了服务器宕机等等原因导致的不能正常访问，那么就自动的将宕掉的服务器断开连接（通过熔断技术将服务器断开）
(也称断路器），这样的话我们就不需要去重启Nginx了，然后将服务器重启或者维护好之后再将他注册到注册中心当中就能高效率地容灾了,以前我们的Nginx当中只是做到了反向代理和均衡负载，但是这些东西在Spring-Cloud当中的组件也有

8．SpringCloud调用服务有哪些方式
调用服务其实就是调用http协议接口,
调用服务使用 :restTemplate和 feign

qq_1003669233

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud学习笔记

Eureka（一）服务发现组件Eureka1．Eureka概念Eureka是Netflix的一个子模块,也是核心模块之一,Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移功能类似注册中心,注册中心就是将一些服务的服务信息注册到注册中心上面去(不要想的多难),其实就是把你要提供的接口信息,放到系统里面可以查询出来,可以知道有多少个接口注册中心有很多,比...
复制链接

扫一扫