springcloud alibaba.pdf

发布时间：2022-06-03 发布人：admin 分类：说明书资料大小：11.21M 资料格式：pdf 举报版权申诉

mythsmyths-12441892-16359647324421882143.pdf-第1页.png

第1页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第2页.png

第2页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第3页.png

第3页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第4页.png

第4页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第5页.png

第5页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第6页.png

第6页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第7页.png

第7页 / 共140页

mythsmyths-12441892-16359647324421882143.pdf-第8页.png

第8页 / 共140页

第一章微服务介绍

1.1 系统架构演变

1.1.1 单体应用架构

1.1.2 垂直应用架构

1.1.3 分布式架构

1.1.4 SOA架构

1.1.5 微服务架构

1.2 微服务架构介绍

1.2.1 微服务架构的常见问题

1.2.2 微服务架构的常见概念

1.2.2.1 服务治理

1.2.2.2 服务调用

1.2.2.3 服务网关

1.2.2.4 服务容错

1.2.2.5 链路追踪

1.2.3 微服务架构的常见解决方案

1.2.3.1 ServiceComb

1.2.3.2 SpringCloud

1.2.3.3 SpringCloud Alibaba

1.3 SpringCloud Alibaba介绍

1.3.1 主要功能

1.3.2 组件

第二章微服务环境搭建

2.1 案例准备

2.2 创建父工程

2.3 创建基础模块

2.4 创建用户微服务

2.5 创建商品微服务

2.6 创建订单微服务

第三章 Nacos Discovery--服务治理

3.1 服务治理介绍

3.2 nacos简介

3.3 nacos实战入门

3.4 实现服务调用的负载均衡

3.4.3 基于Ribbon实现负载均衡

3.5 基于Feign实现服务调用

第四章 Sentinel--服务容错

4.1 高并发带来的问题

4.2 服务雪崩效应

4.3 常见容错方案

有隔离、超时、限流、熔断、降级

4.4 Sentinel入门

4.4.1 什么是Sentinel

4.4.2 微服务集成Sentinel

4.5 Sentinel的概念和功能

4.6 Sentinel规则

4.6.1 流控规则

4.6.2 降级规则

4.6.3 热点规则

4.6.4 授权规则

4.6.5 系统规则

4.7 @SentinelResource的使用

4.8 Sentinel规则持久化

4.9 Feign整合Sentinel

第五章 Gateway--服务网关

5.1 网关简介

5.2 Gateway简介

5.3 Gateway快速入门

5.4 Gateway核心架构

5.4.1 基本概念

5.4.2 执行流程

5.5 断言

5.5.1 内置路由断言工厂

5.5.2 自定义路由断言工厂

5.6 过滤器

5.6.1 局部过滤器

5.6.2 全局过滤器

5.7 网关限流

第六章 Sleuth--链路追踪

6.1 链路追踪介绍

6.2 Sleuth入门

6.2.1 Sleuth介绍

6.2.2 Sleuth入门

6.3 Zipkin的集成

6.3.1 ZipKin介绍

6.3.2 ZipKin服务端安装

6.3.3 Zipkin客户端集成

6.4 ZipKin数据持久化

6.4.1 使用mysql实现数据持久化

6.4.2 使用elasticsearch实现数据持久化

第七章 Rocketmq--消息驱动

7.1 MQ简介

7.1.1 什么是MQ

7.1.2 MQ的应用场景

7.1.2.1 异步解耦

7.1.2.2 流量削峰

7.1.3 常见的MQ产品

7.2 RocketMQ入门

7.2.1 RocketMQ环境搭建

7.2.2 RocketMQ的架构及概念

7.2.3 RocketMQ控制台安装

7.3 消息发送和接收演示

7.3.1 发送消息

7.3.2 接收消息

7.4 案例

7.4.1 订单微服务发送消息

7.4.2 用户微服务订阅消息

7.5 发送不同类型的消息

7.5.1 普通消息

7.5.2 顺序消息

7.5.3 事务消息

7.6 消息消费要注意的细节

第八章 SMS--短信服务

8.1 短信服务介绍

