SpringColud微服务架构知识整理

SpringColud微服务架构

分布式架构

根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。比如一个商城项目有4个功能模块，可以按照功能拆分成4个独立的项目，每个项目单独开发、部署、打包、上线。这样一来，打包的效率提高了，而且每个模块单独开发，互相不受影响。

优缺点

优点

• - 模块之间耦合度低，容错率提高，不会因为某个模块崩溃导致整个服务器崩溃。- 系统拆分实现了流量分担，提高了系统的并发量。- 方便扩展，比如商品功能访问量很大，可以在增加一台商品功能的服务器。- 系统间相互独⽴，互不影响，新的业务迭代时更加⾼效。- 有利于服务升级扩展，比如支付功能升级版本，使用新的技术，其他模块不受影响。

缺点

• - 分布式架构做了服务的拆分，拆分的越多，部署越复杂。- 服务调用关系错综复杂，之前的单体架构，所有功能在一个项目中，可以直接调用。拆分后，独立部署，调用时需要使用远程调用。

微服务

微服务是一种经过良好架构设计的分布式架构方案

微服务的架构特征

单一职责

• 微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责

自治

• 团队独立、技术独立、数据独立，独立部署和交付

面向服务

• 服务提供统一标准的接口，与语言和技术无关

隔离性强

• 服务调用做好微服务容错隔离，使用降级保护，避免出现级联问题

容错隔离

• 当系统在运行时有错误被激活的情况下将错误隔离，仍能保证不间断提供服务的方法和技术。
降级保护
• 通过服务降级可以保证核心业务的顺利进行，比如当程序发现异常时，为了控制异常的影响范围而触发的自动服务降级，返回一个默认值。

SpringCloud是目前国内使用最广泛的微服务框架

集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。

服务拆分和远程调用

任何分布式架构都离不开服务的拆分，微服务也是一样
服务拆分原则

• 不同微服务，不要重复开发相同业务- 微服务数据独立，不要访问其它微服务的数据库- 微服务可以将自己的业务暴露为接口，供其它微服务调用

组件

Eureka注册中心

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址 Eureka 的默认端口为8761

• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
• 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
  负载均衡Ribbon
  

Hystrix熔断器

Hystrix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

Hystrix解决雪崩问题的手段

• - 服务降级
• - 服务熔断

开启熔断

• 在启动类上添加@EnableCircuitBreaker注解
• 在微服务中经常会引入上面三个注解，于是SpringCloud给我们提供了一个组合注解

• @SpringCloudApplication
他里面包含了四个注解@SpringBootConfiguration
@EnableAutoConfiguration 自动化配置类
@ComponentScan 扫描包
@Configuration 配置类

hystrix的状态机有3个状态

1. Closed：关闭状态（断路器关闭），所有请求都正常访问

2. Open：打开状态（断路器打开），所有请求都会被降级，Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断器，断路器会完全关闭，默认失败比例的阈值是50%，请求次数最少不低于20次

3. HalfOpen:半开状态，Open状态不是永久的，开启后会进入休眠时间（默认是5S）。随后熔断器会自动进入半开状态，此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持开启，再次进入休眠计时。

Feign进行远程调用

1. Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。
2. 默认使用的是 URLConnection底层实现微服务的互相调用. 调用一次进行链接, 效率低一些.
3. 改变Feign默认链接方式, 采用 apache下的 HttpClient技术, 用连接池的技术, 解决访问效率低的问题.

Zuul网关

Zuul加入后的架构不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。

• 在使用Zuul的过程中，当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：
• 默认情况下，一切服务的映射路径就是服务名本身。
• 例如服务名为：service-provider，则默认的映射路径就是：/service-provider/**
zuul的高可用
• 启动多个zuul服务，自动注册Eureka，形成集群如果是服务内部访问，你访问zuul，自动负载均衡，没问题，但是zuul更多的是外部访问，PC端，移动端等，他们无法通过Eureka进行负载均衡，那么该怎么办
• 此时我们会使用其他的服务网关，来对zuul进行代理，比如：nginxEureka，Ribbon，Hystrix，Feign，Zuul
• Spring-Cloud config：统一配置中心，自动去Git拉取最新配置，缓存，使用git的Webhook钩子，去通知配置中心，说配置发生了变化，配置中心会通过消息总线去通知所有的微服务，更新配置。

PS:

1. dubbo和springCloud的区别
   
2. 微服务项目的设计流程