微服务笔记

最新推荐文章于 2024-11-11 21:19:25 发布

置顶即将秃头的入门小白

最新推荐文章于 2024-11-11 21:19:25 发布

阅读量259

点赞数

分类专栏：笔记 java 文章标签： java

本文链接：https://blog.csdn.net/weixin_42423927/article/details/109675195

版权

java 同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

笔记

2 篇文章 0 订阅

订阅专栏

什么是微服务

就目前而言，对于微服务业界没有一个统一的，标准的定义。
但是通常而言，微服务架构师一种架构模式或者说是一种架构风格，
他提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的继承中，服务之间互相协调，互相配合。

微服务的理论

设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

微服务之间如何独立通讯的

服务之间采用轻量级的通信机制互相沟通，通常是基于HTTP的RESTFUL API.

微服务的优缺点是什么

1.1 使用微服务架构好处:

1. 服务的独立部署
每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
2. 服务的快速启动
拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量少了。
3. 更加适合敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代，循序渐进的方法进行。
服务拆分可以快速发布新版本，修改哪个服务只需发布对应的服务即可，不用整体重新发布。
4. 职责专一，由专门的团队负责专门的服务
业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，
服务的拆分有利于团队之间的分工。
5. 服务可以动态按需扩容
当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
6. 代码的复用
每个服务都提供REST API,所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

1.2微服务的劣势：

1.分布式部署，调用的复杂性高
单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是
独立部署的，通过HTTP来进行通信，这当中会产生很多问题，比如网络问题，容错问题，
调用关系等。
2. 独立的数据库，分布式事务的挑战
每个微服务都有自己的数据库，这就是所谓的去中心化的数据库管理。这种模式的
有点在于不同的服务，可以选择适合自己业务的数据，缺点就是事务的问题。
3. 测试的难度提升
服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，
这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。
4. 运维难度的提升
在采用传统的单体应用时，我们可能只需要一个Tomcat的集群，一个MySQL的集群就可以了，
但这在微服务架构下是行不通的。当业务增加时，服务也越来越多，服务的部署，监控将变得非常复杂。

什么是服务熔断，什么是服务降级

服务熔断:

在微服务架构中，微服务之间的数据交互通过远程调用完成，微服务A调用微服务B和
微服务C，微服务B和微服务C又调用其他的微服务，此时如果链路上某个微服务的调用
响应时间过长或者不可用，那么对微服务A的调用就会占用越来越多的系统资源，进而引起
系统崩溃，导致“雪崩效应”。

服务熔断是应对雪崩效应的一种微服务链路保护机制。例如再高压电路上，如果某个地方的
电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似
的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点
微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，回复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败
的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。

服务熔断解决如下问题: 1.当所依赖的对象不稳定时，能够起到快速失败的目的；
2.快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。

服务降级:

服务降级是指当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或
换简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系
统资源让给优先级高的服务


自动降级分类:
1.超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况。
2.失败次数降级:主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步
机制探测回复情况。
3. 故障降级
4. 限流降级

服务熔断和服务降级的区别

触发原因不太一样，服务熔断一般是某个服务(下游服务)故障引起，而服务降级一般是从整体符合考虑；

管理目标的层次不太一样，熔断其实是一个框架的处理，每个服务都需要(无层级之分)，而降级一般需要
对业务有层级之分(比如降级一般是从最外围服务开始)。

实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

限流:限制并发的请求访问量:超过阀值则拒绝；

降级:服务分优先级，牺牲非核心服务(不可用)，保证核心服务稳定；从整体负荷考虑；

熔断:依赖的下游服务故障触发熔断，避免引发本体统崩溃,系统自动执行和回复。

微服务为什么需要注册中心，重试机制，熔断措施等

为了能够动态扩容，你的服务需要自动注册且能被主动发现。因此需要个注册中心。

网络之间的调用较为不可靠，因此还需要让调用有重试机制，防止其他服务处bug或其他原因疯狂调用你的服务，HIA㤇有限流措施，为了防止一个服务挂了导致整体的雪崩需要有熔断措施。

为了在特殊嗜好例如大粗的时候让出硬件资源给核心功能，还需要有降级策略。

而且每个服务都需要配置，因此还得有个配置中心，来做统一管理。

服务太多了，调用关系复杂为了对调用者更加的友好，并且还需要对调用进行权限等控制，因此需要有个网关，对外暴露统的接口，当然限流什么的可以再网关实现。

当然整体的监控是必不可少少的，对所有的服务都需要做到全面的监控。

