微服务(一)架构的演变以及SpringCloud部分相关组件

微服务(一)架构的演变以及SpringCloud部分相关组件

  • 1. 架构的演变以及微服务定义
  • 2. 微服务相关组件

1. 架构的演变以及微服务定义

如果是特别小的项目,可以用dubbo集成zookeeper就行。
早期是SOA架构,面向服务的开发,比如一个springboot项目,一个商城项目一个财务项目,都是依赖于一个数据库的。
微服务(一)架构的演变以及SpringCloud部分相关组件_第1张图片
上面是面向单体应用,下面是面向服务或者模块开发,两个模块组成一个项目。打成一个war包。
微服务(一)架构的演变以及SpringCloud部分相关组件_第2张图片
随着技术的前进,形成了如下的架构显示。
微服务(一)架构的演变以及SpringCloud部分相关组件_第3张图片
上面是SOA,打多个war包,两个war包独立运行,两个模块有共同依赖,假设都在商城服务中,但是从财务服务访问共同依赖,需要RPC远程调用服务。

什么是微服务?从面向需求(或者应用)这个维度进行拆分,比如抽离出一个小服务为订单服务,对比以前的服务(SOA)粒度更小。
微服务的拆分是值得关注的问题,许多业务部门招架构师都需要一定的专业背景,这不仅仅是技术上的需要,还有的是对微服务拆分的需要,否则微服务如果拆分过多,会有网络延迟,这个度需要把握好。

2. 微服务相关组件

首先需要明确一点,所有的微服务都是基于springboot的。

假设有3个支付服务,需要做负载均衡,在客户端这里,需要获取服务的列表,怎么获取服务的列表?有个中间商,注册中心,这里用到技术框架一开始为netflix Eureka,可以从Eureka中拿回来放到服务列表中,有了服务列表之后,需要调用组件,是用到netflix feign组件,发起远程调用的,feign从服务列表找一个,直接调过去了。但是调的过程中,需要做客户端的负载均衡,这个时候需要用一下netflix Ribbon,是个客户端的负载均衡,ribbon是一个尝试的功能,如果调用失败,下一次就不让fegin去调用该服务了。什么是客户端的负载均衡?可以主动选择,前提需要知道服务有多少。服务调起之后,这个时候是返回结果给客户端,之后,拿这个结果渲染结果数据。可以用json或者thymeleaf。

在这里,需要把所有结构拆分为服务提供方与服务调用方。
服务提供方:包含了fegin、ribbon以及其他组件,也就是一个springboot包含了这些。
服务调用方:为支付服务service。

服务提供方也需要做负载均衡,一个controller扛不住,需要有多个controller,这个时候需要不能直接暴露controller出来,需要做服务的负载和服务的路由以及权限的处理。这个时候加个网关层。用netflix zuul做服务的网关,所有的请求由它来路由,所谓的路由其实也就是一个URL,告诉zuul之后,用户请求的URL就能直接定位到该Controller,这里的controller可以做横向的负载(镜像)也可以做纵向的负载(不同作用)。也可以在zuul中做一些权限认证的功能,可以不用在controller层跑权限认证,网关这里是拦截一切的请求的,所有的请求都打到zuul上,如果zuul扛不住也可以做多个。在这个zuul里,可以做统一的权限处理,可以集成springcloud securityJWT。如果不用spring security或者是JWT的时候,用shiroshiro是集成在服务提供方controller。需要独自维持会话了,需要SpringSession,这是做session共享用的,但是如果做了oauth2.0与JWT的话,就不用session共享了。Springsecuity可以用在oauth2.0也可用在RBAC中。这里都是基于拦截器的,在controller层。注意,这里的zuul做的网关其实是业务网关,在流量介入层中,还需要一个流量网关,通常是用nginx、LVS、keepalived做。流量介入层很重要,如果流量介入层扛不住,那么微服务的性能也不行了。但是流量介入层的流量网关一般很少做,因为除非是很大很大并发的项目,否则只需要业务网关就行了。

Ribbon调服务的时候,涉及到分布式事务,分布式系统下的事务需要自己去保证了,在单机情况下,利用spring事务机制就行,但是分布式中,却不行。Alibaba Seata,也可以用Gts。调服务时候也涉及到链路追踪,如果服务调用服务再调用服务,这个里面调用多个服务,但是有异常,怎么定位?观察?所以需要链路追踪,sleuth或者是zipkin或者skywalking。也会涉及到分布式锁,zookeeper curator或者redlock

熔断与降级,在ribbon调用服务的时候,不管后面的客户端是否可用,当服务出现长时间等待或不可用情况,能实现熔断和降级处理。Hystrix记录后面服务的状态,是否靠谱,不靠谱就熔断(再也不调,除非该服务又可以正常调用)。为了达到服务啥时候上来给hystrix知道,给每个微服务加个组件(节点信息上报功能)——acturator,这是跑在每个服务中的,提供上报信息功能,上报给hystrix,重新上线。降级:系统整体较忙的时候,让后端的某些服务不提供服务,提供降级的接口。熔断和降级其实它们的原理都相似,都是服务调用失败后的进行一些快速失败措施。但它们的出发点不一样,熔断是为了防止异常不扩散,保证系统的稳定性。而降级则是人为操作。在一些流量顶峰期,为了保证某些热门接口的正常运作,有时候会牺牲一些非核心接口,把资源全都让给热点接口,这就是服务降级。每年12306抢票的时候,大家都集中抢购那几个热门车次的车票,而如果此时有其他用户去查询几天后的非热门车票,有可能会查不出来。这就是降级的表现,在秒杀期间,其他不参与秒杀的接口停止服务,把资源都让给参与秒杀的接口。怎么发现服务是否特别忙?通过actuator上报,另外还有一个统一化的管理,所有信息提交给springcloud admin,是一个所有服务的监控平台。
微服务(一)架构的演变以及SpringCloud部分相关组件_第4张图片
处理消息:spring messaging、spring integration、apache Camel、springcloud stream,messaging是最简单的,第二层是integration,第三层是springcloud stram与camel。Messaging是对单一消息中间件的包装,给它包装成一个统一的标准,屏蔽掉了框架的差异(RQ与kafka),integration或者是camel对messaging的集成,是做EIP的,把所有的消息中间件都放到一起,作为协调者。Springcloud stream对intergration再次包装,与springboot做了整合,为了做springcloud bus。可以做企业级的消息总线。最核心的是AMQP,把所有的消息中间件集成在一起。

微服务(一)架构的演变以及SpringCloud部分相关组件_第5张图片

微服务(一)架构的演变以及SpringCloud部分相关组件_第6张图片

你可能感兴趣的:(SpringCloud,架构,微服务,spring,cloud)