springcloud微服务基本概念

热水养鲨鱼

于 2024-10-11 14:12:23 发布

阅读量442

点赞数 8

分类专栏： springcloud 文章标签： java

本文链接：https://blog.csdn.net/weixin_42477252/article/details/105925094

版权

springcloud 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

微服务架构的4个核心问题

1.服务很多，客户端怎么访问

   2.这么多的服务，服务之间怎么通信

   3.这么多的服务，怎么统一治理

   4.服务挂了怎么办

解决方案：
SpringCloud 生态

1.Spring Cloud NetFlix 一站式解决方案！但停更了
   api网关，zuul组件
   Feign---》httpClient---》Http通信方式，同步，阻塞
   服务的注册与发现：Eureka
   熔断机制：Hystrix

2.Apache Dubbo zookeeper 半自动需要整合别人的
   API:没有，找第三方组件
Dubbo：基于java实现的RPC通信框架
zookeeper：注册与发现
没有熔断机制，可借助Hystrix

3.Spring Cloud Alibaba 一站式解决方案，更简单

本质：
1.API网关
2.HTTP,RPC
3.注册与发现
4.熔断机制

网络不可靠，所以需要解决分布式带来的问题

常见面试题：
1.1 什么是微服务？
1.2 微服务之间是如何独立通讯？
1.3 SpringCloud和Dubbo有哪些区别？
1.4 SpringBoot和SpringCloud，请谈谈对他们的理解
1.5 什么是服务的熔断？什么是服务的降级
1.6 微服务的优缺点是分别是什么？谈谈你在项目开发中遇到的坑（微服务的缺陷）
1.7 你所知道的微服务技术栈有哪些？
1.8 eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？

什么是微服务

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

从技术维度理解：

微服务化的核心就是传统一站式应用，根据业务拆分成一个个服务，彻底的去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自己单独启动或销毁，拥有自己独立的数据库。

2.2、微服务与微服务架构

微服务

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

每个个体完成一个具体的任务或者功能

微服务架构

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值，每个服务运行在其独立的进程中，服务于服务间采用轻量级别的通信机制互相协作，每个服务都围绕着具体的业务构建，并且独立的部署在生产环境中，另外，应尽量避免统一的，集中式服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建。

2.3、微服务优缺点

优点：

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

缺点：

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

2.4、微服务技术栈有哪些？

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

2.5、为什么选SpringCloud作为微服务架构

1.选型依据

整体解决方案和框架成熟度
社区热度
可维护性
学习曲线

2.各微服务框架对比

功能点	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务框架	RPC框架但整合Zookeeper	RPC框架	RPC框架	服务框架
支持Rest	是，Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是	是	是	是
支持多语言	是	否	是	是	否
负载均衡	是（zuul服务，动态路由）	是（客户端）	否	否	是（客户端）
配置服务	Netflix Archaius，SpringCloudConfigServer集中配置	是（Zookeeper）	否	否	否
服务调用链监视	是（zuul），zuul提供边缘服务，Api网关	否	否	否	否
高可用/容错	是（服务端Hystrix+客户端Ribbon）	是（客户端）	否	否	是
经典案例	Netflix	Sina	Google	Facebook
社区活跃程度	高	一般	高	一般	2017重新开始，之前停止5年
学习难度	中	低	高	高	低

3.2、Spring Cloud和Spring Boot关系

Spring Boot专注于快速方便开发单个个体微服务
Spring Cloud是关注全局的微服务协调整理治理的框架，它将Spring Boot开发的一个个单体微服务整合并管理起来，为哥哥微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。
Spring Boot可以离开Spring Cloud独立使用，开发项目，但是Spring Cloud离不开Spring Boot，属于依赖关系

Spring Boot专注于快速、方便开发单个个体微服务、Spring Cloud关注全局的微服务治理框架

Dubbo和Spring Cloud对比

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

最大区别：Spring Cloud 抛弃了Dubbo的RPC通信，采用基于HTTP的REST方式、

Spring Cloud牺牲了服务调用的性能，但也避免了原生RPC带来的问题
REST相比RPC更为灵活，服务提供和调用方依赖只靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

品牌机和组装机区别

很明显Spring Cloud功能比Dubbo更加强大，涵盖面更广，可以和Spring家族更好的融合，这在微服务方面是至关重要的。

使用Dubbo搭建微服务架构就像组装电脑，各个环节选择的自由度很高。

Spring Cloud 具有更高的稳定性

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

Spring Cloud

参考书：

Spring Cloud Netflix 中文文档参考手册中文版

中文api文档：Spring Cloud Dalston 中文文档参考手册中文版

中国社区Grail Codegen-Grail体系的代码生成器

Spring Cloud中文网Spring Cloud中文网-官方文档中文版

RPC和REST实现服务之间通信的区别

什么是RPC

远程方法调用，就是像调用本地方法一样调用远程方法。

什么是REST

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。

REST不仅是CRUD(CRUD Boy哈哈)，不过REST也比较适合做CRUD。

REST使用HTTP的方法，例如：GET,POST,PUT,DELETE,OPTIONS还有比较不常用的PATCH方法。
RPC通常只会使用GET和POST方法，GET方法通常用来获取信息，POST方法可以用来进行所有的行为。

举个简单的例子，如果有REST的API: DELETE /user/1 ，那么通过RPC来实现就是 /deleteUser, HTTP的body是{"id": 1}。这两个实现没有太多的不同，而最大的不同是如何处理行为，在RPC中，可以比较清晰的设计API POST /doWhatevevThingNow，仅仅通过URL就能理解这个API的含义，而REST会让你觉得其只适合进行CRUD的操作。

REST与RPC应用场景

REST和RPC都常用于微服务架构中。

1、HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
  
2、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

最后建议

REST调用及测试都很方便，RPC就显得有点繁琐，但是RPC的效率是毋庸置疑的，所以建议在多系统之间的内部调用采用RPC。对外提供的服务，Rest更加合适个人理解

RPC特点：调用远程服务就像调用本地函数那样使用远程服务

REST特点：调用远程服务通过RESTFul架构风格使用http请求

Eureka注册中心

什么是Eureka

Netflix在设计时，遵循AP原则

Eureka是一个基于REST的服务，用于定位服务，以实现云端中间服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务标识符就可以访问服务，而不需要修改服务调用的配置文件，功能呢类似于Dubbo的注册中心，Zookeeper

原理讲解

Eureka的基本架构

Spring cloud封装Netflix公司开发的Eureka模块来实现服务注册与发现
Eureka采用C-S架构设计，Eureka Server作为服务注册功能的服务器，他是服务注册中心
而系统中的其他微服务，使用Eureka客户端连接到Eureka Server作为服务注册功能的服务器并维持心跳（比如每5秒进行连接）连接，这样系统的维护人员可以通过Eureka Server 来监控系统各个微服务是否正常运转。

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

三大角色：

Eureka Server ：提供服务的注册与发现

Service Provider：将自身服务注册到Eureka中，从而使消费方找到

Service consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务