共计 4913 个字符，预计需要花费 13 分钟才能阅读完成。
微服务
微服务架构是一种以一些微服务来代替开发单个大而全利用的办法，每一个小服务运行在本人的过程里, 并以轻量级的机制来通信, 通常是 HTTP RESTful API。微服务强调小快灵，任何一个绝对独立的性能服务不再是一个模块, 而是一个独立的服务。
微服务是一种生态，不是一种具体技术
微服务的个性
自主性（松耦合）
能够对微服务架构中的每个组件服务进行开发、部署、经营和扩大，而不影响其余服务的性能。这些服务不须要与其余服务共享任何代码或施行。各个组件之间的任何通信都是通过明确定义的 API 进行的。
专用性
每项服务都是针对一组性能而设计的，并专一于解决特定的问题。如果开发人员逐步将更多代码减少到一项服务中并且这项服务变得复杂，那么能够将其拆分成多项更小的服务。
灵便扩大
通过微服务，您能够独立扩大各项服务以满足其反对的应用程序性能的需要。这使团队可能适当调整基础设施需要，精确掂量性能老本，并在服务需要激增时放弃可用性。
轻松部署
微服务反对继续集成和继续交付，能够轻松尝试新想法，并能够在无奈失常运行时回滚。因为故障老本较低，因而能够大胆试验，更轻松地更新代码，并缩短新性能的上市工夫。
目前微服务的倒退情况
目前支流的就是 springCloud 和 dubbo 了，那么咱们对他们做一个比照：
Dubbo
一款高性能、轻量级的开源 Java RPC 框架，它提供了三大外围能力：面向接口的近程办法调用、智能容错、负载平衡，以及服务主动注册和发现。
节点角色阐明：
Provider: 裸露服务的服务提供方。
Consumer: 调用近程服务的服务生产方。
Registry: 服务注册与发现的注册核心。（Dubbo 种个别都是应用 zookeeper 作为注册核心）
Monitor: 统计服务的调用次和谐调用工夫的监控核心。
Container: 服务运行容器。
调用关系阐明：
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册核心注册本人提供的服务。
服务消费者在启动时，向注册核心订阅本人所需的服务。
注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长连贯推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心。
SpringCloud 与 Dubbo 的比照
SpringCould 是基于 SpringBoot 的根底上的一个微服务架构。包含包服务发现（Eureka），断路器（Hystrix），服务网关（Zuul），客户端负载平衡（Ribbon）、服务跟踪 (Sleuth)、音讯总线(Bus)、音讯驱动(Stream)、批量工作(Task) 等。Spring Cloud 摈弃了 Dubbo 的 RPC 通信，采纳的是基于 HTTP 的 REST 形式。
Dubbo 和 Spring Cloud 并不是齐全的竞争关系，两者所解决的问题域不一样：Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案。
SpringCloud
服务发现——Netflix Eureka
Eureka 蕴含两个组件：Eureka Server 和 Eureka Client
Eureka Server 提供服务发现能力，各个微服务启动时会向 Eureka Server 注册本人的信息（服务名、IP、端口等），Eureka Server 便存储了这个信息。性能相似于 zookeeper
Eureka Client 是一个 Java 客户端，用于简化与 Eureka 的交互。
心跳机制：每个微服务启动后，会每个肯定工夫（默认 30s）向 Eureka Server 发送心，让其晓得本人扔衰弱存活。如果 Eureka Server 在肯定工夫内（默认 90s）没有收到某个微服务实例的心跳，Eureka Server 就会登记该实例
Eureka 集群：默认状况下，Eureka Server 也是 Eureka Client，多个 Eureka Server 之间通过复制形式，来实现服务注册表中的数据同步。Eureka Client 会缓存服务注册表中的信息，毋庸每次都申请 Eureka Server 查问，缓解了 Eureka Server 的压力；即便 Eureka Server 所有节点都宕机，服务消费者仍然能够查问本人缓存中的信息找到去调用服务提供者。
自我爱护机制：若是因为网络起因，通过心跳机制判读该服务已死导致实例被登记时，这是不被容许的。因而自我爱护机制来解决这个问题，当 EurekaServer 节点短时间内失落过多客户端（网络起因导致），那么这个节点就会进入自我保护模式，一旦进入该模式，EurekaServer 就会爱护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会登记任何微服务）。当网络复原时，该 EurekaServer 节点会退出自我爱护机制。自我爱护机制使 Eureka 集群更加的稳固与强壮。
CAP 准则
CAP 准则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP 准则是 NOSQL（Redis、mongdb）数据库的基石。
一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点拜访同一份最新的数据正本）
可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写申请。（对数据更新具备高可用性）
分区容错性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。零碎如果不能在时限内达成数据一致性，就意味着产生了分区的状况，必须就以后操作在 C 和 A 之间做出抉择（集群下必须要保障 P）。
CAP 三个个性只能满足其中两个：
CA without P：如果不要求 P（不容许分区），则 C（强一致性）和 A（可用性）是能够保障的。但放弃 P 的同时也就意味着放弃了零碎的扩展性，也就是分布式节点受限，没方法部署子节点，这是违反分布式系统设计的初衷的。传统的关系型数据库 RDBMS：Oracle、MySQL 就是 CA。
CP without A：如果不要求 A（可用），相当于每个申请都须要在服务器之间放弃强统一，而 P（分区）会导致同步工夫有限缩短(也就是期待数据同步完能力失常拜访服务)，一旦产生网络故障或者音讯失落等状况，就要就义用户的体验，期待所有数据全副统一了之后再让用户拜访零碎。设计成 CP 的零碎其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最根本的要求，因为如果连这个规范都达不到，那么间接采纳关系型数据库就好，没必要再浪费资源来部署分布式数据库。
AP wihtout C：要高可用并容许分区，则需放弃一致性。一旦分区产生，节点之间可能会失去分割，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的利用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提醒是有库存的，当你抉择完商品筹备下单的时候，零碎提醒你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统能够失常的服务，而后在数据的一致性方面做了些就义，尽管多少会影响一些用户体验，但也不至于造成用户购物流程的重大阻塞。
zookeeper 和 Eureka
zookeeper 保障的是 CP
zookeeper 存在的问题：当 master 挂掉的时候会通过选举产生新的 master，然而因为在选举期间集群不可用且选举工夫过长导致服务长期不可用。
Eureka 保障的是 AP
Eureka 因为保障的是可用性，因而不会呈现下面那种状况。因为 Eureka 的每个节点都是平等的，挂掉几个节点不会影响整体的工作，当某个 Eurek 的客户端注册失败的时候会主动切换到其余节点进行注册，只有是还有一台存活就阔以保障可用性，只不过查问到的数据不是最新的。
因而 Eureka 能够很好的应答因为网络故障导致节点失落的状况，而不是像 zookeeper 那样使整个注册服务瘫痪的状况。
客服端负载平衡——Netflix Ribbon
Ribbon 工作原理
ribbon 实现的关键点是为 ribbon 定制的 RestTemplate，ribbon 利用了 RestTemplate 的拦截器机制，在拦截器中实现 ribbon 的负载平衡。负载平衡的根本实现就是利用 applicationName 从服务注册核心获取可用的服务地址列表，而后通过肯定算法负载，决定应用哪一个服务地址来进行 http 调用。
负载平衡分类
集中式 LoadBalance
在消费者和提供者之间应用独立的 LoadBanlance 设施，如 Nginx（反向代理服务器）。由该设施将拜访亲求散发到提供者。
过程式 LoadBalance
将 LoadBanlance 的逻辑整合到消费者，消费者从注册核心获取可用的地址，而后本人通过策略抉择适合的服务器。Ribbon 就是典型的过程式。
负载平衡算法
随机负载平衡（默认）：随机抉择状态为 UP 的 Server
简略轮询负载平衡：以轮询的形式顺次将申请调度不同的服务器
加权响应工夫负载平衡：依据响应工夫调配一个 weight，响应工夫越长，weight 越小，被选中的可能性越低
区域感知轮询负载平衡：复合判断 server 所在区域的性能和 server 的可用性抉择 server
断路器——Netflix Hystrix
Hystrix 为分布式系统的提早和故障提供弱小的容错能力。当一个节点出问题的时候，hystrix 保障了整体不会失败，进步了分布式系统的弹性
服务熔断
微服务架构中某个微服务产生故障时，要疾速切断服务，提醒用户，后续申请，不调用该服务，间接返回，开释资源，这就是服务熔断。
熔断失效后，会在指定的工夫后调用申请来测试依赖是否复原，依赖的利用复原后敞开熔断。
服务降级
服务器高并发下，压力剧增的时候, 依据当业务状况以及流量，对一些服务和页面有策略的降级 (能够了解为敞开不必要的服务)，以此缓解服务器资源的压力以保障外围工作的失常运行。
双十一期间，支付宝很多性能都会提醒，[双十一期间，保障外围交易，某某服务数据提早]。
服务网关——Netflix Zuul
网关：零碎惟一对外的入口，介于客户端与服务器端之间，用于对申请进行鉴权、限流、路由、监控等性能。
zuul 提供了两个次要性能：路由和过滤
路由性能负责将内部申请转发到具体的微服务实例上，是实现内部拜访对立入口的根底。
过滤性能则负责对申请的处理过程进行干涉，是实现申请校验、鉴权等解决
Zuul 和 Eureka 进行整合，将 Zuul 本身注册为 Eureka 服务治理下的利用，同时从 Eureka 中取得其余微服务的音讯，也即当前的拜访微服务都是通过 Zuul 跳转后取得。
留神：Zuul 服务最终还是会注册进 Eureka
艰深点就是对立了拜访地址
分布式配置——Spring Cloud Config
在分布式系统中，因为服务数量巨多，为了不便服务配置文件对立治理，实时更新，所以须要分布式配置核心组件。在 Spring Cloud 中，有分布式配置核心组件 spring cloud config，它反对配置服务放在配置服务的内存中（即本地），也反对放在近程 Git 仓库中。在 spring cloud config 组件中，分两个角色，一是 config server，二是 config client。server 提供配置文件的存储、以接口的模式将配置文件的内容提供进来，client 通过接口获取数据、并根据此数据初始化本人的利用。
最初
大家看完有什么不懂的能够在下方留言探讨，也能够关注我私信问我，我看到后都会答复的。也欢送大家关注我的公众号：前程有光，金三银四跳槽面试季，整顿了 1000 多道将近 500 多页 pdf 文档的 Java 面试题材料，文章都会在外面更新，整顿的材料也会放在外面。谢谢你的观看，感觉文章对你有帮忙的话记得关注我点个赞反对一下！