【摘要】 SpringCloud与微服务
程序架构发展史
ORM（All in One) 可承载并发量1~10MVC (Vertical Application) 可承载并发量 10~1000RPC (Distributed Service) 可承载并发量 1000~10000SOA (Elastic Computing) 10000+
Spring Cloud
Spri…

SpringCloud与微服务

程序架构发展史

• ORM（All in One) 可承载并发量1~10
• MVC (Vertical Application) 可承载并发量 10~1000
• RPC (Distributed Service) 可承载并发量 1000~10000
• SOA (Elastic Computing) 10000+

Spring Cloud

• Spring Cloud是一系列框架的有序集合。是一种生态。、
• spring Cloud基于Springboot 提供了一整套的微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

微服务架构

• 由Martin Fowker提出，是一种架构形式。

• 微服务只是业务逻辑的代码，不会和Html，CSS或其他界面组合。

• 微服务是弱耦合的每个服务都能独立部署

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

• 服务很多，客户端该怎么访问？
• 这么多服务，服务之间如何通信？
• 这么多服务，如何治理？
• 服务挂了怎么办？

解决方案

（一）Spring Cloud NetFlix 一站式的解决方案，使用api网关，zuul组件

• http通信方式，同步阻塞式的
• 服务注册与发现：Eureka
• 熔断机制：Hystrix

（二）Apache Dubbo Zookeeper

• 半自动的，需要整合
• API无，找第三方组件或自己实现
• 没有熔断机制
• Dubbo方案不完善

Eureka服务注册与发现

• 解决服务之间如何通信

• NetFlix在设计Eureka时，遵循的就是AP原则

CAP原则

• C：Consistency强一致性
• A ：Availability 可用性
• P ：Partion tolerance 分离容错性

分布式系统不可能同时满足CAP原则

Zookeeper保证的时CP，Eureka保证的时AP

• Eureka时NetFlix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务注册与发现，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件，功能类似zookeeper
• Eureka采用C-S架构，EurekaServer作为服务注册功能的服务端，是注册中心

三大角色

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

• Service Provider 将自身服务注册到Eureka中，从而方便消费者能够找到

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

• 可以有多个Eureka组件，用以服务注册与发现。

• 多个相同Service Provider来共服务。注意要在注册中心的名称相同，用以表示提供相同的服务。

Ribbon负载均衡

• 解决了服务治理问题

• LB（Load Balance）负载均衡：即将用户的请求平摊的分配到多个服务上，从而达到系统的高可用

  分类

  集中式LB ：如Nginx（反向代理服务器）

  进程式：如Ribbon

Spring Cloud Ribbon 是基于 NetFlix Ribbon实现的一套客户端负载均衡工具。

• Ribbon 和 Eureka整合后，不用关心IP地址和端口号，只需要知道在注册中心的Application名称即可。

实现算法

• Ribbon 默认的实现算法是轮询
• randomRule随机算法，
• availabilityFilteringRule ：会过滤掉跳闸的，访问故障的服务，对剩下的进行轮询。
• retryRule： 会选按照轮询获取服务，如果服务获取失败，则会在指定的时间内重试
• 也可以自定义负载均衡算法，如加权算法等

Hystrix服务熔断

• 解决服务挂了的问题
• Hystrix，能保证在一个以来出问题的情况下不会导致整体的服务失败，避免联级故障，以提高分布式系统的弹性。
• 作用：服务降级，服务熔断，服务限流，接近实时的监控。
• 服务熔断：熔断机制是对应雪崩效应的一种微服务链路保护机制，5秒内20次调用失败就会启动熔断机制。服务端某个服务超时或者异常就会引起熔断
• 服务降级：客户端，从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个FallbackFactory，会返回一个默认值（缺省值），整体服务水平下降。

Zuul路由网关

• 解决客户端该怎么访问

• zuul包含了对请求的路由和过滤两个最主要的功能，是实现外部访问同一入口的基础。

• zuu最终还是会注册进eureka

• 提供：代理+路由+过滤三大功能

SpringCloud与Dubbo的区别

• SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HttpRest的方式

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

• 解决的问题不一样：Dubbo的定位是一款RPC框架，而SpringCloud的目标是微服务框架下的一站式解决方案。

文章来源: blog.csdn.net，作者：没蜡笔的小鑫++，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/weixin_46604741/article/details/116033731