经典Java-SpringCloud面试题

1、 什么是微服务？

​ 微服务(Microservice Architecture) 是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
究竟什么是微服务呢？我们在此引用ThoughtWorks 公司的首席科学家 Martin Fowler 于2014年提出的一段话：
原文：https://martinfowler.com/articles/microservices.html
汉化：https://www.cnblogs.com/liuning8023/p/4493156.html

• 就目前而言，对于微服务，业界并没有一个统一的，标准的定义。
• 但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它体长将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值，服务之间采用轻量级的通信机制(HTTP)互相沟通，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应该根据业务上下文，选择合适的语言，工具(Maven)对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

再来从技术维度角度理解下：

• 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

2、微服务之间是如何独立通讯的？

1. 将组建定义为可被独立替换和升级的软件单元。
2. 以业务能力为出发点组织服务的策略。
3. 倡导谁开发谁运营的开发运维一体化方法。
4. RestFul Http协议是微服务架构中最常用的通讯机制。
5. 每个微服务可以考虑采用最佳微服务完成（如不同的编程语言）。
6. 允许不同的微服务采用不同的数据持久化技术。
7. 微服务非常注重建立架构和业务相关指标的实时监控和日志机制，必须考虑每个服务的失败容错机制。
8. 注重快速更新，因此系统会随着时间不断变化和演进。可替代性模块化设计。

微服务通信方式：

    同步：RPC，REST等
    异步：消息队列。要考虑消息可靠传输、高性能，以及编程模型的变化等。

1、客户端到服务端通信，API Gateway方法。

​ API Gateway是解决微服务通信的一个不错的方法。以客户端为例。一个客户端可以向多个微服务中的任意一个微服务发出请求。

​ API Gateway负责请求转发、合成和协议转换。所有请求都要先经过API Gateway，然后再将请求转发到对应的微服务中。

2、进程通信IPC

​ 这种通信不但可以实现一对一、一对多。还可以实现同步和异步请求。

3、SpringCloud 和 Dubbo有那些区别？

1、dubbo由于是二进制的传输，占用带宽会更少；

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大；

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题，很多大型工程无法解决；

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级；

5、dubbo的注册中心可以选择zookeeper、redis等多种，springcloud的注册中心只能用eureka或者自研。

4、 SpringBoot 和 SpringCloud，请谈谈你对他们的理解

1. Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；
2. Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；
3. spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。
4. Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot，属于依赖的关系。

5、什么是服务熔断？什么是服务降级？

来源地址：服务雪崩、降级与熔断

6、 微服务的优缺点分别是什么？说下你在项目开发中遇到的坑

百度百科

优点：

1. 服务的独立部署

   每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。

2. 服务的快速启动

   拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。

3. 更加适合敏捷开发

   敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。

4. 职责专一，由专门的团队负责专门的服务

   业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。

5. 服务可以动态按需扩容

   当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

6. 代码的复用

   每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

缺点：

1. 分布式部署，调用的复杂性高

   单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。

2. 独立的数据库，分布式事务的挑战

   每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。

3. 测试的难度提升

   服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。

4. 运维难度的提升

   在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。

7、你所知道的微服务技术栈有哪些？列举一二

8、Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两者的区别

1. ​ ZooKeeper保证的是CP,Eureka保证的是AP
2. ​ ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
3. ​ Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的，自我保护机制会导致Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务，Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
4. ​ 当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪
5. ​ ZooKeeper有Leader和Follower角色,Eureka各个节点平等
6. ​ ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
7. ​ Eureka本质上是一个工程,而ZooKeeper只是一个进程

各微服务框架对比

     | Spring Cloud Bus为我们的应用程序带来了更多管理端点           | 支持降级                                                     | Netflix内部在开发集成gRPC | IDL定义  | 实践的公司比较多                    |