三分钟学会springcloud微服务

SpringCloud Alibaba

if not now when ,if not me who

官网

[https://spring.io/projects/spring-cloud-alibaba]

Spring Cloud

• Flow control and service degradation：flow control, circuit breaking and system adaptive protection with Alibaba Sentinel

• Service registration and discovery：instances can be registered with Alibaba Nacos and clients can discover the instances using Spring-managed beans. Supports Ribbon, the client side load-balancer via Spring Cloud Netflix

• Distributed Configuration：using Alibaba Nacos as a data store

• Event-driven：building highly scalable event-driven microservices connected with Spring Cloud Stream RocketMQ Binder

• Message Bus: link nodes of a distributed system with Spring Cloud Bus RocketMQ

• Distributed Transaction：support for distributed transaction solution with high performance and ease of use with Seata

• Dubbo RPC：extend the communication protocols of Spring Cloud service-to-service calls by Apache Dubbo RPC

1、Spring Cloud Alibaba 是什么

Spring Cloud Alibaba 是阿里巴巴提供的微服务开发一站式解决方案，是阿里巴巴开源中间件与 Spring Cloud 体系的融合。

2、springcloud的简介

2.1：说到springCloud Alibaba就不得不说 springCloud全家桶系列，抛开耳熟能详的spring,springMVC,springBoot,微服务方面有springcloud，该springcloud主要有许多框架集合组成，其中包括spring-cloud-config、spring-cloud-bus 等近 20 个子项目，他提供了服务治理，路由限流，服务容灾，服务网关，负载均衡，配置统一调度管理等等。其中主要是基于springBoot脚手架搭建的restful风格的微服务，主要以 Netflix 开源为主：

以一个小型电商项目为例，一个传统的电商系统，应该具备订单服务，支付服务，商品服务，库存服务，用户服务等等，我就以这几个服务来阐述下为什么要用springcloud。

2.2 为什么要用springcloud

Eureka 服务注册:
对于微服务来说，他是将服务拆分为每个单体架构也就是每个小型的服务，这些小型服务都可以独立运行起来，比如电商项目就拆分了许多服务，这就导致问题来了，每个服务都具有不同的ip地址和端口，不可能有开发者每个都记住，所以客户端调用服务端就会“迷路”，所以有没有什么好的“灯塔”来指引呢，答案是有的，Eureka就是为了解决这类型问题应用而生，服务端将自己的ip地址和端口，服务名全部注册到eureka服务中心中，相当于进行了小区业务登记，登记了自己的门牌号，客户端也就是访客想寻找这些户主的时候，只要向eureka登记中心，拿到他们的地址信息就可以了。

Gateway服务网关:
正如我之前说的每个服务都有自己独有的ip和端口号，即使通过服务注册中心能拿到其他的服务的ip地址信息，但是这是相对我们后端而言，对于现在前后端分离的模式，前端童鞋不可能会记住这一个个的服务地址，进行与后端交互，否则的话前端童鞋会发疯的，所以有没有一种“中间商”，前端童鞋只要知道这中间商的地址，通过与他进行交互，然后让其调用后端服务，答案是有的，通过gateway我们就可以进行路由分发，前端发起请求，访问gateway后面的服务，经过鉴权验证，有gateway找到相应的服务模块。这样前端只需要知道gateway的ip和端口号以及相应的服务名称即可。

openfeign负载均衡:
解决了前端方面的问题，我们看看后端有什么问题呢，正如我们所知每个模块就是一个服务，所以各个服务之前需要跨通信访问以及对于一些高并发场景下访问量巨大的服务，肯定不能只有一个服务，往往是集群存在，这就导致ip地址又会不一样，像原始的解决方法是通过restTemplate这个模板将服务地址ip和端口号进行拼接，每交互一个服务都需要拼接一次，极大的浪费了开发者面向业务，所以就有了openfeign组件，我们通过它，就可以很简单的进行模块之间的内部通讯，并且它天生支持负载均衡的策略功能。

比如我有一个场景需要订单调用支付系统，我只需要在订单服务里定义一个接口，添加上支付的映射地址，就能进行远程访问，还可以添加@loadBanlance进行负载均衡。

hystrix服务容错:
当服务添加过多的时候，基于他们的通信方式，肯定会涉及到网络的影响，当高并发场景下或者网络波动造成订单服务崩坏了，造成请求一直阻塞在该服务下，产生网络请求延迟，这就会导致其他服务网络波动，出现服务大面积失效，也就是“服务雪崩”效应，为了解决这种问题，“天空一声巨响，我们的"豪猪哥" 闪亮登场了”.通过它的线程隔离的思想，当出现某个服务崩坏的时候，进行fallback降级处理，出现异常，及时走备胎策略，不会产生请求阻塞的情况 ，也就是我们常说的保险丝熔断"跳闸".

config配置文件管理
每个服务内部都有至少一个配置文件，所以当出现很多微服务的时候，这些配置文件就显得不利于管理了，当其中一个配置文件发生更新时，不可能手动的将每一个配置文件进行更新，不现实也利于维护，所以出现了config配置管理中心，通过一个中央配置文件，一般存储到github上，旗下的每个子配置文件都交于该中心配置文件管理，当要进行修改的时候，只需要在中央配置文件进行更改，结合消息队列的广播，进行广播推送，就可以达到统一调度。

stream消息队列管理
这个组件主要是基于无感知更换消息队列，可以达到无缝切换项目中的消息队列。

介绍了这么多的springcloud组件，回到正题为什么要用springcloud alibaba，主要因为对于第一代的springcloud有很多组件目前官方以停止更新，比如"豪猪哥"而alibaba在它们原有的基础上进行了封装，服务注册中nacos不但支持ap理论，还支持cp理论，并且还支持配置文件的统一管理，一个组件具有springcloud很多组件的功能,这是其他服务注册中心没有的，并且界面是中文的，对我们国内程序员很友好的，而sentinel主要完成"豪猪哥"的使命，不过进行了扩展，不仅能通过线程隔离还能通过qps请求限制达到限流的作用。分布式seata具有全局事物回滚的功能，只要在db中加个undo的表，就能控制事物异常回滚

nacos界面图:

sentinel

总结:

以上就是我关于springcloud组件介绍以及springcolud alibaba的相关介绍,如有遗漏，还请各位大佬指正