7.3 作业

最新推荐文章于 2024-09-06 19:15:00 发布

废柴柴柴

最新推荐文章于 2024-09-06 19:15:00 发布

阅读量138

点赞数

文章标签：大数据

本文链接：https://blog.csdn.net/m0_46147887/article/details/125586605

版权

1、Spring Cloud常用组件的都有哪几类？如何选型(对比优缺点)？

Spring colud的优点:

1.集大成者，Spring Cloud 包含了微服务架构的方方面面。

2.约定优于配置，基于注解，没有配置文件。

3.轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。

4.开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。

5.开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。

服务发现——Netflix Eureka

作用：实现服务治理（服务注册与发现）
简介 :Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块.
由两个组件组成：Eureka服务端和Eureka客户端.
Eureka服务端用作服务注册中心.支持集群部署.
Eureka客户端是一个java客户端，用来处理服务注册与发现.
在应用启动时,Eureka客户端向服务端注册自己的服务信息,同时将服务端的服务信息缓存到本地.客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息.
客服端负载均衡——Netflix Ribbon

作用：Ribbon,主要提供客户侧的软件负载均衡算法.
简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用.
注意看上图,关键点就是将外界的rest调用,根据负载均衡策略转换为微服务调用.Ribbon有比较多的负载均衡策略,以后专门讲解.
断路器——Netflix Hystrix

作用: 断路器，保护系统，控制故障范围.
简介: 为了保证其高可用,单个服务通常会集群部署.由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题，调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪.服务与服务之间的依赖性,故障会传播，会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩”效应.
服务网关——Netflix Zuul

作用：api网关,路由,负载均衡等多种作用
简介：类似nginx,反向代理的功能,不过netflix自己增加了一些配合其他组件的特性.
在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务.当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙,这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端.
分布式配置——Spring Cloud Config

作用: 配置管理
简介: SpringCloud Config提供服务器端和客户端.服务器存储后端的默认实现使用git,因此它轻松支持标签版本的配置环境,以及可以访问用于管理内容的各种工具.
这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新.

2. 什么是CAP定理？

CAP定理：CAP定理又称CAP原则。指在一个分布式系统中一致性（consistency）、可用性（availability）、分区容错性（partition tolerance）三个特性最多只能同时支持两个。

一致性（consistency）：在更新操作成功并且返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说一致性指的是并发访问时更新过的数据如何获取，服务端则是更新如何复制分布到整个系统，以保证数据最重一致。

可用性（availability）：“Reads and Writes always succeed”，即服务一直可用，而且时正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现操作失败或者访问超时等用户体验。

分区容错性（partition tolerance）：即分布式系统在遇到某个节点或者网络分区故障的时候，仍然能够对外提供满足一致性或者可用性的服务。

CAP定理的简单证明：

假设存在上图分布式系统，系统内有两个服务器，在正常情况下如果从应用A请求数据更新到服务器后，数据库由DB1更新成DB2，此时通过分布式系统的数据同步更新操作后，B中的数据库也更新为了DB2。这时候通过B向数据库发起请求得到的数据就是即时更新的DB2。

假设A和B之间通信产生网路故障，此时有用户向A发送数据更新的请求，那A中的数据库将会更新成DB2，但是由于A和B之间的通信是断开的，那B中的数据库仍然是DB1。这个时候用户从B发送数据读取的的请求，由于B的数据还没有更新同步，这时候有两种选择：第一，牺牲一致性，响应旧的数据DB1；第二，牺牲可用性，阻塞等待直到通信恢复，数据更新同步以后再给用户响应最新的BD2。

取舍策略：

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。

CP without A：如果不要求A（可用性），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如电商的抢购场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。