springcloud基础理论学习一

水深无声 2024-04-17 23:02 72阅读 0赞

> springcloud学习前提：需要具备一定的java、springboo等相关知识，加油，为自己鼓掌大气....

参考链接：[https://www.cnblogs.com/kashowres/p/9011665.html][https_www.cnblogs.com_kashowres_p_9011665.html]

参考链接：https://blog.csdn.net/q15102780705/article/details/100045375

### 1.1什么是微服务 ###

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

## 怎么学习使用?在接下来的学习中，我们将主要围绕以下红色重点知识再学习. ##

## 服务的注册与发现（Eureka） ##

## 服务消费者（rest+Ribbon） ##

## 服务消费者（Feign） ##

## 断路器（Hystrix） ##

## 断路器监控（Hystrix Dashboard） ##

## 路由网关（Zuul） ##

## 分布式配置中心（Spring Cloud Config） ##

## 消息总线（Spring Cloud Bus） ##

## 服务链路追踪（Spring Cloud Sleuth） ##

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

### 1.3 SpringCloud和Dubbo有哪些区别 ###

Dubbo通信机制基于RPC远程过程调用、SpingCloud基于RESTful API调用

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

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

品牌机与组装机的区别

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

社区支持与更新力度

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

### 1.4 SpringBoot和SpringCloud，请你谈谈对他们的理解 ###

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

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

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

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

### 1.5 什么是服务熔断？什么是服务降级 ###

### 1.6 微服务的优缺分别是什么？说下你在项目开发中碰到的坑 ###

优点

l  每个服务足够内聚，足够小，代码容易理解这样能聚集一个指定的业务功能或业务需求

l  开发简单、开发效率提高，一个服务可能就是专一的只干一件事

l  微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成

l  微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的

l  微服务能使用不同的语言开发

l  易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins，Hudson，bamboo

l  微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作体现价值。

l  微服务允许你利用整合最新技术

l  微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件混合

l  每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库

缺点

开发人员要处理分布式系统的复杂性

多服务运维难度，随着服务的增加，运维的压力也在增大

系统部署依赖

服务间通信成本

数据一致性

系统集成测试

性能监控…………

开发中，我们们有两种开发模式

1． 前后端分离

a)      我们Java程序员，相对而言比较幸福，why?

b)      我们只需要管理后端，给前端的H5工程师就按照约定

c)       Rest地址+输入参数格式和报文约定+输出参数

$.post\{rest,jsonParameter,callBack\}

可以灵活搭配，连接公共库+连接独立库？？？

2.全栈工程师

H5+javaEE+………..

### 1.7你所知道的微服务技术栈有哪些？请列举一二 ###

微服务技术栈：多种技术的集合体

我们再讨论一个分布式的微服务架构的话，它需要有哪些维度？？

一个分布式的微服务架构       维度       E时代下的数字化生活

服务治理                                                                      手机

服务注册                                 电脑

服务调用                                充电宝

服务负载均衡                            路由器

服务监控                                                                      ……           小米科技

各个杂牌

SpringCloud

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 微服务条目 </td> 
 <td style="vertical-align:top;"> 落地技术 </td> 
 <td style="vertical-align:top;"> 备注 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务开发 </td> 
 <td style="vertical-align:top;"> SpringBoot、Spring、SpringMVC </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务配置与管理 </td> 
 <td style="vertical-align:top;"> Netflix公司的Archaius、阿里的Diamond等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务注册与发现 </td> 
 <td style="vertical-align:top;"> Eureka、Consul、Zookeeper等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务调用 </td> 
 <td style="vertical-align:top;"> Rest、RPC、GRP C </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务熔断器 </td> 
 <td style="vertical-align:top;"> Hystrix、Envoy等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 负载均衡 </td> 
 <td style="vertical-align:top;"> Ribbon、Nginx等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务接口调用 （客户端调用服务的简化工具） </td> 
 <td style="vertical-align:top;"> Feign等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 消息队列 </td> 
 <td style="vertical-align:top;"> Kafka、RabbitMQ、ActiveMQ等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务配置中心管理 </td> 
 <td style="vertical-align:top;"> SpringCloudConfig、Cherf等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务路由（API网关） </td> 
 <td style="vertical-align:top;"> Zuul等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务监控 </td> 
 <td style="vertical-align:top;"> Zabbix、Nagios、Metrics、Spectator等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 全链路追踪 </td> 
 <td style="vertical-align:top;"> Zipkin、Brave、Kubernetes等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务部署 </td> 
 <td style="vertical-align:top;"> Docker、OpenStack、Kubernetes等 </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 数据流操作开发包 </td> 
 <td style="vertical-align:top;"> SpringCloud Stream(封装与Redis、Rabbit、Kafka等发送接收消息) </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 事件消息总线 </td> 
 <td style="vertical-align:top;"> Spring Cloud Bus </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> …… </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 </tbody> 
