-
什么是微服务？
微服务，又称微服务架构，是一种架构风格，它将应用程序构建为以业务领域为模型的小型自治服务集合。简单来说就是把一个项目拆分成独立的多个服务，并且多个服务是可以独立运行的，而每个服务都会占用线程。
-
微服务之间是如何进行通信的？
同步通信方案：对外REST，对内RPC。
异步通信方案：消息队列；后端接口实现幂等性。
-
SpringBoot和dubbo有哪些区别？
SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。
Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。
-
SpringBoot和SpringCloud的理解
SpringBoot是一个快速开发的轻量级框架，帮助快速整合第三方常用框架，完全采用注解化（使用注解启动SpringMVC），简化XML配置，内置HTTP服务器（Tomcat、Jetty）。作用是简化Spring应用的初始搭建及开发，解决各种jar包版本冲突问题。
SpringCloud是一系列框架的有序集合，是一个分布式服务治理的框架，本身不会提供具体功能性的操作，是一个为开发者提供快速构建分布式系统的工具。简化了分布式系统基础设施的开发，包括服务发现、服务注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
联系：
SpringBoot+SpringCloud实现微服务开发。具体就是，SpringCloud具备微服务开发的核心技术：RPC远程调用技术；SpringBoot的web组件默认集成了SpringMVC，可以实现HTTP+JSON（Restfull）的轻量级传输，编写微服务接口，所以SpringCloud是依赖SpringBoot框架实现微服务开发。
区别：
SpringBoot专注于快速开发单个微服务，SpringCloud是将SpringBoot开发的一个个单体微服务整合并管理起来，它是关注全局的服务治理框架（RPC远程调用技术、服务治理等）；
SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系。
-
什么是服务熔断，什么是服务降级？
服务熔断：类似于家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
服务降级：服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
相同点：
目标一致：都是从可用性和可靠性出发，为了防止系统崩溃；
用户体验类似：最终都让用户体验到的是某些功能暂时不可用；不同点：
触发原因不同：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
-
微服务的优缺点是什么
优点：
开发简单、开发效率提高，一个服务可能就是专一的只干一件事；
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工；缺点：
开发人员要处理分布式系统的复杂性；多服务运维难度，随着服务的增加，运维的压力也在增大
系统部署依赖；服务间通信成本；数据一致性；系统集成测试 -
微服务的技术栈
-
Eureka和Zookeeper的区别
CAP原则：又称 CAP 定理，1998年，加州大学的计算机科学家 Eric Brewer 提出的，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得（我们常说的鱼和熊掌不可兼得）。CAP 原则也是 NoSQL 数据库的基石。
1、一致性（Consistency，C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。
2、可用性（Availability，A）：在一个分布式系统的集群中一部分节点故障后，该集群是否还能够正常响应客户端的读写请求。（对数据更新具备高可用性）。
3、分区容错性（Partition tolerance，P）：大多数的分布式系统都分布在多个子网络中，而每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。在一个分布式系统中一般分区容错是无法避免的，因此可以认为 CAP 中的 P 总是成立的。CAP 理论告诉我们，在 C 和 A 之间是无法同时做到。
ZooKeeper 基于 CP，不能保证高可用，Eureka 基于AP，能保证高可用。作为注册中心而言，配置是不经常变动的，只有当新版本发布或者服务器出故障时会变动。CP 不合适于配置经常变动的，而 AP 在遇到问题时可以牺牲其一致性来保证系统服务的高可用性，既返回旧数据。在实际生产环境中，选择 Zookeeper 还是选择 Eureka ，这个就要取决于系统架构师对于业务环境的权衡了。