微服务架构SpringCloud的理解

微服务架构是什么？

微服务是一种架构思想，实际上以分布式系统方式开发。架构是为了解耦。该架构解决的是分布式中的四个问题：

一、客户端如何访问众多服务；

应用划分为众多服务以后，客户端需要如何访问？
通过统一的API网关入口解决，其作用如下：
•提供统一服务入口，让微服务对前台透明
•聚合后台的服务，节省流量，提升性能
•提供安全，过滤，流控等API管理功能

二、服务之间如何通信；

对内RPC，对外REST，kafka, 消息队列。

三、服务之间如何发现；

Eureka

四、服务挂了如何处理。

•重试机制 - 针对网络不可靠的问题
•限流 - 针对流量太大处理不过来
•熔断机制 - 一定时间无响应就不再连接
•负载均衡 - 针对高并发情况
•服务降级（本地缓存） - 保证核心服务可用，临时下线不必要的业务

微服务架构的优点和缺点有哪些？

一、优点

可用于解决复杂的业务问题；
独立部署，可持续集成；
方便扩展，提高可用性；
业务拆分，方便复用，适合多团队开发；

二、缺点：

运维复杂；
数据一致性难以保证；
服务拆分后，不同业务模块服务之间的通信增加了时延。

SpringCloud是什么?

SpringCloud它制定了微服务、分布式系统框架的规范,它集成了微服务落地需要的一系列框架，如配置管理、服务发现、熔断器、网关,负载均衡等。
它包含服务注册与发现：eureka,负载均衡：Ribbon,服务熔断器：hystrix,服务配置中心管理:spring cloud config,服务接口调用：Feign ,服务路由：Zuul等。

Eureka

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注
册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

Eureka自我保护机制

当eurekaserver短时间丢失了过多的实例连接（由于网络故障或者频繁地启动关闭客户端），那么eureka就是进入自我保护机制。一旦进入该模式，eureka就会保护服务注册表中的信息，不会删除任何服务注册表中的数据。这是一种应对网络异常的安全保护措施。

负载均衡如何起作用？

负载均衡就是有多台服务器，将外部请求均匀地分布到这些服务器上。这样便能合理均匀地管理负载！负载均衡的策略有随机策略，轮询策略，重试策略等。在服务消费者的RestTemplate加入注解@LoadBalanced，便可以使用负载均衡，提供Ribbon的支持。除了使用默认的负载均衡策略外，我们还可以使用自行选择负载均衡策略。

什么是 Hystrix？它如何实现容错？

Hystrix是服务熔断，相当于电力中的“断路器”。因为服务之间通过远程调用实现信息交互，那么当某个服务的响应太慢或者故障，又或者因为网络波动或故障，则会造成调用者延迟或调用失败，当大量请求到达，则会造成请求的堆积，导致调用者的线程挂起，从而引发调用者也无法响应，调用者也发生故障。
微服务架构中的熔断器，就是当被调用方没有响应，调用方直接返回一个错误响应即可，而不是长时间的等待，这样避免调用时因为等待而线程一直得不到释放，避免故障在分布式系统间蔓延。
Hystrix是一种服务保护机制，避免了单个调用的微服务导致全局”雪崩”。同时Hystrix 通过服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等方式容错处理。
Hystrix是引入在服务消费者中的。在服务消费者的入口类添加注解@EnableCircuitBreaker，开启断路器的功能。在调用远程服务的方法上添加注解：@HystrixCommand(fallbackMethod="error")，就能实现远程服务的服务熔断功能了。实际上我们也可以自定义服务熔断的方法。

Feign是什么？

Feign 整合了 Ribbon 和 Hystrix 两个组件，Spring Cloud Feign对 Ribbon 负载均衡、Hystrix 服务熔断进行简化，在其基础上进行了进一步的封装，不仅在配置上大大简化了开发工作，同时还提供了一种声明式的 Web 服务客户端定义方式。

分布式系统的CAP理论和BASE理论

CAP定理是什么？

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
一致性
更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
这里是强一致性，要不一起成功，要不一起失败！
可用性
服务一直可用，而且是正常响应时间。
分区容错性
分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
比如深圳机房和上海机房，上海机房无法使用的话深圳机房还可以用（这也叫异地多活）

BASE理论是什么？

BASE 理论是对 CAP 理论的延伸，支持大型分布式系统。核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
基本可用(Basically Available)
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务（如取消注册服务、聊天服务）。这就是损失部分可用性的体现。
软状态(Soft State)
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
最终一致性(Eventual Consistency)
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。