</table>

### 1.8 eurek和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？ ###

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

Consistency(一致性), 数据一致更新，所有数据变动都是同步的  
Availability(可用性), 好的响应性能  
Partition tolerance(分区容忍性) 可靠性

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那样使整个注册服务瘫痪。

### 1.9…….. ###

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

选型依据

整体解决方案和框架成熟度

社区热度

可维护性

学习曲线

当前各大IT公司用的微服务架构有哪些？

阿里Dobbo/HSF

京东JSF

新浪微博Motan

当当网DubboX

……

各微服务框架对比

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 功能点/服务 框架 </td> 
 <td colspan="5" style="vertical-align:top;"> 备选方案 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Netflix/Spring Cloud </td> 
 <td style="vertical-align:top;"> Motan </td> 
 <td style="vertical-align:top;"> gRPc </td> 
 <td style="vertical-align:top;"> Thrift </td> 
 <td style="vertical-align:top;"> Dubbo/DubboX </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 功能定位 </td> 
 <td style="vertical-align:top;"> 完整的微服务框架 </td> 
 <td style="vertical-align:top;"> RPC框架，但整合了ZK 或Consul，实现集群环境的基本的服务注册/发现 </td> 
 <td style="vertical-align:top;"> RPC框架 </td> 
 <td style="vertical-align:top;"> RPC框架 </td> 
 <td style="vertical-align:top;"> 服务框架 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 支持Rest </td> 
 <td style="vertical-align:top;"> 是&nbsp; &nbsp;Ribbon支持多种可插拔的序列化选择 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 支持RPC </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是（Hession2） </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 支持多语言 </td> 
 <td style="vertical-align:top;"> 是（Rest形式）？ </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务注册/发现 </td> 
 <td style="vertical-align:top;"> 是（Eureka）&nbsp; Eureka服务注册表，Karyon服务端框架支持服务自注册和健康检查 </td> 
 <td style="vertical-align:top;"> 是（Zookeeper/consul） </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 负载均衡 </td> 
 <td style="vertical-align:top;"> 是（服务端zuul+客户端Ribbon） Zuul-服务，动态路由&nbsp;&nbsp; 云端负载均衡Eureka（ 针对中 间层服务器） </td> 
 <td style="vertical-align:top;"> 是（客户端） </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是（客户端） </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 配置服务 </td> 
 <td style="vertical-align:top;"> Netflix Archaius&nbsp;&nbsp; Spring Cloud Config Server集中配置 </td> 
 <td style="vertical-align:top;"> 是（zookeeper提供） </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 服务调用链监控 </td> 
 <td style="vertical-align:top;"> 是（zuul）&nbsp; Zuul提供边缘服务，API网关 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 高可用/容错 </td> 
 <td style="vertical-align:top;"> 是（服务端Hystrix+客户端Ribbon） </td> 
 <td style="vertical-align:top;"> 是（客户端） </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 否 </td> 
 <td style="vertical-align:top;"> 是（客户端） </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 典型应用案例 </td> 
 <td style="vertical-align:top;"> Netflix </td> 
 <td style="vertical-align:top;"> Sina </td> 
 <td style="vertical-align:top;"> Gooogle </td> 
 <td style="vertical-align:top;"> Fackbook </td> 
 <td style="vertical-align:top;"> &nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 社区活跃程度 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 一般 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 一般 </td> 
 <td style="vertical-align:top;"> 2017.8重新启动 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 学习难度 </td> 
 <td style="vertical-align:top;"> 中等 </td> 
 <td style="vertical-align:top;"> 低 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 低 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 文档丰富度 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 <td style="vertical-align:top;"> 一般 </td> 
 <td style="vertical-align:top;"> 一般 </td> 
 <td style="vertical-align:top;"> 一般 </td> 
 <td style="vertical-align:top;"> 高 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 其他 </td> 
 <td style="vertical-align:top;"> Spring Cloud Bus为我们的应用程序带来了更多管理端点 </td> 
 <td style="vertical-align:top;"> 支持降级 </td> 
 <td style="vertical-align:top;"> Netflix内部在开发集成gRPC </td> 
 <td style="vertical-align:top;"> IDL定义 </td> 
 <td style="vertical-align:top;"> 实践的公司比较多 </td> 
 </tr> 
 </tbody> 
</table>

**单机系统All       In     One**

可以看作eclipse工作空间里面只有一个工程

如：Tmall

com.atguigu.service

商品/交易/积分/订单…….

**分布式**

专业的事交给专业的人做，尽量降低耦合度

各个模块/服务，各自独立出来，分灶吃饭

各自微小的一个过程，让专业的人专业的模块，来做专业的事情

独立部署

l  拆分

l  各自独立的进程