微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，
互相配置，为用户提供最终价值，服务之间采用轻量级的通信机制(HTTP)互相沟通，每个服务都围绕着具体的业务进行构建，并且能狗被独立的部署到生产环境中，另外，应尽
量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应该根据业务上下文，选择合适的语言，工具(Maven)对其进行构建，可以有一个非常轻量级的集中式管理来
协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
2.微服务之间是如何独立通讯的？同步（REST HTTP协议，RPC TCP 协议）
异步（消息中间件，例如Kafka、ActiveMQ、RabbitMQ、RocketMQ）
REST HTTP 协议（编写restful风格接口，调用接口）（springcloud使用REST通信）
REST 请求在微服务中是最为常用的一种通讯方式，它依赖于 HTTP\HTTPS 协议。RESTFUL 的特点是：
- 每一个 URI 代表 1 种资源
- 客户端使用 GET、POST、PUT、DELETE 4 个表示操作方式的动词对服务端资源进行操作：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT 用来更新资源，DELETE 用来删除资源
- 通过操作资源的表现形式来操作资源
- 资源的表现形式是 XML 或者 HTML
- 客户端与服务端之间的交互在请求之间是无状态的,从客户端到服务端的每个请求都必须包含理解请求所必需的信息
举个例子，有一个服务方提供了如下接口：
另外一个服务需要去调用该接口，调用方只需要根据 API 文档发送请求即可获取返回结果。
通过这样的方式可以实现服务之间的通讯。
RPC TCP 协议（客户端代理序列化方法和参数传入服务器，服务器代理解码方法和参数并执行方法，将结果再序列化传回去，客户端代理再解码结果得到结果）
两台机器是提供者和消费者，都要创建两个代理，消费者代理接受到需要远程调用提供者的提供的方法，
将方法和参数序列化，进行网络传输到提供者机器，之后提供者代理解码方法和参数，运行自己的方法，
将结果序列号，进行网络传输到消费者机器，之后消费者解码结果，就能远程使用提供者提供的方法了。
3.Dubbo 和 SpringCloud对比
dubbo之前停更过一段时间，之后继续更新，而springcloud在现阶段比较火一直在更新。
dubbo专注于RPC通信（通过服务器代理将方法参数序列号和解码的过程，不同的服务器调用对方的方法）
springcloud使用的是基于HTTP的REST方式
dubbo就是单独的一个功能组件，而springcloud提供了一站式解决分布式问题。
| | Dubbo | SpringCloud |
| ------ | ------------- | ---------------------------- |
| 服务注册中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netfilx Hystrix |
| 服务网关 | 无 | Spring Cloud Netfilx Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总栈 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
5.服务熔断，服务降级
服务熔断（提供者）
Hystrix解决服务雪崩的方案（服务熔断）：在不可用的服务中服务端给调用方返回备用响应，就可以继续运行调用之后的服务，就可以避免长时间的等待或抛出无法解决的异常，无法释放调用线程，导致服务雪崩
服务降级（消费者）
当某个时间段访问压力大，需要停掉不重要的某些功能（例如：广告。。），释放占用资源以保证主要核心重要业务能够顺利完成，而消费者调用这些不重要功能时，客户端会返回备用响应
6.微服务优缺点
优点
- 单一职责原则；
- 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
- 开发简单，开发效率高，一个服务可能就是专一的只干一件事；
- 微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
- 微服务能使用不同的语言开发；
- 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
- 微服务允许利用和融合最新技术；
- 微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库；
缺点
- 开发人员要处理分布式系统的复杂性；
- 多服务运维难度，随着服务的增加，运维的压力也在增大；
- 系统部署依赖问题；
- 服务间通信成本问题；
- 数据一致性问题；
- 系统集成测试问题；
- 性能和监控问题；
7.微服务技术栈有那些？
springcloud使用Eureka注册中心，Ribbon负载均衡， Feign接口调用服务，Hystrix （熔断机制，dashboard监控）， zuul路由网关，config连接git配置中心
| **微服务技术条目** | 落地技术 |
| -------------------- | ------------------------------------------------ |
| 服务开发 | SpringBoot、Spring、SpringMVC等 |
| 服务配置与管理 | Netfix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、PRC、gRPC |
| 服务熔断器 | Hystrix、Envoy等 |
| 负载均衡 | Ribbon、Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Fegin等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服务配置中心管理 | SpringCloudConfig、Chef等 |
| 服务路由(API网关) | Zuul等 |
| 服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全链路追踪 | Zipkin、Brave、Dapper等 |
| 数据流操作开发包 | SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息) |
| 时间消息总栈 | SpringCloud Bus |
| 服务部署 | Docker、OpenStack、Kubernetes等 |
8.Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两者的区别
作为分布式服务注册中心，Eureka比Zookeeper好在哪里？
CAP是什么?
- C (Consistency) 一致性
- A (Availability) 可用性
- P (Partition tolerance) 分区容错性
- 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
- 可用性（A）：不管什么时候访问，都可以正常的获取数据值。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
- 分区容忍性（P）：分区容错性指在遇到某节点或网络分区故障的时候，能够在其他的节点，访问到故障节点的内容（即通过拷贝，每个节点内容都是一样的）
CAP的三进二（只能保持两个同时实现，不能一起实现）：CA、AP、CP
因为在实现分布式时，必须考虑分区容忍性（P），因为节点随时会崩，需要集群实现，每个节点都拷贝相同的内容以保证内容一样，
不等待所有节点拷贝完成就使用，一致性（C）不能保证，因为一致性需要所有节点在任何时间访问的内容都必须一样，
等待所有节点拷贝完成才使用，可用性（A）不能保证，因为必须等待完成，在那个时间段不能使用
著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。
- Zookeeper 保证的是 CP —> 满足一致性，分区容错的系统，通常性能不是特别高
- Eureka 保证的是 AP —> 满足可用性，分区容错的系统，通常可能对一致性要求低一些
Zookeeper保证的是CP（网络问题导致master节点宕机，选举时间长，集群无法使用，无法保证可用性）
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30-120s，且选举期间整个zookeeper集群是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。
Eureka保证的是AP（网络有问题时触发自我保护机制，不会移除过期服务，同时能接受新服务，保证可用性，而不会同步到其他节点，无法保证一致性）
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
- Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
- 当网络稳定时，当前实例新的注册信息会被同步到其他节点中
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪
