微服务复习

分布式解决方案

XA规范：分布式事务规范，定义了分布式事务模型

四个角色：事务管理器(协调者TM),资源管理器(参与者RM),应用程序AP，通信资源管理器（crm）

每次begin事务开始之后commit事务结束进行一个事务，在commit之前做一个发送其他节点通信的操作，给每一个rm一个txid，单节点的话sql没问题就提交

第一个阶段：每个参与者执行本地事务但不提交，进入ready状态，并通知协调者已经准备就绪

第二个阶段：当协调者确认每个参与者ready后，通知参与者进行commit操作，如果有参与者fail，则发送rollfack命令，各参与者做回滚

第三个阶段：主要是针对两阶段的优化，解决了2pc单点故障的问题，但是性能问题和不一致问题仍然没有根本解决，如果挂掉的话各自有各自的超时机制，然后执行这个提交动作，不会一直阻塞在这里

出现问题

单点故障：一旦事务管理器出现故障，整个系统不可用

数据不一致，响应时间长，不确定性

tcc

springcloud熔断策略？

通过后台配置，配置到每一个接口，能够支持到每一个接口的案例，每个案例的每个接口降级，配置一个开关，没次新增一个案例就添加一个案例，目前没有实现自动化。

springboot是怎么做到简化配置的？

主要是@EnableAutoConfiguration这个注解起的作用，这个注解是间接隐藏在springboot的启动类注解@SpringBootApplication中。

通过这个注解，SpringApplication.run(…)的内部就会执行selectImports()方法，寻找 META-INF/spring.factories文件，读取里面的文件配置，将事先已经写好的自动配置类有选择地加载到Spring容器中，并且能按照约定的写法在application.properties中配置参数或开关。

为什么要用 Dubbo？

随着项目需要使用的服务越来越多，服务之间的关系也越来越复杂，于是对这些服务也因此衍生出了一系列相应的技术，比如服务提供，服务调用，连接处理，通信协议，服务发现，服务路由，日志输出等行为，需要把这些技术进行封装和管理这些技术，所以dubbo就出现了

springcloud和dubbo的区别？

它们两个的底层原理都是类似的，dubbo中的二进制性能比http的性能更好一些，他俩底层都是rpc，经过深度优化的RPC框架对于性能和处理并发能力是更好一些的，但是现在很多中小型企业而言dubbo一次请求10ms，springCloud请求一次是20ms，对很多中小型公司而言，性能，并发不是最主要的因素，而springCloud这套架构原理，走http接口和http请求，就足够性能和并发的需求了，没必要使用高度优化的rpc服务框架

springCloud安全性相对比dubbo安全性高一些

dubbo最开始的一个定位只是单纯的一个服务框架而已，类似配置网关这种还得选择一些其他技术不提供其他的功能

而springclod这个框架中小型公司用的特别多，它主打的微服务架构，组件齐全，功能齐全，网关直接提供，分布式配置中心，

授权认证，服务调用链路追踪，资源隔离，熔断降级，服务请求qps监控，契约测试，zk封装

用springCloud优势在于功能齐全，中小型公司开箱即用，直接满足系统中的开发需求

springCloud配置消费者提供者直接通过注解就可以实现配置，而dubbo是需要在xml里面进行配置消费者和提供者

springcloud组件有哪些？

服务发现——Netflix Eureka     客服端负载均衡——Netflix Ribbon    断路器——Netflix Hystrix    服务网关——Netflix Zuul       分布式配置——Spring Cloud Config     

链路追踪----springcloud sleuth：a服务查b服务查c服务，查一个完整的链路

服务网关----gateway：接口鉴权处理，路由转发，权限校验，限流控制，过滤器

springcloud断路器的作用

他针对对报错有一个阈值，开关，断开了以后他就不会调用你这个接口的实现，它会调用你默认的一个方法，像电路一个开关，你达到这个值得时候会自动断开

举个例子： 当一个服务调用另一个服务由于网络原因或者自身原因出现问题时 调用者就会等待被调用者的响应 当更多的服务请求到这些资源时

 导致更多的请求等待 这样就会发生连锁效应（雪崩效应） 断路器就是解决这一问题

断路器有完全打开状态

 一定时间内 达到一定的次数无法调用 并且多次检测没有恢复的迹象 断路器完全打开，那么下次请求就不会请求到该服务

 半开

        短时间内 有恢复迹象 断路器会将部分请求发给该服务 当能正常调用时 断路器关闭

  关闭

         当服务一直处于正常状态 能正常调用 断路器关闭

Eureka和zookeeper的区别？

Zookeeper保证CP

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

Eureka保证AP

        Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

• Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
• Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
• 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

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

Hystrix如何实现线程隔离？

Hystrix通过命令模式，将每个类型的业务请求封装成对应的命令请求，比如查询订单->订单Command，查询商品->商品Command，查询用户->用户Command。每个类型的Command对应一个线程池。创建好的线程池是被放入到ConcurrentHashMap中

maven命令？

maven package：会将jar包打包到target下

maven install：将jar包装载到maven仓库，供其他项目使用

springCloud工作原理

Eureka的工作流程表