SOA和微服务

SOA和微服务两种都是面向服务的，只是SOA注重的是企业资源的重复利用，把企业的各个应用通过ESB进行整合。微服务注重的是应用级别的服务划分，使得应用内服务边界清晰，易扩展。

分布式和集群

分布式可以认为是通过网络连接多个组件而形成的系统。

广义上说前后分离的应用就能算分布式，前端的js代码在浏览器跑着，后端的代码再服务器跑着，两种不同的组件合力对外提供服务构成分布式。

而我们常提到的分布式是狭义上的，织带不同的组件通过写作构成的系统。

而集群常指的同一个组件多实列而构成逻辑上的整体。

这两个概念不冲突，分布式系统里面可以包含集群。

RPC:

RPC:远程过程调用，他是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。

RPC是一种技术思想而非一种规范或协议，常见RPC技术框架有：

应用级的服务的框架: 阿里的Dubbo/Dubbox,Google gRPC,Spring Boot /Spring Cloud
远程通信协议：RML,Socket,SOAP(HTTP XML)，REST(HTTP JSON)
通信框架:MINA和Netty

一个RPC的核心功能主要有5个部分组成，分别是客户端，客户端Stub,网络传输模快，服务端Stub,服务端等。

RPC的主要组成:

客户端(Client): 服务调用方
客户端存根(ClientStub): 存放服务端地址信息，将客户端的请求参数数据信息打包成网格信息，再通过网络传输发送给服务端。
服务端存根(Server Stub): 接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
服务端(Server): 服务的真正提供者
Network Service: 底层传输，可以试TCP或HTTP

一次RPC调用流程如下:

服务消费者(Client客户端)通过本地调用的方式调用服务
客户端存根(Client Stub)接收到调用请求后负责将方法，入参等信息序列化(组装)成能够进行网络进行网络传输的消息体。
客户端存根(Client Stub) 找到远程的服务地址，并且将消息通过网络发送给服务端
服务端存根(Server Stub) 收到消息后进行解码(反序列化操作)
服务端存根(Server Stub) 根据解码结果调用本地的服务进行相关处理
服务端(Server) 本地服务业务处理
处理结果返回给服务端存根(Server Stub)
服务端存根(Server Stub)序列化结果。
服务端存根(Server Stub)将结果通过网络发送至消费方。
客户端存根(Client Stub)接收到消息，并进行解码(反序列化)。
服务消费方得到最终结果。

SpringCloud:

什么是SpringCloud:

SpringCloud,基于SpringBoot提供了一套微服务解决方案，包括服务注册于发现，配置中心，全链路监控，服务网关，负载均衡，熔断器组件等，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中心的开源组件。

SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务结构落地技术的集合体，俗称微服务全家桶。

SpringCloud和SpringBoot关系:

SpringBoot专注于快速方便的开发单个个体服务。

SpringCloud是关注全局的微服务协调整理框架，他将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供:配置管理，服务发现，熔断器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。

SpringBoot可以离开SpringCloud独立使用，开发项目，但是SpringCloud离不开SpringBoot，输入依赖关系。

SpringBoot专注于快速，方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架。

SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式.

SpringCloud和Dubbo有哪些区别:

解决的问题领域不一样:Dubbo的定位是一款RPC框架，SpringClound的目标是微服务架构下的一站式解决方案。

CAP:C(一致性),A(可用性),P(容错性)

ACID:A(原子性)，C(一致性),I(隔离性)D(持久性)

CAP的三进二:CA,AP,CP

CAP理论的核心:

一个分部是式系统不可能同时很好的满足一致性，可用性和分区容错性这个三个需求
根据CAP原理，将nosql数据库分成了满足CA原则

满足CP原则和满足AP原则三大类:

CA:单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP:满足一致性，分区容错性的体统，通常性能不是特别高
AP:满足可用性，分区容错性的系统，通常可能对一致性要求低一些

SpringCloud分布式开发五大组件:

服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config

什么是服务发现(Eureka):

Eureka遵循的是AP原则。
Eureka是Netflix的一个子模块,也是核心模快之一，是基于REST的服务，用于定位服务，实现云端中间层服务发现。
Eureka采用了C-S的架构设计，EurEka的客户端连接到EurekaServer作为服务注册功能的服务器，他是服务注册中心。

Eureka包含两个组件:Eureka Server 和 Eureka Client。

Eureka Server 提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以咋几面中直观的看到。
Eureka Client是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳。EurekaServer将会从服务注册表中把这个服务节点移除掉(默认周期为90秒)。

