福从天降，仅此一次！阿里巴巴独家微服务全解手册已“重现江湖”

写在前面

Spring Cloud for Alibaba，它是由一些阿里巴巴的开源组件和云产品组成的。这个项目的目的是为了让大家所熟知的 Spring 框架，其优秀的设计模式和抽象理念，以给使用阿里巴巴产品的 Java 开发者带来使用 Spring Boot 和 Spring Cloud 的更多便利。

很多人可能会问，有了spring cloud这个微服务的框架，为什么又要使用spring cloud alibaba这个框架了？

随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。所以急需其他的一些替代产品，也就是spring cloud alibaba，目前正处于蓬勃发展的态势。

目前市面上Spring Cloud Alibaba相关的博文书籍少之又少，我翻阅了各大平台网站都没有发现真正能把Spring Cloud Alibaba讲解的十分透彻，由此特意去阿里拜访了一位老朋友，整理出了这份Spring Cloud Alibaba全解，在这里我选择将它进行一个开源式的分享，大体内容如下：

spring cloud alibaba全解2

目录

 

 

 

第一章微服务介绍

系统架构演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在，系统架构大体经历了下面几个过程:单体应用架构>垂直应用架构>分布式架构>SOA架构>微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。接下来我们就来了解一下每种系统架构是什么样子的，以及各有什么优缺点。

单体应用架构

 

 

微服务架构的常见问题

一旦采用微服务系统架构，就势必会遇到这样几个问题:

• 这么多小服务，如何管理他们? (服务治理注册中心[服务注册发现剔除])
• 这么多小服务，他们之间如何通讯? (restful rpc)
• 这么多小服务，客户端怎么访问他们? (网关)
• 这么多小服务，一旦出现问题了，应该如何自处理? (容错)
• 这么多小服务，一旦出现问题了，应该如何排错? (链路追踪)

对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。

 

 

SpringCloud Alibaba介绍

Spring Cloud Alibaba致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过Spring Cloud编程模型轻松使用这些组件来开发分布式应用服务。依托Spring Cloud Alibaba,您只需要添加一些注解和少量配置，就可以将Spring Cloud应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

主要功能

 

第二章微服务环境搭建

案例准备

技术选型

maven: 3.3.9

数据库: MySQL 5.7

持久层: SpingData Jpa

其他: SpringCloud Alibaba 技术栈

模块设计

springcloud-alibaba父工程

shop-common公共模块[实体类]

shop-user用户微服务[端口: 807x]

shop-product商品微服务[端口: 808x]

shop-order订单微服务[端口: 809x]

 

 

创建用户微服务

 

创建商品微服务

 

创建订单微服务

 

第三章Nacos Discovery--服务治理

服务治理介绍

先来思考一个问题

通过上一章的操作， 我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址(ip,端口)等硬编码到了代码中，这种做法存在许多问题:

●一旦服务提供者地址变化，就需要手工修改代码

●一旦是多个服务提供者，无法实现负载均衡功能

●一旦服务变得越来越多，人工维护调用关系困难

 

那么应该怎么解决呢，这时候就需要通过注册中心动态的实现服务治理。

什么是服务治理

服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。

 

1.服务注册:在服务治理框架中，都会构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单，服务注册中心需要以心跳的方式去监测清单中的服务是否可用，如果不可用，需要在服务清单中剔除不可用的服务。

 

2.服务发现:服务调用方向服务注册中心咨询服务，并获取所有服务的实例清单，实现对具体服务实例的访问。

 

 

实现服务调用的负载均衡

什么是负载均衡

通俗地讲，负载均衡就是将负载(工作任务，访问请求)进行分摊到多个操作单元(服务器组件)上进行执行。

 

根据负载均衡发生位置的不同，一般分为服务端负载均衡和客户端负载均衡。

 

服务端负载均衡指的是发生在服务提供者一方,比如常 见的nginx负载均衡

 

而客户端负载均衡指的是发生在服务请求的一方，也就是在发送请求之前已经选好了由哪个实例处理请求。

 

第四章Sentinel--服务容错

高并发带来的问题

在微服务架构中，我们将业务拆分成一个个的服务， 服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。

接下来，我们来模拟一个高并发的场景

 

服务雪崩效应

在分布式系统中,由于网络原因或自身的原因,服务般无法保证 100%可用。如果一个服务出现了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待，进而导致服务瘫痪。

由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩效应”。

 

 

实现一个接口的限流

 

第五章Gateway--服务网关

网关简介

大家都都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢?如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。

 

 

过滤器

 

网关限流

 

第六章Sleuth--链路追踪

链路追踪介绍

在大型系统的微服务化构建中，一个系统被拆分成了许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。在这种架构中，-次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题:

• 如何快速发现问题?
• 如何判断故障影响范围?
• 如何梳理服务依赖以及依赖的合理性?
• 如何分析链路性能问题以及实时容量规划?

 

Zipkin的集成

 

第七章Rocketmq--消息驱动

MQ简介

 

 

RocketMQ的架构及概念

 

第八章SMS--短信服务

短信服务介绍

短信服务(Short Message Service)是阿里云为用户提供的一种通信服务的能力。

• 产品优势:覆盖全面、高并发处理、消息堆积处理、开发管理简单、智能监控调度
• 产品功能:短信通知、短信验证码、推广短信、异步通知、数据统计
• 应用场景:短信验证码、系统信息推送推广短信等

 

 

第九章Nacos Config--服务配置

服务配置中心介绍

首先我们来看一下,微服务架构下关于配置文件的一些问题:

1. 配置文件相对分散。在一个微服务架构下， 配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统配置和管理。
2. 配置文件无法区分环境。微服务项目可能会有多个环境，例如:测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，-一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
3. 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。

基于上面这些问题，我们就需要配置中心的加入来解决这些问题。

配置中心的思路是:

• 首先把项目中各种配置全部都放到一个集中的地方进行统一管理， 并提供套标准的接口。
• 当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
• 当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

当加入了服务配置中心之后，我们的系统架构图会变成下面这样

 

nacos的几个概念

 

第十章Seata--分布式事务

分布式事务基础

 

 

Seata介绍

2019年1月，阿里巴巴中间件团队发起了开源项目Fescar (Fast & EaSy Commit AndRollback)，其愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。后来更名为Seata,意为: Simple Extensible Autonomous TransactionArchitecture,是一套分布式事务解决方案。

Seata的设计目标是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进。它把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务。

 

Seata实现分布式事务控制

 

由于笔记涉及到的知识点太多了，就不一一展示给大家了，需要完整版【spring cloud alibaba全解2】笔记的朋友，可以点赞此文关注小编，按下图步骤后获取！！

总结

其实 Spring Cloud for Alibaba 项目就是为了阿里的项目能很好地结合融入 Spring Boot & Cloud 使用，这个项目目前由阿里维护。

对同时使用 Spring Cloud 和阿里巴巴项目的人来说无疑带来了巨大的便利，一方面能结合 Spring 无缝接入，另一方面还能使用阿里巴巴的组件，也带来了更多的可选择性。

现在更多优秀的阿里产品融入开源社区，相信 Java 开发环境会越来越好，Java 也会越来越强大！

动手转发给更多的朋友吧！