在最近的面试中，经常被问到，除了SSM框架之外，还了解什么框架，瞬间就懵逼了，一把辛酸泪。
首先说说，什么是微服务架构那？
大约 2009 年开始，Netflix 完全重新定义了它的应用程序开发和操作模型，拉开了微服务探索的第一步，直到2014年3月 Martin Fowler 写的一篇文章 Microservices 以更加通俗易懂的形式为大家定义了什么是微服务架构。Martin Fowler 在文中阐述了对微服务架构的设想，认为微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。（英文看不懂的，可以去看一些博主的中文，https://blog.csdn.net/moonpure/article/details/79768621）
每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
再来聊聊 Spring Boot
Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。采用 Spring Boot 可以大大的简化开发模式，所有你想集成的常用框架，它都有对应的组件支持。
Spring Boot 基于 Spring 开发，Spirng Boot 本身并不提供 Spring 框架的核心特性以及扩展功能，只是用于快速、敏捷地开发新一代基于 Spring 框架的应用程序。也就是说，它并不是用来替代 Spring 的解决方案，而是和 Spring 框架紧密结合用于提升 Spring 开发者体验的工具。同时它集成了大量常用的第三方库配置（例如 Redis、MongoDB、Jpa、RabbitMQ、Quartz 等等），Spring Boot 应用中这些第三方库几乎可以零配置的开箱即用，大部分的 Spring Boot 应用都只需要非常少量的配置代码，开发者能够更加专注于业务逻辑。
Spring Boot 一经推出就受到开源社区的追捧，Spring Boot 官方提供了很多 Starters 方便集成第三方产品，很多主流的框架也纷纷进行了主动的集成，比如 Mybatis。Spring 官方非常重视 Spring Boot 的发展，在 Spring 官网首页进行重点推荐介绍，是目前 Spring 官方重点发展的项目之一。
Spring Boot 本身发展特别快，自从 2014 年 4 月发布 Spring Boot 1.0 之后，版本更新非常频繁，我在 2016 年使用的时候是 1.3.X，到现在 Spring Boot 已经发布了 Spring Boot 2.0，Spring Boot 2.0 集成了很多最新优秀的技术和新特性，并且对 Spring Boot 1.0 的 API 进行了大幅优化。Spring Boot 一经推出就迅速的成为一门热门的技术，从下图也可以看出这个结论：
上图为2014年到2018年 Spring Boot 的百度指数，可以看出 Spring Boot 2.0 的推出引发了搜索高峰。
Spring Boot 和 微服务架构
随着 Spring 不断的发展，涉及的领域越来越多，项目整合开发需要配合各种各样的文件，慢慢变得不那么易用简单，违背了最初的理念，甚至人称配置地狱。Spring Boot 正是在这样的一个背景下被抽象出来的开发框架，目的为了让大家更容易的使用 Spring 、更容易的集成各种常用的中间件、开源软件；另一方面，Spring Boot 诞生时，正处于微服务概念在慢慢酝酿中，Spring Boot 的研发融合了微服务架构的理念，实现了在 Java 领域内微服务架构落地的技术支撑。
Spring Boot 作为一套全新的框架，来源于 Spring 大家族，因此 Spring 所有具备的功能它都有，而且更容易使用；Spring Boot 以约定大于配置的核心思想，默认帮我们进行了很多设置，多数 Spring Boot 应用只需要很少的 Spring 配置。Spring Boot 开发了很多的应用集成包，支持绝大多数开源软件，让我们以很低的成本去集成其他主流开源软件。
Spring Boot 特性：
- 使用 Spring 项目引导页面可以在几秒构建一个项目
- 方便对外输出各种形式的服务，如 REST API、WebSocket、Web、Streaming、Tasks
- 非常简洁的安全策略集成
- 支持关系数据库和非关系数据库
- 支持运行期内嵌容器，如 Tomcat、Jetty
- 强大的开发包，支持热启动
- 自动管理依赖
- 自带应用监控
- 支持各种 IED，如 IntelliJ IDEA 、NetBeans
Spring Boot 的这些特性非常方便、快速构建独立的微服务。所以我们使用 Spring Boot 开发项目，会给我们传统开发带来非常大的便利度，可以说如果你使用过 Spring Boot 开发过项目，就不会再愿意以以前的方式去开发项目了。
总结一下，使用 Spring Boot 至少可以给我们带来以下几方面的改进：
- Spring Boot 使编码变简单，Spring Boot 提供了丰富的解决方案，快速集成各种解决方案提升开发效率。
- Spring Boot 使配置变简单，Spring Boot 提供了丰富的 Starters，集成主流开源产品往往只需要简单的配置即可。
- Spring Boot 使部署变简单，Spring Boot 本身内嵌启动容器，仅仅需要一个命令即可启动项目，结合 Jenkins 、Docker 自动化运维非常容易实现。
- Spring Boot 使监控变简单，Spring Boot 自带监控组件，使用 Actuator 轻松监控服务各项状态。
总结，Spring Boot 是 Java 领域最优秀的微服务架构落地技术，没有之一。
至于SpringCloud 、 消息队列是微服务架构的解决方案
2 Spring Cloud微服务架构
Spring Cloud是基于Spring Boot的一整套实现微服务的框架，因此它只能采用Java语言，这是它与其他几个微服务框架的最明显区别。Spring Cloud是一个包含了很多子项目的整体方案，其中由Netflix开发后来又并入Spring Cloud的Spring Cloud Netflix是Spring Cloud微服务架构的核心项目，即可以简单地认为Spring Cloud微服务架构就是Spring Cloud Netflix，后面我们用Spring Cloud时如果不特意声明，就是指Spring Cloud Netflix。
首先，Spring Cloud中的服务注册中心是Eureka模块，它提供了一个服务注册中心、服务发现的客户端，还有一个简单的管理界面，所有服务使用Eureka的服务发现客户端来将自己注册到Eureka中，如下所示为相关示意图，你会发现它很像之前第4章中的某个图。
那么Spring Cloud是如何解决服务的负载均衡问题的呢？由于Spring Cloud的微服务接口主要是基于REST协议实现的，因此它采用了传统的HTTP Proxy机制。如下图所示，Zuul类似一个Nginx的服务网关，所有客户端请求都通过这个网关来访问后台的服务。
Zuul从Eureka那里获取服务信息，自动完成路由规则的映射，无须手工配置，比如上图中的URL路径/customer/*就被映射到Customer这个微服务上。当Zuul转发请求到某个指定的微服务上时，会采用类似ZeroC IceGrid的客户端负载均衡机制，被称为Ribbon组件，下图给出了Zuul与Eureka的关系及实现服务负载均衡的示意图。
如下所示是Spring Cloud微服务架构平台的全景图。我们看到它很明显地继承了Spring Framework一贯的思路——集大成！
从图中来看，Spring Cloud 微服务架构平台集成了以下一些实际项目开发中常用的技术与功能模块。
基于Spring Security的OAuth模块，解决服务安全问题。
提供组合服务（Composite Services）的能力。
电路断路器 Hystrix，实现对某些关键服务接口的熔断保护功能，如果一个服务没有响应（如超时或者网络连接故障），则Hystrix可以在服务消费方中重定向请求到回退方法（fallback method）。如果服务重复失败，则Hystrix会快速失败（例如直接调用内部的回退方法，不再尝试调用服务），直到服务重新恢复正常。
监控用的Dashboard，可以简化运维相关的开发工作量。
总体来说，Spring Cloud是替代Dubbo的一种好方案，虽然Spring Cloud是基于REST通信接口的微服务架构，而Dubbo以RPC通信为基础。对于性能要求不是很高的Java互联网业务平台，采用Spring Cloud是一个门槛相对较低的解决方案。
3 基于消息队列的微服务架构
除了标准的基于RPC通信（以及类RPC的通信如Http Rest、SOAP等）的微服务架构，还有基于消息队列通信的微服务架构，这种架构下的微服务采用发送消息（Publish Message）与监听消息（Subscribe Message）的方式来实现彼此之间的交互。下图是这种微服务架构下各个组件之间的交互示意图，我们看到消息中间件是关键，它负责连通各个微服务与UI组件，担任了整个系统互联互通的重任。
基于消息队列的微服务架构是全异步通信模式的一种设计，各个组件之间没有直接的耦合关系，也不存在服务接口与服务调用的说法，服务之间通过消息来实现彼此的通信与业务流程的驱动，从这点来看，基于消息队列的微服务架构非常接近Actor模型。实际上，分布式的Actor模型也可以算作一种微服务架构，并且在微服务概念产生之前就已经存在很久了。下面是一个购物网站的微服务设计示意图，我们看到它采用了基于消息队列的微服务架构。
网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路，如下图所示，微服务之间通过RabbitMQ传递消息，实现通信。
与上面几种微服务架构相比，基于消息队列的微服务架构并不多，案例也相对较少，更多地体现为一种与业务相关的设计经验，各家有各家的实现方式，缺乏公认的设计思路与参考架构，也没有形成一个知名的开源平台。因此，如果需要实施这种微服务架构，则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台，其代价是成本高、风险大，因此决策之前需要架构师“接地气”地进行全盘思考与客观评价。
文中提到的RPC可以从知乎回答上了解一二：https://www.zhihu.com/question/25536695
本文主要从：https://www.cnblogs.com/ityouknow/p/9034377.html 。http://www.broadview.com.cn/article/348 等文章摘录整理