1. 什么是微服务？
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务之间是松耦合的，同时微服务之间，通常是采用轻量级的基于 HTTP 的 RESTful API通信机制互相沟通，互相配合。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。
2. 微服务有什么特点？
(1).复杂度可控
在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
(2).独立部署
独立部署由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
(3).技术选型灵活
微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，所以需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。
(4).容错
当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
(5).扩展
单块架构应用也可以实现横向扩展，当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
3. Spring Boot / Cloud 都做了那些事情?
(1).什么是 Spring Boot？
Spring Boot使用了特定的方式来进行配置，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程，从而使开发人员不再需要定义样板化的配置. Spring Boot 不是什么新的框架，它默认配置了很多框架的使用方式，Spring Boot 简化了基于 Spring 的应用开发，通常我们想要集成的常用框架，它都有对应的组件支持，通过少量的代码就能创建一个独立的、产品级别的 Spring 应用.
Spring Boot的核心功能 :
(1) 起步依赖
SpringBoot工程继承spring-boot-starter-parent后已经具备版本锁定等配置了，然后对于我们需要的某种功能添加起步依赖，起步依赖会进行依赖的传递，这些依赖组合在一起即支持某项功能。 简单的说，起步依赖就是将具备某种功能的坐标打包到一起，并提供一些默认的功能。
Spring Boot配置文件的加载：
传递依赖时会依次从resources目录下加载application.yml和application.properties配置文件。
(2).自动配置
Spring Boot的自动配置是一个运行时（更准确地说，是应用程序启动时）的过程，考虑了众多因素，才决定 Spring配置应该用哪个，不该用哪个。该过程是Spring自动完成的。
SpringBoot可以简化开发的一个主要原因就是采用了默认配置，所谓约定大于配置就是这个意思。在没有自己指定配置的时候使用默认配置的原理，如若需要更改配置，则需要在application.properies或者application.yml配置中添加对应属性。
Spring Boot自动配置运行原理：
(1). SpringBoot项目运行类启动，就是添@SpringBootApplication注解的类。
先看@SpringBootApplication
- @SpringBootConfiguration：标记当前类为主配置类
- @EnableAutoConfiguration：开启自动配置
- @ComponentScan：扫描主类所在的同级包以及下级包里的被注解的Bean
(2).自动配置的核心功能是由@EnableAutoConfiguration这个注解提供的。
@Import(AutoConfigurationImportSelector.class)导入的配置功能，
AutoConfigurationImportSelector里有一个selectImports方法，这个方法里有一个configurations，返回的configurations对象中包含待配置的class的类名集合。
在方法里调用了getCandidateConfigurations方法, 而这个方法里又调用了SpringFactoriesLoader下的loadFactoryNames方法, loadFactoryNames方法会扫描META-INF/spring.factories文件, 这文件列出了哪些需要自动配置。
但是自动配置类是否会被自动配置，还需要满足类上边注明的条件判断注解。
这里使用非常常用的DataSourceAutoConfiguration类来做例子讲解一下自动配置的流程。首先进入这个类，可以上面的几个注解。简单介绍一下这几个注解的作用。
@Configuration注解：声明此类为配置类。
@ConditionalOnClass注解：判断classpath下是否存在后面指定的类，因为我这里没有引入对应的类，所以会报红，所以这个自动配置也并没有生效。
@EnableConfigurationProperties注解：启用ConfigurationProperties功能，这个注解后面指定的类就是需要映射属性到配置文件的属性类。这里的配置文件是指application.properties文件.(如若要修改默认配置，可在此配置文件添加自定义属性和值得键值对)
@Import注解：数据库配置相关的类，有的自动配置类时没这个注解的，比如RedisAutoConfiguration类，所以这个看具体情况，但是前面三个注解是必须的。
附：常见org.springframework.boot.autoconfigure.condition包下的条件注解意思
@ConditionalOnBean：当容器里有指定的bean的条件下。
@ConditionalOnMissingBean：当容器里不存在指定bean的条件下。
@ConditionalOnClass：当类路径下有指定类的条件下。
@ConditionalOnMissingClass：当类路径下不存在指定类的条件下。
@ConditionalOnProperty：指定的属性是否有指定的值，比如@ConditionalOnProperties(prefix=”xxx.xxx”, value=”enable”, matchIfMissing=true)，代表当xxx.xxx为enable时条件的布尔值为true，如果没有设置的情况下也为true。
Spring Boot的使用：
(1). 创建一个maven工程，该工程为普通的java工程即可。
(2). SpringBoot要求项目要继承SpringBoot的起步依赖spring-boot-starter-parent
(3). 提供SpringBoot引导类。
(4). 在引导类同级包或者子级包中创Controller类。
(2).什么是Spring Clound？
Spring Cloud 是一系列框架的有序集合，它是基于Spring Boot实现的微服务架构开发工具，并且为微服务中设计的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策精选、分布式会话和集群状态管理等操作提供了一套简单的开发方式，这些操作都可以用 Spring Boot 的开发风格做到一键启动和部署。
Spring Cloud 原理详解及核心组件使用：
推荐博文:https://blog.csdn.net/qq_41701956/article/details/83829539
4.微服务、Springboot、Springcloud他们三者之间又有什么关系?
(1).微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。
(2).Spring Boot 是一套快速配置脚手架，可以基于 Spring Boot 快速开发单个微服务。
(3).Spring Cloud基于 Spring Boot 实现服务治理工具包;Spring Boot 专注于快速、方便集成的单个微服务个体;Spring Cloud 关注全局的服务治理框架。Spring Boot / Cloud 是微服务实践的最佳落地方案。
Spring Cloud 和Dubbo分布式架构的对比.
(1).从两个公司的背景来谈
Dubbo是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司;Spring Cloud 是大名鼎鼎的 Spring 家族的产品。阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。Spring 专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架是他们的主业。
(2).从社区活跃度这个角度来对比
Dubbo 虽然也是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比 Spring Cloud 还好，除过当当网在此基础上增加了 rest 支持外，已有两年多的时间几乎没有任何更新了。在使用过程中出现问题，开发者提交到 GitHub 的 Issue 也少有回复。相反 Spring Cloud 自从发展到现在，仍然在不断的高速发展。从 GitHub 上提交代码的频度和发布版本的时间间隔就可以看出，现在 Spring Cloud 即将发布 2.0 版本，到了后期会更加完善和稳定。
(3).从整个大的平台架构来讲
Dubbo 框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。Spring Cloud 几乎考虑了服务治理的方方面面，更有 Spring Boot 的支持，开发起来非常的便利和简单。
(4).从技术发展的角度来讲
Dubbo 刚出来的那会技术理念还是非常先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益不少。经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo 一直停滞不前，自然有些掉队，有时候我个人也会感到有点可惜，如果 Dubbo 一直沿着当初的那个路线发展，并且延伸到周边，今天可能又是另一番景象了。
(5).两者使用特点
首先springcloud对比dubbo，最大的特点之一就是使用Restful的模式进行交互，dubbo是基于RPC进行通信的，而Restful是基于Http协议进行的，从协议的角度上来说Http和RPC都是基于TCP进行研发的协议，Http是最广泛的，不仅支持浏览器还支持各种APP通信，这么来说吧Http就是大家都在用的协议，而RPC是针对某一个平台某一个环节针对性开发的自定义协议，Http由于大众化，所以本身协议会有点笨重，解析起来自然也比RPC要慢，这也是RPC的优势之一，但是Http具有良好的跨平台性质
微服务 vs 传统开发
1.分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。
2.架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。
3.部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。
4.容灾不同，好的微服务可以隔离故障避免服务整体 down 掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。
5.给数据库带来的挑战
每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理?这是大家普遍遇到的一个问题。
有如下三种处理方案：
(1).严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。
(2).将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库各种切换导致后台统计难以实现，是一个折中的方案。
(3).数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用 Mongodb、Hbase 等。
第一种方案适合业务较为简单的小公司;第二种方案，适合想在原有系统之上，慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。
原文地址：https://www.cnblogs.com/loewe007/p/10307626.html