Spring Boot 简介
Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者
特点：
- Spring Boot可以建立独立的Spring应用程序；
- 内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作了。
- 无需再像Spring那样搞一堆繁琐的xml文件的配置；
- 可以自动配置Spring；
- 提供了一些现有的功能，如表单数据验证以及一些外部配置这样的一些第三方功能；
- 提供的POM可以简化Maven的配置；
- 非常简洁的安全策略集成
- Spring Boot 使监控变简单，Spring Boot 自带监控组件，使用 Actuator 轻松监控服务各项状态。
- Spring Boot 使部署变简单，Spring Boot 本身内嵌启动容器，仅仅需要一个命令即可启动项目，结合 Jenkins 、Docker 自动化运维非常容易实现。
- Spring Boot 使配置变简单，Spring Boot 提供了丰富的 Starters，集成主流开源产品往往只需要简单的配置即可。
Spring Cloud 简介
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud 和 Spring Boot 的对比区别：
- Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务；Spring Cloud是一个基于Spring Boot实现的云应用开发工具；
- Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；
- spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。
- Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot，属于依赖的关系。
Spring Boot 是单体应用，包含实现所有功能的程序，但是Spring Cloud是分布式微服务应用。
下面是Spring Cloud的一张全景图，Spring Cloud = Spring Boot + 分布式组件（不知道这样等号合不合适）
（来自https://blog.csdn.net/fan521dan/article/details/104955600）
单体架构与分布式微服务架构的对比：
单体架构：
通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、EXE、BIN或其它归档格式。
Spring Boot 完整的部署了一个项目，项目所有功能都在单个项目中做了实现。
单体架构的优点
- 便于开发：只需借助IDE的开发，调试功能即可完成，开发简单直接，集中式管理, 基本不会重复开发
- 易于测试：只需要通过单元测试或浏览器即可完成测试
- 易于部署：打包成单一可执行jar包或者war包，执行包即可完成部署
- 功能都在本地，没有分布式的管理开销和调用开销
单体架构的缺点
- 复杂性高，如果业务很复杂，代码维护难，代码功能耦合在一起，新人不知道何从下手
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目
- 扩展能力受限，伸缩性差（系统运行在单个服务器上，比较难扩展，无法满足高并发情况下的业务需求）
- 代码难以被修改和重构,因为单体架构代码耦合度会比较高
- 不利于多人开发，容易发生冲突
- 单点故障问题，一旦某个功能挂了，所有功能都无法使用
单体架构的适用场景
- 单个团队维护的业务功能简单的系统（性能要求不高，单个服务器也能负载）
微服务架构
Spring Cloud属于分布式微服务架构。微服务架构风格是一种将一个单一应用程序拆分为许多小型服务的方法，这样一来，每个小开发团队单独维护一个小型服务的运行（提升每个团队的专注度，服务间的交互由团队间协商决定），便于团队协作，同时避免了单点故障问题。
每个服务运行在自己的进程中，所有微服务独立运行，共同构建起整个系统，服务间通信采用轻量级通信机制(通常用HTTP传送JSON数据完成进程间的通信，REST API)。
这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务采用集中式的管理，每个服务可用不同的语言开发，使用不同的数据存储技术，从而达到异构。
微服务的优点
- 单个拆分出来的微服务更加容易开发、维护
- 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署，并且单个拆分出来的微服务启动较快
- 并且修改某个微服务的时候，只用重新部署单个服务，比较容易部署
- 技术栈不受限，多个服务可以分别使用不同的技术，只需要保证服务交互正常就行
- 按需伸缩，便于添加服务器提高性能（因为本来就是分布式的）
- 扩展性高，我们需要什么功能直接增加服务就好了
- 容错性能好：单个服务出了故障，那么bug也会仅仅停留在某个服务中，不会影响其他服务的正常使用。
微服务的缺点
- 微服务架构带来过多的运维操作, 可能需要团队具备一定的 DevOps 技巧.
- 分布式系统可能复杂难以管理。因为分布部署跟踪问题难。当服务数量增加，管理复杂性增加。
微服务的适用场景
- 大型、复杂的项目
- 有快速迭代的需求
- 访问压力大
微服务拆分：
- 职责划分（按照业务功能做划分，比如专门维护支付功能业务或者专门维护秒杀业务，通过功能的不同来划分业务）
- 通用性划分（将通用的东西专门划分出去，比如分布式系统里面的配置中心专门用来维护多个机器使用的配置，存储系统专门使用IO性能比较好的服务器来部署存储业务）
微服务拆分粒度：
需要大家协商，一个是功能发生变化的时候，不会影响到过多相关功能的改变（一般拆分出来的一个服务是不会影响到另一个服务的，面向接口设计，但是同一个业务里面功能会耦合高一些，服务拆的太细，管理不太方便，拆的太粗，功能发生改变的时候会比较麻烦，需要改动很多地方，避免出现意想不到的BUG）
刚开始编写系统的时候，可以不用规划那么细，计划赶不上变化，所以可以等一个业务功能涉及太多的时候，再将这个业务进行拆分。毕竟一口吃不成一个胖子。
References:
- https://www.cnblogs.com/money131/p/10659223.html
- https://baike.baidu.com/item/Spring%20Boot/20249767?fr=aladdin
- https://baike.baidu.com/item/spring%20cloud
- https://blog.csdn.net/fan521dan/article/details/104955600
- https://blog.csdn.net/mn_kw/article/details/80499016
- https://blog.csdn.net/kunyus/article/details/90670710
（写博客主要是对自己学习的归纳整理，资料大部分来源于书籍、网络资料和自己的实践，整理不易，但是难免有不足之处，如有错误，请大家评论区批评指正。同时感谢广大博主和广大作者辛苦整理出来的资源和分享的知识。）