SpringCloud分布式架构前期逻辑知识

Springcloud分布式架构

单体架构，小企业经常用到，典型代表就是一个应用、一个数据库、一个web容器就可以跑起来。选择单体架构：保证上线速度，这种方案简单灵活；二是传统企业垂直度较高，访问压力下的业务，这种模式对技术要求比较低，方便各层次开发人员接收，也满足客户要求。

垂直架构：在单体架构一段时间后，公司的业务模式得到了认可，交易量也越来越大，企业为了应对更大的流量，就会对原有的业务进行拆分：后台系统、前端系统、交易系统等。在这一阶段往往会将系统分为不同的层级，每个层级有对应的职责，UI层负责和用户进行交互、交互逻辑层负责具体业务功能，数据库层负责和上层进行数据交换和存储。

服务化架构：公司垂直子系统会变得越来越多，系统和系统之间的调用关系呈指数上升趋势。在这样的背景下，SOAP面项目服务的架构

SOAP服务化优点：根据需求通过网络对松耦合的组粒度应用组件进行分布式部署/组合和使用。服务层时SOAP的基础。可以直接被应用调用，从而控制系统中与软件代理交互的人为依赖性。

服务化架构是一套松耦合的架构，复去的拆分原则是服务内部高聚合，服务之间松耦合。

 

在这个阶段会使用webService和dubbo进行服务治理。

SOA和微服务架构区别和联系：

          区别：1/微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务。2/微服务不再强调传统SOA架构里面比较重的ESB企业服务总线。3/为服务强调每个微服务有自己的独立运行空间，包括数据库资源。4/微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调采用了HTTP Rest API的方式进行。5/微服务的切分力度更小。

为什么考虑Spring Cloud 
 

• Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证
• Spirng Cloud天然支持Spring Boot，更加便于业务落地。
• Spring Cloud发展非常的快，从16年开始接触的时候相关组件版本为1.x，到现在将要发布2.x系列
• Spring Cloud是Java领域最适合做微服务的框架。
• 相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
• 对于中小企业来讲，使用门槛较低。

它的特性 

以下为Spring Cloud的核心特性： 
 

• 分布式/版本化配置
• 服务注册和发现
• 路由
• 服务和服务之间的调用
• 负载均衡
• 断路器
• 分布式消息传递

Springcloud核心组件：Eureka注册中心。Eureka是Netflix开源的一款服务驻注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是SpringCloud体系中最重要的组件之一。Euyeka就是一个服务中心，将所有的可用的服务都注册在这里进行管理，其他各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平拓展/故障转移等。

因此服务系统的注册中心至关重要，一旦挂掉就会影响全部服务，因此需要搭建Eureka集群来保持高可用性，生产中建议使用最少两台。随着系统流量不断增加，需要根据情况来拓展某个服务，Eureka内部已经实现负载均衡地功能，只需要增加相应的服务端实例就可以了。那么在系统运行期间某个实力挂了怎么办，Eureka有一个心跳检测机制，如果某个实例在规定时间内没有进行通讯则会被自动剔除掉，避免某个实例挂掉影响服务。

Eureka具有注册中心/负载均衡/故障转移等功能。

 

Hystrix

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

下图中：A作为服务提供则，B为A的服务消费者，c和D是B的服务消费者，A不可用引起了B不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。

 

在这种情况下，就需要真个服务机构具有故障隔离的功能，避免某一个服务挂掉会影响全局。在Springcloud中Hystrix组件就扮演这个角色。

Hystrix会在某个服务联系调用N此不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了服务整体。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。

Hystrix Dashboard和Turbine：

当熔断发生的时候要迅速的响应来解决问题，避免故障进一步扩散

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard，可以直观看到各个Hystrix Command请求响应时间，请求成功率等数据。但是Hystrix Dsahboard只能查看单个应用内的服务信息，需要一个工具汇总系统内多个服务数据并列显示到Hystrix Dashboard ,这个工具就是Turbine；

 

Springcloud config ：解决分布式系统配置管理方案。包含Client和Server两个部分。Refresh，在服务运行期间重新加载配置文件。

Springcloud Bus ：消息总线。通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其他消息指令中，SpringCloud bus核心思想是通过分布式启动器对Springboot进行拓展，也可以建立一个或者多个应用之间的通信频道。目前唯一的实现方式是AMQP消息代理作为通道。

有了Springcloud bus,当我们改变配置文件提交到版本库中时，自动触发对应实例的bus/refresh，客户端A机会发送消息给Springclient Bus,接着消息总线就会发送消息给各个客户端。

 

服务网关：微服务模式下，后端服务实例是动态的，对于客户端而言很难发现动态改变的实例的访问信息。因此基于微服务的项目中为了简化前端的调用逻辑，通常引用API Gateway 作为轻量级网关，同时Api Gateway 也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

Springcloud体系中支持Api Gateway落地技术是Zuul。Springcloud zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控、弹性、安全等边缘服务。Zuul是Netflix出品的JVM路由和服务端的负载均衡器。

具体作用就是服务转发，接受并转发所有内外部的服务端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似功能。

