微服务架构springcloud

时间  2019-11-12 标签 微服 架构 springcloud

码云地址：https://gitee.com/lpxs/lp-springcloud.git 有问题能够多沟通：136358344@qq.com。git

微服务架构

1、服务化简介

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

  • 服务化之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组成数据库

2、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组件应用。

下面介绍下咱们经常使用的系统架构 这里写图片描述api

服务注册与发现 Eureka

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

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的整合，对监控内容转化成可视化界面
联系我们 沪ICP备13005482号-10