微服务学习笔记

最新推荐文章于 2024-06-21 09:39:30 发布

Six_GodHLS

最新推荐文章于 2024-06-21 09:39:30 发布

阅读量875

点赞数

本文链接：https://blog.youkuaiyun.com/sinat_34979820/article/details/108180397

版权

本文是一篇关于微服务架构的全面学习笔记，涵盖了微服务的定义、优缺点、技术栈选择，特别是深入探讨了SpringCloud生态系统，包括Eureka服务发现、Ribbon客户端负载均衡、Feign声明式调用、Hystrix断路器、Zuul路由网关以及SpringCloud Config配置管理。文章详细阐述了每个组件的作用和工作原理，为读者提供了丰富的微服务实践知识。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

微服务学习笔记

开始吧

微服务

1.什么是微服务架构

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

2.什么是微服务

微服务强调的是服务的大小，它关注的是某一点，具体解决某一问题/提供落地
对应服务的一个服务应用，狭义的看，可以看作IDEA里面一个个微服务工程/或者Module

通俗的讲就是：
IDEA工具里面maven开发的一个个独立的小moudle，他具体是使用
springboot开发的一个小模块，专业的事情交给专业的模块来做，一个模块就做一件事情
强调的是一个个的个体，每个个体完成一个具体的任务或者功能

3.微服务优缺点

优点：
每个服务足够内聚，足够小，代码容易理解这样聚焦一个指定的业务功能或业务需求
开发简单、开发效率提高、一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的
微服务能使用不同的语言开发
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins，Hudson、Bamboo。
微服务易于被一个开发人员理解、修改、维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术
微服务只是业务逻辑的代码，不会和HTML，Css，或其它界面组件混合
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。

缺点：
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控。。。。。。。

4.微服务技术栈有哪些

微服务条目	落地技术	备注
服务开发	Springboot、Spring、SpringMvc
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zkeeper等
服务调用	Rest、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx
服务接口调用（客户端调用服务端的简化工具）	Fegin等
消息队列	Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloud、Chef等
服务路由(API网关)	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spectator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、Openstack、Kubernetes等
数据流程操作开发包	SpringCloud Stream(封装与Redis、Rabbit、Kafka等发送接收消息)
事件消息总线	Spring Cloud Bus
…	…

SpringCloud

1.为什么选择SpringCloud

功能点/服务框架	Netfix/Sping cloud	Motan	gRPC	Thrift	Dubo/DubboX
功能定位	完整的微服务框架	RPC框架，但整合了ZK或Consul，实现集群环境的基本的服务注册/发现	RPC框架	RPC框架	服务框架
支持Rest	是 Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是(Hession2)	是	是	是
支持多语言	是(Rest形式)?	否	是	是	否
服务注册/发现	是(Eureka) Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查	是(Zookeeper/Consul)	否	否	是
负载均衡	是(服务端zuul+客户端Ribbon) Zuul-服务，动态路由云端负载均衡Eureka(针对中间层服务器)	是(客户端)	否	否	是(客户端)
配置服务	Netflix Archaius SpringCloud Config Server集中配置	是(Zookeeper提供)	否	否	否
服务调用链监控	是(zuul) Zuul提供边缘服务、API网关	否	否	否	否
高可用/容错	是(服务端Hystrix+客户端Ribbon)	是(客户端)	否	否	是(客户端)
典型应用案例	Netflix	Sina	Google	Facebook
社区活跃程度	高	一般	高	一般	2017年前停止维护
学习难度	中等	低	高	高	低
文档丰富度	高	一般	一般	一般	高
其他	SpringCloudBus 为我们的应用程序带来更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践的公司比较多

2.SpringCloud是什么

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

SpringCloud 利用Springboot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。

SpringBoot并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

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

3.SpringCloud和SpringBoot的区别与关系

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

SpringCloud是关注全局的微服务协调治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来。

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

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

4.SpringCloud和Dubbo的区别

	Dubbo	SpringCloud
