SpringCloud微服务架构
- 微服务架构介绍
- 1.SpringCloud微服务架构图
- 2.网关服务(Zuul)
- 3.注册中心(Eureka)
- 注册中心(Eureka)介绍
- 关系调用说明
- 4.负载均衡(Ribbon)
- 客户端负载均衡
- 5.熔断(Hystrix)
- 什么是熔断
- Hystrix是什么
- Hystrix主要解决那些问题
- 6.聚合服务(Service)
- 7.原子服务(Atom)
- [项目框架源码](javascript:void(0))
微服务架构介绍
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
1.SpringCloud微服务架构图
2.网关服务(Zuul)
不同的微服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。比如一个电影购票的收集APP,可能回调用电影分类微服务，用户微服务，支付微服务等。如果客户端直接和微服务进行通信，会存在以下问题：
1.客户端会多次请求不同微服务，增加客户端的复杂性
2.存在跨域请求，在一定场景下处理相对复杂
3.认证复杂，每一个服务都需要独立认证
4.难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接和微服务通信，那么重构会难以实施
5.某些微服务可能使用了其他协议，直接访问有一定困难
上述问题:都可以借助微服务网管解决。微服务网管是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关
Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：
6.身份认证和安全: 识别每一个资源的验证要求，并拒绝那些非法的请求
7.审查与监控
8.动态路由：动态将请求路由到不同后端集群
9.压力测试：逐渐增加指向集群的流量，以了解性能
10.负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
11.静态响应处理：边缘位置进行响应，避免转发到内部集群
12.多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB(ElasticLoad Balancing)使用多样化
Spring Cloud对Zuul进行了整合和增强。目前，Zuul使用的默认是Apache的HTTP Client，也可以使用Rest Client，可以设置ribbon.restclient.enabled=true.
3.注册中心(Eureka)
注册中心(Eureka)介绍
Eureka是Spring Cloud Netflix微服务套件中的一部分，可以与Springboot构建的微服务很容易的整合起来。
Eureka包含了服务器端和客户端组件。服务器端，也被称作是服务注册中心，用于提供服务的注册与发现。Eureka支持高可用的配置，当集群中有分片出现故障时，Eureka就会转入自动保护模式，它允许分片故障期间继续提供服务的发现和注册，当故障分片恢复正常时，集群中其他分片会把他们的状态再次同步回来。
客户端组件包含服务消费者与服务生产者。在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性的发送心跳来更新它的服务租约。同时也可以从服务端查询当前注册的服务信息并把他们缓存到本地并周期性的刷新服务状态。
注册中心 如下图：
关系调用说明
服务生产者启动时，向服务注册中心注册自己提供的服务
服务消费者启动时，在服务注册中心订阅自己所需要的服务
注册中心返回服务提供者的地址信息给消费者
消费者从提供者中调用服务
注册中心示例 如下图：
4.负载均衡(Ribbon)
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，而已让我们将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。它只是一个工具类框架，无需独立部署，但几乎存在于每一个Spring Cloud构建的微服务和基础设施中。微服务建的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括之后的Feign。
客户端负载均衡
客户端负载均衡和服务端负载均衡最大的不同点在于服务清单所存储的位置。客户端负载均衡中，所有尅兑换节点都要维护自己要访问的服务端清单，这些服务端的清单来自于服务注册中心，比如Eureka服务端。客户端负载均衡中心也需要心跳去维护服务端清单的健康，这个步骤需要与服务注册中心配合完成。在Spring Cloud实现的服务治理框架中，默认会创建针对各个服务治理框架的Ribbon自动化整合配置，比如Eureka中的org.springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfiguration，Consul中的org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration。在实际使用的时候，我们通过查看这两个类的实现，已找到它们的配置详情来帮助我们更好地使用它。
通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用：
服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate聊实现面向服务的接口调用。
这样就可以将服务提供者的高可用以及服务消费者的负载均衡调用一起实现了。
5.熔断(Hystrix)
什么是熔断
做过分布式的同学应该都知道这个概念，在这里还是要解释下熔断，因为对于有些同学，根本就没听过这个。熔断就是切断项目对指定服务的调用。举个例子在分布式环境下有A,B,C,D四个个服务，A依赖B,C,D。在调用的过程中发现D服务异常了，为了不拖垮整个集群，我们会选择不调用D服务，进行服务降级。
Hystrix是什么
上面说了什么是熔断，可是什么时候该启用熔断，什么时候去探测服务是否可用，当依赖异常恢复时，什么时候上层恢复依赖等这些技术细节都是我们要去考虑的。而Hystrix就是为了解决这些问题而诞生的。
在分布式环境下hystrix通过添加延迟容错和失败容差逻辑来帮助我们处理服务之间的交互。它会隔绝各服务间的调用，防止出现雪崩现象并提供fallback失败备用方案，以此提高我们服务集群的弹性。
Hystrix主要解决那些问题
对外依赖包括第三方类库的依赖提供延迟和失败保护
阻断传递失败，防止雪崩
快速失败并即时恢复
合理的fallback和优雅降级
提供近实时的监控、告警和操作控制
6.聚合服务(Service)
service是业务层，是使用一个或多个模型执行操作的方法。
- 封装通用的业务逻辑，操作。
如一些数据的检验，可以通用处理。 - 调用其他服务。
- 其他请求：如远程服务获取数据，如第三方api等。
7.原子服务(Atom)
原子服务完成的是一个个原子性操作，不涉及业务逻辑，我个人通常将其归入持久化层，负责数据的存储与获取
