1. 整体目录介绍
第一章 微服务介绍
1.1 传统单体架构
1.2 SOA架构
1.3 微服务架构
1.4 微服务的拆分建议
1.5 微服务与集群的关系
1.6 微服务架构的组件
1.7 SpringBoot与SpringCloud的区别
1.8 SpringCloud与Dubbo区别
1.9 Spring Cloud for Alibaba
第二章 微服务环境搭建
2.1 技术选型
2.2 创建服务
第三章 Nacos注册/配置中心
3.1 nacos介绍
3.2 nacos入门使用
3.3 服务调用Feign
第四章 GetWay服务网关
4.1 网关介绍
4.2 GetWay入门使用
第五章 Sentinel服务容错
5.1 高并发带来的问题
5.2 Sentinel入门使用
第六章 Sleuth链路追踪
第七章 RabbitMQ消息中间件
第八章 SMS短信服务
第九章 Seata分布式事务
2. 传统单体应用架构
程序在编写完成之后会被打包并部署为一个具体的应用。Java Web项目打包成WAR包，Java项目打包成JAR包。
但是随着用户人数的增加，一台机器可能满足不了系统的负载，此时我们就会考虑水平扩展。
面对上述情况，我们通常会增加服务器的数量，并将打包好的应用拷贝到不同服务器，然后通过负载均衡器实现应用的水平扩展。
缺点
// 1. 应用维护困难 随着时间推移项目逐渐变大，一旦项目变得庞大而复杂，就很难进行二次开发与维护。
// 2. 可靠性低 因为所有模块都运行在一个进程中，任何一个模块出现问题，都会导致整个进程崩溃，进而影响到整个应用。
// 3. 不利于技术更新 如果需要更改某个技术，可能需要将整个应用重新开发。
3. SOA架构
针对传统单体架构的问题，企业开始通过SOA【面向服务的架构】来解决。
SOA：把应用中相近的功能聚合到一起，以服务的形式提供出去。即：他将原来的单体架构细分为不同的子系统，再由各个子系统互相调用所需的服务。
优点
// 1. 将项目拆分成若干个子项目，不同的团队可以负责不同的子项目，从而提高开发效率。
// 2. 把模块拆分，使用接口通信，降低了模块之间的耦合度。
// 3. 能够升级单个服务而无需重写整个应用。
缺点
// SOA中各个相互独立的服务还是部署在同一个Tomcat实例，随着业务功能的增多，会导致SOA服务越来越复杂。
4. 微服务架构
微服务架构：是一种架构风格和架构思想。
它倡导我们在传统单体架构的基础上，将系统按照功能拆分为更加细粒度的服务。
所拆分的每一个服务都是一个独立的应用，单独部署。这些应用对外提供公共的API，可以独立承担对外服务的职责。
围绕着这一思想的一系列体系结构【开发，测试，部署等等】，我们就可以称它为“微服务架构”。
优点
// 1. 每个微服务可以独立部署 当某个微服务发生变更时，不需要重新部署整个项目。
// 2. 技术选型灵活 各个微服务的技术选型可以不一样，当需要对某个微服务技术升级时，不需要面临对整个项目的重新开发。
// 3. 复杂度可控 每个微服务专注单个功能，体积小，复杂度低，便于维护。
// 4. 易于容错 当某个服务发生故障时，在设计良好的情况下，其他服务一般不会被影响。
// 5. 易于扩展 单个服务可以水平扩展，比如：订单服务访问高，我可以对其多部署几个服务。
SOA与微服务区别
SOA项目分为多个子系统，粗粒度。微服务项目分为多个微服务，细粒度。
SOA项目服务部署在一起，互相依赖。微服务项目每个微服务可以独立部署。
4. 微服务的拆分建议
-
通过业务功能分解并定义与业务功能相对应的服务。
-
按照动词或用例分解，并定义负责特定操作的服务。例如：一个负责完成订单的航运服务。
-
通过定义一个对给定实体或资源的所有操作负责的服务。例如：一个负责管理用户账户的账户服务。
补充. 分布式微服务与集群的关系
分布式：多个独立的计算机集合，每个计算机做不同的事，共同支撑一个系统。
集群：多个独立的计算机集合，每个计算机做相同的事，共同支撑某一个服务。
分布式中的每一个节点也都可以做集群。
5. 微服务架构的组件
前言：开发微服务架构的项目，我们一般采用如下组件。
// 1. 微服务注册中心 注册系统中所有服务的地方。
// 2. 服务注册 服务提供方将自己的调用地址注册到服务注册，用于让服务调用方能够方便快速地调用自己
// 3. 服务发现 服务调用方从注册中心找到自己要调用的服务的地址。
// 4. 负载均衡 服务提供方以多实例的形式提供服务，使用负载均衡能让服务调用方连接到合适的服务节点。
// 5. 服务容错 通过一系列保护机制，保证服务调用者在调用到异常服务时能快速返回结果，免得长时间等待。
// 6. 服务网关 服务调用的唯一入口，一般用来实现用户鉴权，动态路由，负载均衡，限流等功能。
// 7. 分布式配置中心 将本地的配置信息注册到配置中心统一管理。 为什么要统一管理呢？ 各个微服务的配置文件可能不一样，而且配置在本地，如果要修改配置，修改完需要重启。有了分布式配置中心，就可以解决这些问题。
// 微服务实例的开发 springBoot
// 服务注册 eureka zookeeper nacos consul
// 服务发现 feign dubbo
// 负载均衡 ribbon
// 服务容错 hystrix sentinal
// Api网关 zuul gateway
// 分布式配置中心 springcloud config nacos
// 分布式事务 seata lcn
6. SpringBoot与SpringCloud的区别
SpringCloud
它是在SpringBoot的基础上构建的，它不是一个具体的技术，而是一个简化分布式系统构建的工具集。
Spring Cloud中包含多个子项目，如：Spring Cloud Netflix，Spring Cloud Config，Spring Cloud Starters等。
SpringBoot
它是一个用来开微服务实例的。
7. SpringCloud与Dubbo区别
Spring Cloud：本身也是基于SpringBoot开发而来，SpringCloud是一系列框架的有序集合，就是把非常流行的微服务的技术整合到一起。
dubbo：本身只是众多分布式开发中解决问题的一种方式，它主要是做服务调用，而spring cloud 是一系列的有序集合。
7. Spring Cloud for Alibaba
spring cloud中的几乎所有的组件都使用Netflix公司的产品【eureka，hystrix，rabbin，zuul，config...】，然后在其基础上做了一层封装【比如推出openFeign(对feign进行了一个升级)，推出了gateWay来替换zuul】，还增加了几个没什么大作用的组件，然后就推出来了。
然而Netflix公司的18年12月12日宣布的服务旗下产品进行维护，其发现组件Eureka，Hystrix等 已经停止更新，而其他的众多组件预计会在明年(即2020年)停止维护。如此一来，SpringCloud就要凉凉了。
此时开发者们急需其他的一些替代产品，此时spring cloud alibaba就来了，它是由阿里巴巴提供的。Spring Cloud 这时就急了鸭，他就与spring cloud alibaba达成合作，将Spring cloud alibaba整合到sping cloud，将其作为Spring Cloud 下的子项目。
整合之后，依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里提供的某些中间件来迅速搭建分布式应用系统。
说说Spring Cloud Alibaba的版本号
SpringCloud的版本号是英文方式。因为springcloud是微服务的解决方案，他会有很多子项目，每个子项目都维护这自己的版本号，为了避免冲突，就使用了伦敦地铁站的名字作为版本号。以首字母作为顺序，a,b,c,d....排列。
再说咱们国人开发的，我们没有用英文名，还是数字那种方式。
SpringCloud for alibaba：https://spring.io/projects/spring-cloud-alibaba