微服务
微服务架构是一种以一些微服务来代替开发单个大而全利用的办法，每一个小服务运行在本人的过程里,并以轻量级的机制来通信, 通常是 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面试题材料，文章都会在外面更新，整顿的材料也会放在外面。谢谢你的观看，感觉文章对你有帮忙的话记得关注我点个赞反对一下！