1、为什么需要使用微服务？
如果采用微服务架构模式，则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处：
- 敏捷开发：由于每个服务都是独立并且微小的，由单独的团队负责，可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。
- 独立部署：每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。
- 开发维护方便：整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。
- 负载均衡：一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。
- 突破单数据库性能瓶颈 : 每个服务都有自己的数据库模式，而不是共享单个数据库模式。
2、微服务拆分服务的原则是什么？
拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个的其他服务或客户端提供数据，那
- 单一职责、高内聚低耦合：简单来说一张表划分为一个服务
- 服务粒度适中：服务不要太细（有的团队甚至一个接口一个服务）
- 以业务模型切入：比如产品，用户，订单为一个模型来切入
- 演进式拆分：刚开始不要划分太细，可以随着迭代过程来逐步优化
- 避免环形依赖与双向依赖：尽量不要做服务之间的循环依赖
3、微服务都有使用过哪些组件？各个组件的作用是什么？使用的场景有哪些？
- eureka（注册中心） 所有的微服务模块统一到注册中心注册，生成注册表，进行统一管理。eureka既可以是生产者，也可以是消费者。当然也可以搭建集群，如果其中一个eureka崩了，也不会影响其他微服务的使用，提高系统的性能。
- ribbon（负载均衡）ribbon最牛的地方RoundRobinRule轮询算法，默认的是每个服务按顺序请求一次。服务之间也需要进行通信，可以采用http或rpc(远程过程调用)。可以采用RestTemplate，RestTemplate内部封装了http，返回object，使用更方便快捷。
- zuul（网关）通俗的讲，是一个关口，想让哪些东西通过就可以通过，不想让哪些东西通过就不能通过。当请求从客服端发到服务器，如果经过网关的一系列验证和过滤符合访问要求，那么在之后访问其他微服务或由网关路由转发之后的访问时，不需要再做同样的安全认证。
- Hystrix（熔断器）简单来说，相当于电路中的保险丝。举个例子说明下熔断器的用途。商品下单会调用订单服务，然后订单服务会通知仓库服务发货、订单服务通知积分服务给用户新增积分。如果积分服务挂了，每次订单服务请求积分服务线程会等待几秒钟然后返回一个异常。如果做秒杀的时候，大量的订单服务线程卡在积分服务这里，然后订单服务也挂了，完犊子，雪崩，整个服务炸了。如果第一次请求积分服务的时候发现它挂了，就不在管他，各服务都做它该做的事。这时就会用到Hystrix。最后积分服务进行降级处理，给用户一个提示，积分服务出现异常，待人工核实后添加积分。大不了最后积分服务恢复后人工进行积分处理，不影响整个服务的使用。Hystrix里面有个性能非常好，如果发现积分服务挂了，Hystrix自动打开，一段时间后，Hystrix会半开，放一个请求过积分服务，问问积分服务怎么样了，如果积分服务还挂着，Hystrix就继续打开，一旦积分服务请求成功，Hystrix自动关闭。（Hystrix小伙子是真的不错，让人也太省心了）
4、服务之间调用使用的什么组件？能说一下原理吗？
采用Springcloud的核心组件之Feign 进行调用
5、使用微服务部署，服务雪崩如何处理？
服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。
造成服务雪崩的原因有很多，包括硬件原因，网络原因，软件原因等等。软件方面，解决服务雪崩的几种解决方案如下：
- 超时：造成线程的挤压都是因为同步远程调用长时间没有得到回复造成的，所以设置超时时间，可以减少线程的长时间占用，避免线程挤压。
- 限流：对服务进行限流，避免服务因并发量过大而造成服务崩掉。
- 熔断：对已经挂掉的服务，直接不再进行调用，而是直接返回结果，这就是熔断。以此避免已经挂掉的服务对调用者造成的影响。
- 隔离：分为进程隔离，线程隔离和信号量隔离。隔离机制的本质就是将服务调用的粒度划分的更小，以此来减少服务生产崩溃而对服务调用带来的影响，避免服务雪崩现象产生。