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(可用性)方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,虽然多少会影响一些用户体验,但也不至于造成用户购物流程的严重阻塞。