8.2 短信服务使用

8.3 下单之后发送短信

第九章 Nacos Config--服务配置

9.1 服务配置中心介绍

9.2 Nacos Config入门

9.3 Nacos Config深入

9.3.1 配置动态刷新

9.3.2 配置共享

9.4 nacos的几个概念

第十章 Seata--分布式事务

10.1 分布式事务基础

10.2 分布式事务解决方案

10.2.1 全局事务

10.2.2 可靠消息服务

10.2.3 最大努力通知

10.2.4 TCC事务

10.3 Seata介绍

10.4 Seata实现分布式事务控制

10.4.4 seata运行流程分析

扩展章节 Dubbo--rpc通信

11.1 介绍

11.2 实现

11.2.1 提供统一业务api

11.2.2 提供服务提供者

11.2.3 提供服务消费者

第一章微服务介绍 1.1 系统架构演变随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布式架构--->SOA架构--->微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。接下来我们就来了解一下每种系统架构是什么样子的，以及各有什么优缺点。 1.1.1 单体应用架构互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。优点：项目架构简单，小型项目的话，开发成本低项目部署在一个节点上，维护方便缺点：

全部功能集成在一个工程中，对于大型项目来讲不易开发和维护项目模块之间紧密耦合，单点容错率低无法针对不同模块进行针对性优化和水平扩展 1.1.2 垂直应用架构随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量. 还是以上面的电商为例子，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块，而不增加消息模块. 此时单体应用就做不到了，垂直应用就应运而生了. 所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成: 电商系统(用户管理商品管理订单管理) 后台系统(用户管理订单管理客户管理) CMS系统(广告管理营销管理) 这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。优点：系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展一个系统的问题不会影响到其他系统，提高容错率缺点：系统之间相互独立，无法进行相互调用系统之间相互独立，会有重复的开发任务 1.1.3 分布式架构当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。优点：抽取公共的功能为服务层，提高代码复用性缺点：系统间耦合度变高，调用关系错综复杂，难以维护 1.1.4 SOA架构在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture，面向服务的架构)是关键。优点:

使用注册中心解决了服务间调用关系的自动调节缺点: 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 ) 服务关心复杂，运维、测试部署困难 1.1.5 微服务架构微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。优点：服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展微服务之间采用Restful等轻量级http协议相互调用缺点：分布式系统开发的技术成本高（容错、分布式事务等） 1.2 微服务架构介绍微服务架构，简单的说就是将单体应用进一步拆分，拆分成更小的服务，每个服务都是一个可以独立运行的项目。 1.2.1 微服务架构的常见问题一旦采用微服务系统架构，就势必会遇到这样几个问题：这么多小服务，如何管理他们？(服务治理注册中心[服务注册发现剔除]) 这么多小服务，他们之间如何通讯？(restful rpc) 这么多小服务，客户端怎么访问他们？(网关) 这么多小服务，一旦出现问题了，应该如何自处理？(容错) 这么多小服务，一旦出现问题了，应该如何排错? (链路追踪) 对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。

1.2.2 微服务架构的常见概念 1.2.2.1 服务治理服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。服务注册：服务实例将自身服务信息注册到注册中心。服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

1.2.2.2 服务调用在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于 HTTP的RESTful接口以及基于TCP的RPC协议。 REST(Representational State Transfer) 这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议 RPC（Remote Promote Call）一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。区别与联系

比较项通讯协议性能灵活度应用 1.2.2.3 服务网关 RESTful HTTP 略低高 RPC 一般使用TCP 较高低微服务架构 SOA架构随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：客户端需要调用不同的url地址，增加难度在一定的场景下，存在跨域请求的问题每个微服务都需要进行单独的身份认证针对这些问题，API网关顺势而生。 API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。 1.2.2.4 服务容错在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：不被外界环境影响不被上游请求压垮

不被下游响应拖垮 1.2.2.5 链路追踪随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪 1.2.3 微服务架构的常见解决方案 1.2.3.1 ServiceComb

分享到：

赞收藏

资料库

springcloud alibaba.pdf

相关推荐

行业

热门标签

最新资料