Eureka自我保护机制:

总结:某时刻某一个微服务不可用，Eureka不会立刻清理，依旧会对该服务的信息进行保存。！

默认情况下，如果Eureka在一定时间内容没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例(默认90秒)。但是网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了-因为微服务本身其实是健康的，此时不应该注销这个服务。Eureka通过自我保护机制来解决这个问题-当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。
在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当他收到的心跳重新恢复到阀值以上时，该EurekaServer节点就会自动退出自我保护模式。他的设计哲学就是宁可保留错误的服务注册信息，也不盲目销毁任何可能健康的服务实例。一句话：好死不如赖活着。
自我保护模式是一种应对网络异常的安全保护措施。他的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留)，也不盲目注销任何健康的微服务。使用自我保护模式。可以让Eureka集群更加的健壮和稳定。
在SpringCloud中，可以eureka.server.enable-self-preservation 来打开(true默认)/禁用(false)自我保护机制(不推荐关闭自我保护机制)

什么是客服端负载均衡(Ribbon):

SpringCloud Ribbon是基于Netflix(net父类可死) Ribbon实现的一套客户端负载均衡的工具。
简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客服端的软件负载均衡算法，将NetFlix的中间层服务连接再一起。Ribbon的客户端组件提供一系列完整的配置项如:连接超时，重试等等。简单的说，就是在配置文件中列出LoadBalancer(简称LB:负载均衡)后面所有的机器，Ribbon会自动的帮助你基于某种规则(如简单轮询，随机连接等等)去连接这些机器。

Ribbon能干嘛?

LB,即负载均衡（Load Balance），在微服务或分布集群中经常用的鄂一中应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA(高可用)。
常见的负载均衡软件有Nginx,Lvs等等
dubbo,SpringCloud中均有给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义

负载均衡简单分类:

集中式LB：即再服务的消费提供方之间使用独立的LB设施，如Nginx,由该设施负责把访问请求通过某种策略转发至服务的提供方。
进程式LB：将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。Ribbon就属于进程内LB，他只是一个类库，消费方通过他来获取到服务提供方的地址。

Ribbon流程图:

服务提供者把服务注册到Eureka中去，Ribbon服务消费方从Eureka中查询可用的服务列表。然后去负载均衡服务选择服务提供者。

Feign负载均衡

简介：feign是声明式的web Service客户端,他让微服务之间的调用之间的调用变得更简单了，类型controller调用service，Spring Cloud集成了Ribbon和Rureka，可在使用Feign时提供负载均衡的http客户端。

只需要创建一个接口，然后添加注解即可!

fegin调用微服务访问的两种方法:

微服务名字(ribbon)
接口和注解(feign)

Feign能干什么？

在Fegin的实现下，我们只需要创建一个接口并使用注解的方式来配置他（在微服务接口上面标注一个Fegin注解即可），即可完成对服务提供方的接口绑定，简化了使用SpringCloud Ribbon时，自动封装服务调用客户端的开发量。

什么是断路器(Hystrix):

Hystrix是一个用于分布处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

"断路器"本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个服务预期的，可处理的备选响应(FallBack),而不是长时间的等待或者破抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布系统中的蔓延，乃至雪崩。

Hystrix可以干嘛:

服务降级
服务熔断
服务限流
接近实时监控

什么是服务网关(Zuul):

Zuul包含了对请求的路由和过滤两个最主要的功能:

其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

注意:Zuul服务最终还是会注册到Eureka

提供:代理+路由+过滤

Zuul能干嘛?

路由，过滤

什么是分布式配置(Config):

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。方便部署与运维。
分客户端、服务端。
　　服务端也称分布式配置中心，是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
客户端则是通过指定配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。默认采用 git，并且可以通过 git 客户端工具来方便管理和访问配置内容。

eureak和zookeeper都可以提供服务注册于发现的功能，两个的区别：

作为服务注册中心，EurEka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性),A(可用性),P(容错性)

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

Zookeeper保证的是CP:

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用，也就是说，服务注册功能对可用性的要求要高于一致性，但是Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader(领导者)选举。问题在于，选举Leader时间太长，30-120s,且选举期间整个Zookeeper集群都是不可用的，这就导致再选举期间注册服务瘫痪，再云部署的环境下，因为网络问题使得Zookeeper集群失去mster节点是较大概率发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureak保证的是AP：

Eureka看明白了这一点，因此在设计时就优先保证可用性，Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客服端再向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果再15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况。