服务注册中心	Zookeeper	SpringCloud Netflix Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	SpringCloud Netflix Hystrix
服务网关	无	SpringCloud Netflix Zuul
分布式配置	无	SpringCloud Config
服务跟踪	无	SpringCloud Sleuth
消息总线	无	SpringCloud Bus
数据流	无	SpringCloud Stream
批量任务	无	SpringCloud Task

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

严格来说，这两种方式各有优势。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，在这强调快速演化的微服务环境下，显得更加适合。

品牌机与组装机的区别
很明显，SpringCloud的功能比Dubbo更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很可能因为一条内存质量不行就点不亮了，总让人不怎么放心，但是如果你是一名高手，那些都不是问题；而SpringCloud就像品牌机，在SpringSource的整合下，做了大量的兼容性测试，保证了及其拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

社区支持与更新力度
最为重要的是，Dubbo停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级(比如当当网的DubboX)，这对于很多想采用微服务架构的中小软件组织，显然不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。

5.Spring Cloud 官网及中文社区

SpringCloud官网地址https://spring.io/projects/spring-cloud

https://springcloud.cc/spring-cloud-netflix.html

相关API中文说明:https://springcloud.cc/spring-cloud-dalston.html

springcloud中国社区:http://springcloud.cn
springcloud中文网:https://springcloud.cc

6.Spring Cloud国内使用情况

阿里云：
在这里插入图片描述

Eureka

1.什么是Eureka

Eureka 是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如Zookeeper。

2.Eureka基本架构

在这里插入图片描述

3.Eureka与Zookeeper对比

著名的的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP
Eureka保证的是AP。

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

Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性，Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，而Eureka的客户端再向某个Eureka注册时如何发现连接失败，则会自动切换至其它节点，只有一台Eureka还在，就能保证注册服务可用(保证可用性)。只不过查询到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现网络故障，此时会出现以下几种情况：
1.Eureka不再从注册中心列表中移除因为长时间没收到心跳而应对过期的服务
2.Eureka仍然能够接受服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3.当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此，Eureka可以很多好的应对网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Ribbon

1.Ribbon是什么

SpringCloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balanceer(简称LB) 后面所有的机器，Ribbon会自动的帮助你基于某种原则(如简单轮询，随机连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

LB，即负载均衡(load Balance)，在微服务或分布式集群中经常用的一种应用。负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA(高可用)。常见的负载均衡有软件Nginx，LVS，硬件F5等。
相应的在中间件，例如：dubbo和SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。

集中式LB：
即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件、如F5，也可以是软件，如Nginx)，由该设施负责把访问请求通过某种策略转发至服务的提供方。

进程内LB：
将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

Feign

1.Feign是什么

Feign是一个声明式WebService客户端，使用Feign能让编写Web Service客户端更加简单，它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解，Feign也支持可拔插式的编码器和解码器。SpringCloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

Feign是一个声明式的Web服务客户端，使得编写Web服务客户端变得非常容易。
只需要创建一个接口，然后在上面添加注解即可。

2.Feign能干什么

Feign旨在使编写Java Http客户端变得更容易。
前面在使用Ribbon+RestTemplate时，利用RestTemplate对http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多出调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可)，即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。

Feign集成了Ribbon
利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过feign只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。

Feign通过接口的方法调用Rest服务(之前是Ribbon+RestTemplate)
该请求发送给Eureka服务器(http://MICROSERVICECLOUD-DEPT/dept/list)，通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用。

Hystrix断路器

1.Hystrix是什么

服务雪崩
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”，如何扇出的链路上某个微服务的调用响应时间过长或者不用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源在几秒钟内饱和，比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

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

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

2.服务熔断

熔断机制是应对雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息，当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内2次调用失败就会启动熔断机制，熔断机制的注解是@HystrixCommand。

一般是某个服务故障或者异常引起，类似现实世界中的“保险丝”，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时。

2.服务降级

服务降级处理是在客户端实现完成的，与服务端没有关系。

整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

所谓降级，一般是从整体负荷考虑，就是当某个服务熔断之后，服务器将不再被调用。

此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。

这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强。

Zuul路由

1.Zuul路由是什么

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

注意：Zuul服务最终还是会注册进Eureka
提供=代理+路由+过滤三大功能。