链路追踪：服务越来越复杂，对调用链分析越来越复杂，如服务之间调用关系、某个请求对应的调用链、调用之间消费的时间等。对这些信息进行监控就成了一个问题。在实际运用中我们需要监控服务和服务之间的通讯的各项指标。Springcloud也给出了集体的解决方案：springcloud Sleuth和Zipkin

 

Springcloud组件服务配套使用：

SpringCloud设计之初就考虑了大型互联网公司的架构演变，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能手势以插拔的形式提供出来，方便我们系统架构演变。可以合理地选择需要的组件进行集成，从而在演进过程中会更加平滑顺利。

 

SpringCloud--配置管理

加入需要同时搭建多台服务器，可以对每台服务器做相同配置，但是维护和同步成本较高。

默认使用git进行配置文件管理，所有web服务均从GIT里面进行获取配置文件，由于Git服务器与web服务器之间不需要共享存储，只需要网络可达就行，从而实现web服务于配置信息的存放位置的解耦。

SpringCloud同一控制应用和GIT服务的交互，用用只需要按照Springcloud规范配置GIT的URL皆可以。

Localhost:8888/abc/xyz

其中abc就是application的名字，xyz就是profile的名字，config server这个Rest接口返回的只是应用名为abc，profile名为xyz时，GIT配置环境变量的结构。

Config server提供的REST接口，SpringCloud 官方文档，几个可选的URL：

1. /{application}/{profile}[/{label}]
2. /{application}-{profile}.yml
3. /{label}/{application}-{profile}.yml
4. /{application}-{profile}.properties
5. /{label}/{application}-{profile}.properties

比如第三个格式，如果在GIT版本库中有一个配置文件Spring-cloud/helloworldConfig/config-client-dev.properties,那么访问

配制文件约定内容：

{application}-{profile}.properties或者{application}-{profile}.yml

http://localhost:8888/config-client-dev.properties就可以显示配置文件内容。

SpringCloud配置服务结构图：

 

Spring Cloud Zuul路是微服务架构中不可或缺的一部分，提供动态路由。监控，弹性，安全等的边缘服务，Zuul是 Netflix出品的基于JVM路由和服务端的负载均衡器。提供负载均衡、反向代理、权限认证的API Gateway。

服务化：通过URL映射的方式实现Zuul转发具有局限性，比如每增加一个服务就需要配置一条内容，另外后端的服务如果是动态来提供的，就不能实现这种方式来配置。实际上在实现微服务架构时，服务名与服务实例地址关系在eureka server中已经存在，只需要将Zuul注册到eureka server上发现其他服务，就可以实现serviceId的映射。

demo中一些注解示例：

Spring-cloud-eureka: 注解@SpringBootApplication   @EnableEurekaServer

Getway-service-suul-simple 注解 @SpringBootApplication  @EnableZuulProxy

Getway-service-zuul-eureka注解：@SpringBootApplication  @EnableZuulProxy

Spring-cloud-eureka: @SpringBootApplication   @EnableEurekaServer

Spring-cloud-producer:@SpringBootApplication  @EnableDiscoveryClient

 

Zuul核心：

Filter是Zuul的核心，用来实现对外服务控制。Filter生命周期4个，分别是PRE、ROUTING 、POST、ERROR，整个生命周期下图：

Zuul大部分功能都是通过过滤器实现的，这些过滤器类型对应于请求的典型生命周期。

PRE: 这种过滤器在请求被路由之前调用，可以利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

ROUNTING：将请求路由到位服务，用于构建发送微服务的请求，并使用Apache HttpClient或Netflix Ribbon请求微服务。

Post： 路由到微服务以后执行，用于响应添加标准的HTTP Header 、收集统计信息和指标、将相应从微服务发送给客户端等。

ERROR:在其他阶段发生错误时执行该过滤器。除了默认的过滤器类型外，Zuul允许将我们创建的自定义过滤器类型，例如，我们还可以制定STATIC类型的过滤器，直接在Zuul中生成相应，而不将请求转发到后端的微服务。

 

 

总结springcloud技术栈：

Springboot—为服务入门微框架，简化Spring应用初期搭建初级开发过程

Eureka：远端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

SpringCloud config—配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git、以及Subversion

Hystrix:熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点，从而延迟和故障提供更强大的容错能力。

Zuul—Zuul实在云平台上提供动态路由、监控、弹性、安全等边缘服务的框架，Zuul相当于设备和Netflix流应用的Web网站后端所有请求的前门。

Springcloud Bus—事件、消息总线，用于集群（例如配置变化事件）中传播状态变化，可用于Springcloud config联合热部署。

Springcloud Sleuth—日志收集包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。

Ribbon—提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。

Turbin：Turbin是聚合服务器发送事件流数据的工具，封装了Redis、Rabbit、Kafka等发送接收信息。

Feign:--Feign是一种声明式、模板化Http客户端

Springcloud OAuth2  基于Spring Security和OAuth2安全工具包，为应用程序添加安全控制。

 

Springcloud参考文档：https://blog.csdn.net/chen978616649/article/details/78493001/