一、系统架构的演变
单机版
把我们的所有的模块都放置一个项目上，最后将项目打包成war包或者jar包部署到你的服务器上；
- 优点：1、方便开发；2、部署简单
- 缺点：1、代码耦合，开发维护困哪；2、并发性差、容错率高；3、无法针对对不同的模块进行优化
分布式
不同的业务在不同的模块上，然后发布在不同的服务器上，物理上的分离，逻辑上的集中
- 优点：1、降低了代码的耦合度；2、相比提高了项目的并发、容错率；3、(相比微服务关系错综复杂)
- 缺点：1、比较难开发；2、部署较难
SOA：面向服务
微服务：SpringCloud Dubbo 两套解决方案
二、微服务
是什么？
- 将传统的一站式的引用，根据业务的不同 拆分成一个一个的服务，去降低耦合度；
- 每一个微服务提供单个业务功能的服务，一个服务做一件事。
- 从技术的角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁。
- 可以拥有独立的数据库；
根据业务的不同：拆分成怎么样，仁者见仁智者见智了；微服务是一种架构风格；
特点
- 单一职责；微；
- 面向服务：每个服务都要对象暴露Rest风格服务接口API,不在乎里面的实现技术
- 自治：团队独立、技术独立、前后端分离、数据库分离、部署独立。
三、Dubbo与SpringCloud的区别？
本质区别
- dubbo是基于RPC(远程过程调用)
- SringCloud是基础Http协议(超文本传输协议)
RPC和Http的区别
- RPC：基于原生的TCP协议，工作于会话层，传输效率高；自定义数据格式；限定统一技术
- HTTP：传输协议，也是基于TCP，工作于应用层，传输效率较低；统一的数据格式；不限制技术，只需要提供rest风格接口；消息封装臃肿
- 如果你的公司是使用java技术栈，可以使用Dubbo
- 但是如果使用技术栈的多样化或者青睐于Spring，使用SpringCloud
四、Spring、Spring FrameWork、SpringBoot和SpringCloud是什么？
Spring
Spring是一个生态体系(技术体系)，是集大成者，包括了SpringFrame，SpringBoot、SpringCloud、Spring Data、SpringSecurity 等等
Spring Frame
是整个Spring的基石，是一个一站式的轻量级的Java开发框架，核心是控制反转(IOC)和面向切面(AOP),针对开发WEB层的SpringMVC，业务层的AOP，持久层的JDBCTemplate等配置解决方案。
SpringBoot
SpringBoot是一个快速整合第三方框架的框架；有着简化配置、自动配置、独立运行和应用监控等优点
SpringCloud
SpringCloud则是微服务架构的一套解决方案；关注的是宏观，将SpringBoot开发的一个个单体的服务整合并管理起来，它为各个服务提供了注册中心进行服务发现，配置管理，负载均衡，断电器路由，微代理
由很多组件组成：
Eureka：注册中心；服务的注册与发现；
Zuul：网关组件；路由的请求分发、过滤器(Ribbon. hystrix)
Ribbon：负载均衡组件
Hystrix：熔断组件
Fegin：远程调用组件
五、Eureka(注册中心)
服务注册中心(可以是一个集群)，对外暴露自己的地址
- 提供方：使用eureka的客户端，启动向eureka注册自己的信息(地址、提供什么服务)
- 消费者：向eureka订阅服务，Eureka会将对应的服务提供者的地址列表发送给消费者，并且定期拉取服务进行更新
- 心跳(续约)：提供方会定期的通过http方式向eureka刷新自己的状态
- 使用application.name即可访问服务器，其中还可做负载均衡、熔断；
使用步骤
- 注册中心：item-eureka
1、引入启动器；
2、配置spring.application.name = item-eureka
eureka.client.service-url.defaultZone=http://localhost:10086/eureka
// 当是eureka集群时，两两相互注册即可； 关闭自我保护，定期清 除无效链接
eureka.server: eviction-interval-timer-in-ms: 5000
enable-self-preservation: false]
3、启动类添加注解 @EnableEurekaServer
- 客户端：itcast-service-provider itcast-service-consumer
- 1、引入启动类
- 2、覆盖默认配置 spring.application.name 注册到eureka
eureka.client.service-url.defaultZone=http://localhost:10086/eureka
在服务提供方中，设置心跳时间
eureka：
instance:
lease-renewal-interval-in-seconds: 5 # 心跳时间
lease-expiration-duration-in-seconds: 15 # 过期时间
在服务消费者，设置拉取服务间隔时间
eureka. client:
registry-fetch-interval-seconds: 5- 3、启动类添加注解@EnableDiscoveryClient
六、Ribbon(负载均衡)
- 1、eureka已经集成了
- 2、无需覆盖默认配置
- 3、在RestTemplate 这个组件上添加注解 @LoadBalanced
使用的负载均衡策略
- 1、默认使用的是：轮循
- 2、可以使用 随机
service-provider.ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
七、Hystrix(熔断)
Hystrix是一个处理分布式系统的 延迟和容错开源库；在分布式系统里，许多依赖不可避免的会调用失败，你如超时、异常等，hystrix组件能够保证一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性
对比
- 之前：请求阻塞，一直阻塞会导致其他的服务器等不到响应，可能会级联故障，导致整个系统雪崩；
- 现在：用户的请求将不用直接访问服务，而是通过线程池中空闲的线程来访问服务，如果线程池已满，或者请求超时，则会进行服务降级；(比如向调用方返回一个响应；向调用方返回一个符合预期的、可处理的备选响应[FallBack]，而不是长时间的等待或者抛出调用方无法处理的异常)
服务降级:优先保护核心服务，而非核心服务不可用或弱可用
触发服务降级的条件
- 线程池已满；
- 请求超时
服务熔断：(断路器) 有三个状态
- Close：关闭状态，所有的请求都能正常的访问
- Open：打开状态，所有的请求都会被降级。Hystrix会对请求情况进行计数，当一定时间内请求次数达到20次以上并且失败次数的阈值达到了50%，则触发熔断，断路器会被打开；所有的请求都不能正常的访问；
- Half-Open：半打开状态；Open的状态不是永远的，当休眠5秒后会自动进去半打开状态；会释放部分请求通过，如果这些请求是成功的，那么就是完全关闭断路器；如果不成功，那么继续进行休眠5秒，重复流程；
八、Feign(远程调用)
Feign(伪装)：可以把Rest请求进行隐藏，伪装成SpringMVC的Controller一样，你不用在自己拼url和参数等，一切交给feign就可以
Feign也集成了Ribbon负载均衡(默认配置)和Hystix服务熔断(需要配置)；
使用流程
- 1、引入openFeign启动器
- 2、配置 feign.hystrix.enable = true ,开启我们的hystrix断路器；
- 3、配置启动类，@EnableFeignClients
- 4、创建一个接口，添加注解@FeignClient(value,class=断路器的class)
- 5、在接口中定义一些方法，这些方法的书写跟SpringMVC的controller类似，使用的都是SpringMVC的注解
- 6、创建一个熔断类，实现feign接口，实现对应的方法，才能实现Feign进行熔断
九、Zuul(服务网关)
不论是来自客户端(PC端或移动端)的请求，还是服务内部调用，一切对服务的请求都必须经过Zuul服务网关组件，然后再由网关来实现动态路由、授权等等操作；Zuul就是我们服务的统一入门
Zuul 如果需要负载均衡 可以用nginx进行做负载均衡和反向代理
使用流程(路由)
- 1、引入Zuul启动器
- 2、配置有4种方式
- 1、zuul.routes.<路由名称>.path=/service-provider/**
zuul.routes.<路由名称>.url=http://localhost:8082- 2、zuul.routes.<路由名称>.path=/service-provider/**
zuul.routes.<路由名称>.serviceId=service-provider- 3、zuul.routes.服务名 /随意item/**
- 4、不用配置，默认是服务id为开头，如provider就是 /provider/**
- 在启动类(引导类)@EnableZuulProxy
过滤器
创建一个类继承ZuulFilter父类(基类)
重写其四个方法
- 1、FilterType : Pre Route Post Error
- 2、FilterOrder：返回值越小执行的优先级越高
- 3、shouldFilter：是否执行run方法，true为执行
- 4、run 具体的拦截逻辑
Nginx
- 可做服务器也可做网关
- 反向代理；负载均衡；动态路由；请求过滤
十、分布式微服务架构
十一、Eureka 和 Zookeeper 两个区别
CAP是什么？
- C：强一致性
- A：可用性
- P：分区容错性
分布式理论CAP
一个分布性系统不可能同时满足CAP；由于分区容错性P是分布式中必须要保证的；所以我们只能在A和C中进行权衡。
Zookeeper遵循CP
当一台Zookeeper挂了，那其他的Zookeeper会进行一次选取(要求强一致性；我一定要保证数据的一致性)；但是在选举的过程中Zookeeper是不可用的，而当前的体验不是很好；
Eureka遵循AP
- Eureka各个节点是平等的，几个节点挂掉并不会影响正常节点的工作，剩下的节点还能提供注册和查询的服务。
- 而Eureka的客户端在某个Eureka注册时发现失败，则会自动切换到其他的节点；只要有一台Eureka在，就能保证注册服务可用(保证可用性)；只不过查询到的信息可能不是最新(不能保证一致性)
- 除此之后，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳；(就是所有的eureka的都没有心跳)，那么eureka会认定注册中心出现了网络故障。会出现以下情况：
- 1、Eureka不再从注册列表中移除因为长时间没收到心跳而过期的服务；
- 2、Eureka能够接受新服务的注册和查询请求，但是不会被同步到其他节点(即保证当前节点的可用性)；
- 3、当网络稳定时，当前节点新的注册信息会被同步到其他节点中。
扫一扫
1375
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
