SpringBoot 与 SpringCloud 有什么区别？
今日学习目标：
SpringBoot 与 SpringCloud 有什么区别？
✅创作者：林在闪闪发光
⏰预计时间：30分钟
个人主页：林在闪闪发光的个人主页林在闪闪发光的个人社区，欢迎你的加入: 林在闪闪发光的社区
目录
一、什么是微服务？
1.1 传统单体架构
1.2 微服务架构
二、Spring Cloud是什么？
三、Spring Cloud 五大组件
四、Spring Cloud和Spring Boot的关系
五、Spring Cloud和Dubbo的关系
一、什么是微服务？
在讲解SpringCloud之前，我们先来讲解什么是微服务？
1.1 传统单体架构
介绍：
单体架构在小微企业比较常见，典型代表就是一个应用、一个数据库、一个web容器就可以跑起来。
从图中可以分析，单体架构基本上就是如上所说的：一个应用，一个数据库，一个web容器，里面集成了所有的功能。
特点：
（1）所有的功能集成在一个项目工程中。
（2）所有的功能打一个war包部署到服务器。
优点：
项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：
（1）扩展性和可靠性差，因为所有功能集成在一个服务或者一个war包中，修改某个功能时，需要所有服务重新打包。
（2）前期开发比较快，后期随着功能的增长，交互的周期会越变越长的。
（3) 所有应用都在一个数据库上操作，数据库出现性能瓶颈。特别是数据分析跑起来的时候，数据库性能急剧下降。
(4) 开发、测试、部署、维护愈发困难。即使只改动一个小功能，也需要整个应用一起发布。
（5）技术栈受限。
针对传统的单体架构模式，这时候就出现了微服务。
1.2 微服务架构
维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
我的理解是
微服务是一种架构模式，叫微服务架构更合理，就是把一个系统中的各个功能点都拆开为一个个的小应用然后单独部署，每个服务运行于独立的进程，具备独立的业务能力。
特点：
（1）将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
（2）服务与服务之间互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中
（3）应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具(如Maven)对其进行构建。
优点：
- 单一职责原则；
- 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
- 开发简单，开发效率高，一个服务可能就是专一的只干一件事；
- 微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
- 微服务允许利用和融合最新技术；
- 微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库；
缺点：
- 开发人员要处理分布式系统的复杂性；
- 多服务运维难度，随着服务的增加，运维的压力也在增大；
- 系统部署依赖问题；
- 服务间通信成本问题；
- 数据一致性问题；
- 系统集成测试问题；
- 性能和监控问题；
二、Spring Cloud是什么？
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
简单来说，Spring Cloud是一个微服务框架的规范，注意，只是规范，他不是任何具体的框架。所以说SpringCloud是各个微服务架构落地技术的集合体,俗称微服务全家桶。
三、Spring Cloud 五大组件
- 服务注册与发现——Netflix Eureka
-
负载均衡：
- 客户端负载均衡——Netflix Ribbon
- 服务端负载均衡：——Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口)
- 断路器——Netflix Hystrix
- 服务网关——Netflix Zuul
- 分布式配置——Spring Cloud Config
1、Eureka
作用：实现服务治理（服务注册与发现）。
一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。
2、Ribbon
作用：主要提供客户侧的软件负载均衡算法。
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
3、Hystrix
断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调用操作。
为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
4、Zuul
作用：具有api网关，路由，负载均衡等多种作用。
类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。
5、Config
作用：配置管理。
SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。
四、Spring Cloud和Spring Boot的关系
（1）SpringBoot专注于开发,方便的开发单个个体微服务；
（2）SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务，整合并管理起来，为各个微服务之间提供：配置管理、服务发现、断路器、路由、为代理、事件总栈、全局锁、决策竞选、分布式会话等等集成服务；
（3）SpringBoot可以离开SpringCloud独立使用，开发项目，但SpringCloud离不开SpringBoot，属于依赖关系；
（4）SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架；
五、Spring Cloud和Dubbo的关系
（1）Dubbo是基于RPC调用的，而Spring Cloud是基于HTTP的REST方式，所以效率上是Dubbo更快。
（2）Dubbo的组件不是很齐全，他的很多功能比如服务注册与发现你需要借助于类似Zookeeper等组件才能实现，而Spring Cloud则是提供了一站式解决方案。
从使用广度来说，在国内几年前dubbo的使用人数远多于Spring Cloud的，但是近来Spring Cloud慢慢的有了后来居上的趋势。
