spring-cloud-Hoxton.SR6 (springBoot2.2.x-2.3.x)学习篇（一）

spring-cloud-Hoxton.SR6 (springBoot2.2.x-2.3.x)学习篇（一）

cloud版本: Hoxton.SR6

boot版本: 2.2.x-2.3.x

目前（2020-08-09）cloud官网最新的版本为Hoxton.SR7 (基于boot 2.3.x构建)

一、什么是微服务

• 戳我：进入官网
• 官方定义:微服务就是由一系列围绕自己业务开发的微小服务构成,他们独立部署运行在自己的进程里,基于分布式的管理
• 通俗定义:微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

- a suite of small services                      			    --一系列微小服务
- running in its own process                                    --运行在自己的进程里
- built around business capabilities                            --围绕自己的业务开发
- independently deployable                                      --独立部署
- bare minimum of centralized management of these services      --基于分布式管理

二、为什么要使用微服务

传统应用（单体应用）

所有的业务逻辑在一个项目中编写以及打包运行。

优缺点：

# 1.优点
-	单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。

# 2.缺点
- 应用随着时间的推进，加入的功能越来越多，最终会变得巨大，且代码冗余极高，久而久之，开发效率低，代码维护困难
- 由于项目为一个整体 对开发语言以及技术人员选择有局限性 一个项目中使用一种语言（java、php等）
- 牵一发而动全身,任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性

微服务架构应用

优缺点：

# 1.优点
- 将服务拆分成多个单一职责的小的服务，进行单独部署，服务之间通过网络进行通信
- 微服务有极强的扩展能力,业务量大的服务可以再次拆分服务，也可以进行集群部署，剔除服务也很方便
- 每个服务应该有自己单独的管理团队，高度自治
- 服务之间无耦合，服务之间升级维护互不影响
- 更大的系统负载能力和容错能力(集群)
- 解决单一的开发人员技术栈选择（java、php、go）（maven gradle）等

------------------凡事都有双面性，微服务展示出了他的优势之处，同时也有其不足的地方-------

# 2.缺点
- 开发人员要处理分布式系统的复杂性
- 小微服务多了，多运维人员/开发的DevOps要求较高
- 服务治理 和 服务监控 较为棘手
- 分布式事务问题
- 服务通信对性能的损耗

三、架构演变过程

[单体应用架构] ===> [垂直应用架构] ===> [分布式服务架构] ===> [流动计算架构]||[微服务架构] ===> [未知]

单体应用架构：

网站小，业务不是很多，所有功能卸载一个应用中，减少部署成本 CRUD 为核心功能

垂直应用架构：

网站有点规模，业务规模增大了点，访问量随之增大了点，增加机器对应用性能提升有限，于是呢，将原来的单体应用拆分为几个，例如 前端用应用，后端应用等 ，三层架构 思想 前后分离思想

分布式服务架构：

垂直应用越来越多，应用之间交互不可避免，于是想着将一些核心的功能模块或业务模块单独拆分出来，将服务分散部署在不同的机器上的，但一个服务可能负责几个功能，能提供一个强大的稳定的服务中心，用于提高业务复用及整合。

微服务架构：

微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，但是由于服务微服务化后给团队带来的挑战也是显而易见的，例如服务粒度小，数量大，DevOps要求提高

四、什么是SpringCloud

概念意义

• 戳我：进入

- springcloud为开发人员提供了在分布式系统中快速构建一些通用模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线）。分布式系统的协调导致了锅炉板模式，使用springcloud开发人员可以快速地建立实现这些模式的服务和应用程序。

核心组件

- eureka-server                 服务注册中心组件
- rabbion & openfeign  			服务负载均衡 和 服务调用组件
- hystrix & hystrix dashboard   服务断路器  和  服务监控组件
- zuul 				            服务网关组件
- config 						统一配置中心组件
- bus                           消息总线组件
- zipkin                        服务链路追踪组件

当然了，上方仅仅为 springcloud最开始为我们提供的组件

随着几年的发展，也出现了很多 新兴组件，其工作模式及思路呢，也是与上方类似，只是做了加强或进一步封装而已，但是，最上方基础组件，也是很有必要学习的，只要掌握了上方工作模式，再使用其他一些替代型组件时才会更易上手。

例如：

- consul、zookeeper、nacos   可替换 eureka作为服务注册中心组件
- sentinel                  服务断路器 限流 组件
- gateway  					服务网关组件
- nacos  					服务配置中心组件  没错 nacos 可以作为注册中心同时也可以作为配置中心
- skywalking 				服务链路追踪组件

SpringCloud基本架构图

后边我也会尝试学习一些Alibaba生态圈的微服务组件

SpringCloudAlibaba架构图

Spring Cloud Alibaba其实是阿里的微服务解决方案，是阿里巴巴结合自身微服务实践,开源的微服务全家桶，在Spring Cloud项目中孵化成为Spring Cloud的子项目。第一代的Spring Cloud标准中很多组件已经停更,如：Eureak,zuul等。所以Spring Cloud Alibaba很有可能成为Spring Cloud第二代的标准实现，所以许多组件在业界逐渐开始使用，已有很多成功案例

五、SpringCloud版本信息

• 戳我：进入cloud官网查看版本信息

• springcloud 版本管理方式: 命名方式 Angel.SR1~6 Brixton.SR1~6 Camden.SR1~6

• 其版本信息与我们常见的版本管理是不一样的，其是以伦敦地铁站名称 天使、布里斯顿、卡姆登 …

• 发布序列将推出名称以“.SRX”结尾的“服务发布,X代表数字 例如 SR1 SR2… 目前都 H 版本了最新版为 Hontox.SR7

• 注意的是,springcloud是基于springboot构建的 ,且高版本是不兼容低版本的，且 springboot版本信息需根据官网提示,与springcloud 相对应。

• 版本选择

  • 戳我：查看官网版本建议选择

  - Angel 										版本基于springboot1.2.x版本构建与1.3版本不兼容
  - Brixton										版本基于springboot1.3.x版本构建与1.2版本不兼容
  	`2017年Brixton and Angel release官方宣布报废
  - Camden      							版本基于springboot1.4.x版本构建并在1.5版本通过测试
  	`2018年Camden release官方宣布报废
  - Dalston、Edgware 				 版本基于springboot1.5.x版本构建目前不能再springboot2.0.x版本中使用
  	`Dalston(达尔斯顿)将于2018年12月官方宣布报废。Edgware将遵循Spring Boot 1.5.x的生命周期结束。
  - Finchley 									版本基于springboot2.0.x版本进行构建,不能兼容1.x版本
  - Greenwich									版本基于springboot2.1.x版本进行构建,不能兼容1.x版本				
  - Hoxton								    版本基于springboot2.2.x版本进行构建,不能兼容2.1.x 机1.x版本
  

  当前学习版本选择为：

  - SpringBoot  2.2.5
  
  - SpringCloud Hontox.SR6  (最新为2.3.x的 Hontox.SR7)
  

---