系统微服务架构

系统微服务架构

 

一、系统微服务架构

2、什么是微服务（Microservice）

 

　微服务英文名称Microservice，Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务能够独立地编译及部署，并经过各自暴露的API接口相互通信。它们彼此相互协做，做为一个总体为用户提供功能，却能够独立地进行扩充。

 

微服务架构须要的功能或使用场景

 1：咱们把整个系统根据业务拆分红几个子系统。

 2：每一个子系统能够部署多个应用，多个应用之间使用负载均衡。

 3：须要一个服务注册中心，全部的服务都在注册中心注册，负载均衡也是经过在注册中心注册的服务来使用必定策略来实现。

 4：全部的客户端都经过同一个网关地址访问后台的服务，经过路由配置，网关来判断一个URL请求由哪一个服务处理。请求转发到服务上的时候也使用负载均衡。

 5：服务之间有时候也须要相互访问。例若有一个用户模块，其余服务在处理一些业务的时候，要获取用户服务的用户数据。

 6：须要一个断路器，及时处理服务调用时的超时和错误，防止因为其中一个服务的问题而致使总体系统的瘫痪。

 7：还须要一个监控功能，监控每一个服务调用花费的时间等。

  

目前主流的微服务框架：Dubbo、 SpringCloud、thrift、Hessian等。

  

3、SpringCloud项目简介

 

　SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，

跟spring boot框架一块儿使用的话，会让你开发微服务架构的云服务很是好的方便。

  

  SpringBoot旨在简化建立产品级的 Spring 应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能

  

相关组件架构图

  

 

1.Eureka简介

 

   Eureka是Spring Cloud Netflix的一个子模块，也是核心模块之一。用于云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

服务注册与发现对于微服务系统来讲很是重要。有了服务发现与注册，你就不须要成天改服务调用的配置文件了，你只须要使用服务的标识符，就能够访问到服务。

   服务发现：服务发现是微服务基础架构的关键原则之一。试图着手配置每一个客户端或某种格式的约定能够说是很是困难的和很是脆弱的。Eureka是Netflix服务发现的一种服务和客户端。这种服务是能够被高可用性配置的和部署,而且在注册的服务当中，每一个服务的状态能够互相复制给彼此。

   服务注册:当一个客户端注册到Eureka,它提供关于本身的元数据（诸如主机和端口，健康指标URL，首页等）Eureka经过一个服务从各个实例接收心跳信息。若是心跳接收失败超过配置的时间，实例将会正常从注册里面移除

 下图是基本的服务注册和发现

 

对于应用，配制文件一般是放在项目中管理的，它可能有各类各样的配置文件和属性文件，另外还可能有开发环境、测试环境、生产环境等，这样的话就得一式三份，如果传统应用还好说，若是是微服务呢，这样不光配置文件有可能冗余并且量大，繁重复杂，很差维护，这样的话就须要一个配置文件的统一管理了。

 

2.SpringCloud Config简介

SpringCloud Config为分布式系统外部化配置提供了服务器端和客户端的支持，它包括ConfigServer和ConfigClient两部分。

 

　　　　

　　Server:

实例通常多于两个，以实现HA；

配置以文件形式存储，快速支持目前以SpringBoot的开发方式的配置文件；

支持GIt，码云，SVN，本地文件等多种形式；

支持属性加密；

　　Client：即各自的微服务应用；

 

3.微服务网关ZUUL

 

因为微服务过多，可能某一个小业务就须要调各类微服务的接口，不可避免的就会须要负载均衡和反向代理了，以确保ui不直接与全部的微服务接口接触，因此咱们须要使用一个组件来作分发，跨域等各类请求。

　　ZUUL是Netflix开源的微服务网关，它能够和Eureka、Ribbon、Hystrix等组件配合使用，它主要用做反向代理、Filter扩展、动态加载、动态路由、压力测试、弹性扩展、审查监控、安全检查等。
　　

 

