1.什么是微服务?

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

2.微服务之间是如何建立通讯的?

1.HTTP RESTFul RestTemplate(Spring提供的用于访问Rest服务的客户端)
2.Feign(是Netflix开发的声明式、模块化的HTTP客户端,Feign可帮助我们更好更快的便捷、优雅地调用HTTP API)

3.Spring Cloud和Dubbo有哪些区别?

Dubbo的通信是通过rpc建立的，SpringCloud通过RESTful建立的

4.SpringCloud和Spring Boot谈谈你对他们的理解

  1. Spring Boot 是 Spring 的⼀套快速配置脚⼿架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是⼀个基于Spring Boot实现的云应⽤开发⼯具；
  2. Spring Boot专注于快速、⽅便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架；
  3. Spring Boot使⽤了默认⼤于配置的理念，很多集成⽅案已经帮你选择好了，能不配置就不配置；
  4. Spring Cloud很⼤的⼀部分是基于Spring Boot来实现，可以不基于Spring Boot吗？不可以。

5.什么是服务熔断？什么是服务降级?

服务熔断
一般是某个服务故障或异常引起，类似于现实世界的保险丝，当某个异常条件被触发是，直接熔断整个服务，而不是一直等到服务超时
服务降级
所谓降级，一般是从整体负荷考虑的，当某个服务熔断后，服务器将不再被调用
此时客户端可以准备一个fallback回调，返回一个缺省值
这样所，服务可用，比起全部服务直接挂掉要好

6.微服务的优缺点？说下你在项目中碰到的问题

优点:
每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点:
开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控……

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

多种技术的集合体

微服务条目

落地技术

备注

服务开发

Springboot、Spring、SpringMVC

服务配置与管理

Netflix公司的Archaius、阿里的Diamond等

服务注册与发现

Eureka、Consul、Zookeeper等

服务调用

Rest、RPC、gRPC

服务熔断器

Hystrix、Envoy等

负载均衡

Ribbon、Nginx等

服务接口调用(客户端调用服务的简化工具)

Feign等

消息队列

Kafka、RabbitMQ、ActiveMQ等

服务配置中心管理

SpringCloudConfig、Chef等

服务路由（API网关）

Zuul等

服务监控

Zabbix、Nagios、Metrics、Spectator等

全链路追踪

Zipkin，Brave、Dapper等

服务部署

Docker、OpenStack、Kubernetes等

数据流操作开发包

SpringCloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息）

事件消息总线

Spring Cloud Bus

8.eureka和zookeeper都可以提供服务注册与发现的功能，请说说两者的区别?

作为服务注册中心，Eureka比Zookeeper的区别在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP
Eureka则是AP

1.Zookeeper保证CP
当向注册中心查询服务列表时，用户可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

2 Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

9.微服务架构风格?

一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都运行在自己的进程中，并与轻量级开发(RESTful风格开发)进行通信

10.分布式系统?

各个模块/服务，各自独立出来
各自微小的进程
独立部署
三个重要的组成部分
1.拆分
2.各自独立的进程
3.拥有自己独立的数据库