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:
- /{application}/{profile}[/{label}]
- /{application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{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/