经过网关的方式，提供致对外的服务，具体的服务调用分发由网关根据注册中心进行分发。

 

4.熔断器Hystrix

 

在微服务架构中一般会有多个服务层调用，基础服务的故障可能会致使级联故障，进而形成整个系统不可用的状况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用致使“服务消费者”的不可用,并将不可用逐渐放大的过程。

若是下图所示：A做为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引发了B的不可用，并将不可用像滚雪球同样放大到C和D时，雪崩效应就造成了。

熔断器（CircuitBreaker）

熔断器的原理很简单，如同电力过载保护器。它能够实现快速失败，若是它在一段时间内侦测到许多相似的错误，会强迫其之后的多个调用快速失败，再也不访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操做，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可使应用程序可以诊断错误是否已经修正，若是已经修正，应用程序会再次尝试调用操做。

熔断器模式就像是那些容易致使错误的操做的一种代理。这种代理可以记录最近调用发生错误的次数，而后决定使用容许操做继续，或者当即返回错误。 熔断器开关相互转换的逻辑以下图：

熔断器就是保护服务高可用的最后一道防线。

 

 

5.熔断器监控Hystrix-dashboard

是一款针对Hystrix进行实时监控的工具，经过Hystrix Dashboard咱们能够在直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。可是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 咱们须要一个工具能让咱们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine.在复杂的分布式系统中，相同服务的节点常常须要部署上百甚至上千个，不少时候，运维人员但愿可以把相同服务的节点状态以一个总体集群的形式展示出来，这样能够更好的把握整个系统的状态。 为此，Netflix提供了一个开源项目（Turbine）来提供把多个hystrix.stream的内容聚合为一个数据源供Dashboard展现

 

 

6.Spring Cloud Sleuth服务跟踪系统

 

通常的，一个分布式服务跟踪系统，主要有三部分：数据收集、数据存储和数据展现。根据系统大小不一样，每一部分的结构又有必定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（troubleshooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（须要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展现又涉及到数据挖掘和分析。虽然每一部分均可能变得很复杂，但基本原理都相似。

服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程，称为一个“trace”。每一个 trace 中会调用若干个服务，为了记录调用了哪些服务，以及每次调用的消耗时间等信息，在每次调用服务时，埋入一个调用记录，称为一个“span”。这样，若干个有序的 span 就组成了一个 trace。在系统向外界提供服务的过程当中，会不断地有请求和响应发生，也就会不断生成 trace，把这些带有span 的 trace 记录下来，就能够描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间，以及请求成功与否等信息，就能够在发生问题的时候，找到异常的服务；根据历史数据，还能够从系统总体层面分析出哪里性能差，定位性能优化的目标。

Spring Cloud Sleuth为服务之间调用提供链路追踪。经过Sleuth能够很清楚的了解到一个服务请求通过了哪些服务，每一个服务处理花费了多长。从而让咱们能够很方便的理清各微服务间的调用关系。此外Sleuth能够帮助咱们：

•耗时分析: 经过Sleuth能够很方便的了解到每一个采样请求的耗时，从而分析出哪些服务调用比较耗时;

•可视化错误: 对于程序未捕捉的异常，能够经过集成Zipkin服务界面上看到;

•链路优化: 对于调用比较频繁的服务，能够针对这些服务实施一些优化措施。

spring cloud sleuth能够结合zipkin，将信息发送到zipkin，利用zipkin的存储来存储信息，利用zipkin ui来展现数据。

这是Spring Cloud Sleuth的概念图：

ZipKin

Zipkin 是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展示。

每一个服务向zipkin报告计时数据，zipkin会根据调用关系经过Zipkin UI生成依赖关系图，显示了多少跟踪请求经过每一个服务，该系统让开发者可经过一个 Web 前端轻松的收集和分析数据，例如用户每次请求服务的处理时间等，可方便的监测系统中存在的瓶颈。