1、Spring boot 是 Spring （AOP和IOC）的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务；
Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Cloud是多个Spring boot微服务的集合，当然不是简单的集合，那么就涉及到微服务的七大原则：
1）、围绕业务概念建模
经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。使用限界上下文来定义可能的领域边界。
2）、接受自动化文化
微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期花费一定的成本，构建支持微服务的工具是很有意义的，比如：自动化测试，调用一个统一的命令行，以相同的方式把系统部署到各个环境；使用环境定义来帮助你明确不同环境间的差异，同时保持使用统一的方式进行部署；创建自定义镜像来加快部署，创建全自动化不可变服务器。
3）、隐藏内部实现细节
为了使一个服务独立于其他服务，最大化独立演化的能力，隐藏实现细节至关重要。隐藏服务的数据库，以避免陷入数据库耦合；使用数据泵（data pump）或事件数据泵（event data pump）,将跨多个服务的数据整合到一起，以实现报表功能。
4）、让一切都去中心化
为了最大化微服务能带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。
在这个旅程中，确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过请注意，实现这种模式需要很多的工作量。
像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来代替编排或哑中间件，使用智能终端点（smart endpoint）确保相关的逻辑和数据，在服务限界内能保持服务的内聚性。
5）、可独立部署
我们应当始终努力确保微服务可以独立部署。我们也应该同时提供新旧两个版本，允许消费者慢慢迁移到新版本。当使用基于RPC的集成时，避免使用像Java RMI提供的那种使用生成的桩代码，紧密绑定客户端/服务器的技术。
通过采用单服务单主机模式，可以减少部署一个服务引发的副作用，比如影响另一个完全不相干的服务。请考虑使用蓝/绿部署或金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕获它们。
请记住，你可以更改单个服务，然后把它部署到生产环境，无需联动地部署其他任何服务，这应该是常态，而不是例外。你的消费者应该自己决定何时更新，你需要适应他们。
6）、隔离失败
微服务架构比单块架构更具弹性，前提是我们了解系统的故障模式，并做出相应的计划。
如果我们心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的路上。请确保正确设置你的超时，了解何时及如何使用舱壁和断路器，来限制故障组件的连带影响。如果系统只有一部分行为不正常，要了解其对用户的影响。知道网络分区可能意味着什么，以及在特定情况下牺牲可用性或一致性是否是正确的决定。
7）、高度可观察
我们不能依靠观察单一服务实例，或一台服务器的行为，来看系统是否运行正常。相反，我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真实用户的行为，从而使用语义监控来查看系统是否运行正常。聚合你的日志和数据，这样当你遇到问题时，就可以深入的解析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你跟踪系统间的调用。
2、Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；
Spring Cloud的5个经常用组件：
服务发现——Netflix Eureka； 作用：实现服务治理（服务注册与发现）
客服端负载均衡——Netflix Ribbon； 作用：Ribbon，主要提供客户侧的软件负载均衡算法。
断路器——Netflix Hystrix； 作用：断路器，保护系统，控制故障范围。
服务网关——Netflix Zuul； 作用：api网关，路由，负载均衡等多种作用
分布式配置——Spring Cloud Config ； 作用：配置管理；
3、spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring
boot来实现。
4、Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot，属于依赖的关系。