微服务架构springCloud

红太狼 2022-05-24 01:34 329阅读 0赞

> 码云地址：[https://gitee.com/lpxs/lp-springcloud.git][https_gitee.com_lpxs_lp-springcloud.git]  
> 有问题可以多沟通：136358344@qq.com。

## 微服务架构 ##

### 一、服务化简介 ###

服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合，并且强调DevOps和快速演化。

*  服务化之Nginx  
    Nginx通过接受客户端Http请求，根据路径配置，转发，跳转相应的服务。

1.  Nginx配置中存在服务调用的逻辑
2.  服务消费者不知道真正服务提供者的实例。
3.  服务不易管理。

*  服务化之Dubbo  
    Dubbo是阿里开源的一个SOA服务治理解决方案。服务消费者和提供者都可将服务信息注册到Register，形成了服务中心的组件。通过Monitor进行很好的服务管理，消费者可以进行负载均衡，服务降级等。

1.  致命的缺点-维护停止（阿里目前又着手维护）
2.  Dubbo严重依赖于第三方组件（Zookeeper／Redis）
3.  由于Dubbo的RPC调用，使得服务提供方与消费方有着代码层次的高强度耦合。

*  服务化之Spring Cloud  
    SpringCloud提出是开发面向云端的Application，为微服务提供了全套的组件技术支撑。值得注意的是：Spring Cloud抛弃了Dubbo的RPC通信，采用了基于Http的Rest方式通信。

下面介绍下重点介绍下springcloud组成

### 二、Spring Cloud ###

Spring Cloud共集成了19个子项目，里面都包含一个或者多个第三方的组件或者框架！

*  Spring Cloud Config 配置中心，利用git集中管理程序的配置。
 *  Spring Cloud Netflix 集成众多Netflix的开源软件
 *  Spring Cloud Bus 消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化
 *  Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的应用程序
 *  Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。
 *  Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul实现的领导选举和平民状态模式的抽象和实现。
 *  Spring Cloud Consul 基于Hashicorp Consul实现的服务发现和配置管理。
 *  Spring Cloud Security 在Zuul代理中为OAuth2 rest客户端和认证头转发提供负载均衡
 *  Spring Cloud Sleuth SpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。
 *  Spring Cloud Data Flow 一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。
 *  Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在Spring Cloud应用中收发消息。
 *  Spring Cloud Stream App Starters 基于Spring Boot为外部系统提供spring的集成
 *  Spring Cloud Task 短生命周期的微服务，为SpringBooot应用简单声明添加功能和非功能特性。
 *  Spring Cloud Task App Starters
 *  Spring Cloud Zookeeper 服务发现和配置管理基于Apache Zookeeper。
 *  Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。
 *  Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
 *  Spring Cloud Starters （项目已经终止并且在Angel.SR2后的版本和其他项目合并）
 *  Spring Cloud CLI 插件用Groovy快速的创建Spring Cloud组件应用。

下面介绍下我们常用的系统架构  
![这里写图片描述][70]

\#\#\#\#服务注册与发现 Eureka  
对于微服务的治理而言，核心就是服务的注册和发现。在Spring Cloud 中提供了多种服务注册与发现组件：Eureka,Consul,Zookeeper。官方推荐使用Eureka  
![这里写图片描述][70 1]

#### Ribbon ####

Ribbon是Netflix发布的开源项目，主要功能是为REST客户端实现负载均衡。

*  怎么实现负载均衡通过注解@LoadBalanced 来实现负载均衡
 *  Ribbon的工作：

1.  第一步有限选择Eureka Server，它优先选择在同一个Zone且负载较少的Server，
2.  第二步在根据用户指定的策略，在从Server取到的服务注册列表中选择一个地址。其中Ribbon提供了多重策略，例如轮询round robin、随机Random、根据相应时间加权等。

#### Feign ####

Spring Cloud为Feign增加了对Spring MVC注解的支持，还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。Feign也用到ribbon，当你使用@ FeignClient，ribbon自动被应用。  
原理：

*  通过@EnableFeignCleints注解开启FeignCleint
 *  根据Feign的规则实现接口，并加@FeignCleint注解,来绑定该接口对应服务
 *  程序启动后，会进行包扫描，扫描所有的@ FeignCleint的注解的类，并将这些信息注入IOC容器中。
 *  当接口的方法被调用，通过jdk的代理，来生成具体的RequesTemplate，RequesTemplate再生成Request
 *  Request交给Client去处理，其中Client可以是HttpUrlConnection、HttpClient
 *  最后Client被封装到LoadBalanceClient类，这个类结合类Ribbon做到了负载均衡。

#### spring cloud config ####

*  每个项目都散落着各种配置文件，如果采用分布式的开发模式，需要的配置文件随着服务增加而不断增多。某一个基础服务信息变更，都会引起一系列的更新和重启。
 *  Spring Cloud Config项目是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client通过接口获取数据、并依据此数据初始化自己的应用。Spring cloud使用git或svn存放配置文件，默认情况下使用git。
 *  真正的数据存在Git等repository中,Config Server去获取相应的信息,然后与Client Application,相互间基于HTTP,TCP,UDP等协议的通信.
 *  当配置更改时，标有@RefreshScope的Spring @Bean将得到特殊处理。这解决了状态bean在初始化时只注入配置的问题。RefreshScope是上下文中的一个bean，它有一个公共方法refreshAll()来清除目标缓存中的范围内的所有bean。还有一个refresh(String)方法可以按名称刷新单个bean。此功能在/refresh端点（通过HTTP或JMX）中公开。

#### 服务网关 Zuul ####

*  将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，那么整个服务只需要暴露一个api，对外屏蔽了服务端的实现细节，也减少了客户端与服务器的网络调用次数。这就是api gateway。
 *  但是如果后端服务多达十几个的时候，每一个都这样配置也挺麻烦的，spring cloud zuul已经帮我们做了默认配置。默认情况下，Zuul会代理所有注册到Eureka Server的微服务，并且Zuul的路由规则如下：http://ZUUL\_HOST:ZUUL\_PORT/微服务在Eureka上的serviceId/\*\*会被转发到serviceId对应的微服务。

#### 服务追踪分析Sleuth ####

Spring Cloud Sleuth为Spring Cloud实现分布式跟踪解决方案。其兼容了Zipkin, HTrace和log-based追踪  
利用Spring Cloud Sleuth来和Zipkin进行集成。Spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等全部自动完成。zipkin的存储方式有多种，默认是保存在内存中，但是其不能持久保存，容器重启等一些其他情况可能导致数据的丢失  
Spring Cloud Sleuth 提供了两种追踪信息收集的方式，一种是通过 http 的方式，一种是通过 异步消息 的方式

*  提供链路追踪。通过sleuth可以很清楚的看出一个请求都经过了哪些服务。可以很方便的理清服务间的调用关系。
 *  可视化错误。对于程序未捕捉的异常，可以在zipkin界面上看到。
 *  分析耗时。通过sleuth可以很方便的看出每个采样请求的耗时，分析出哪些服务调用比较耗时。当服务调用的耗时随着请求量的增大而增大时，也可以对服务的扩容提供一定的提醒作用。
 *  优化链路。对于频繁地调用一个服务，或者并行地调用等，可以针对业务做一些优化措施。

#### 断路器Hystrix ####

*  Netflix创建了一个名为Hystrix的库,实现了断路器的模式。“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
 *  除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面

[https_gitee.com_lpxs_lp-springcloud.git]: https://gitee.com/lpxs/lp-springcloud.git
[70]: /images/20220524/52b0dce950884ceabf5c1932743574ad.png
[70 1]: /images/20220524/3b1fb4dca767465ba5c78f8038d3d9e5.png