微服务与微服务架构

微服务的优缺点

优点

缺点

Dubbo与Spring Cloud

Spring Cloud Netflix

Eureka

Eureka的自我保护机制

Eureka和ZooKeeper的区别

简单对比一下CAP和ACID

Ribbon

Ribbon内置的七大负载均衡算法

Feign

Hystrix断路器

服务雪崩、熔断与降低

Zuul

Config分布式配置中心

---

        先简单了解一下微服务相关知识

微服务与微服务架构

        微服务架构是一种架构模式，提倡将单一应用划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合。服务之间采用轻量级的通信机制交互（基于HTTP的RESTful API）。

        微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度来看就是一种小而独立的处理过程，类似于进程概念，能够自行单独启动或销毁，拥有各自的数据库。

        比如医院中的科室：内科，外科，心脑血管科，耳鼻喉科等。微服务强调的是个体，微服务架构强调的是整体，是把一个个的微服务整合起来，对外暴露，是一个整体。

微服务的优缺点

优点

• 每个服务足够内聚，足够小，代码容易理解，更容易聚焦一个指定的业务功能或需求
• 开发简单、开发效率提高，一个服务可能只专门做一件事
• 微服务能够被2-5人的小团队单独开发
• 微服务是松耦合的，是具有功能意义的服务，无论是在开发阶段或部署阶段都是独立的
• 微服务可以使用不同的语言进行开发
• 易于第三方集成，比如Jenkins，Hudson，bamboo
• 易于被一个开发理解，修改和维护
• 允许开发人员利用融合最新技术
• 微服务只是业务逻辑的代码，不会和HTML、CSS或其他界面组件混合

缺点

• 开发人员要处理分布式系统的复杂性
• 多服务运维难度，随着服务的增加，运维的压力也增大
• 系统部署依赖
• 服务间通信成本较大
• 容易引起数据一致性的问题
• 系统集成测试、性能监控比较复杂

Dubbo与Spring Cloud

        Apache Dubbo 最初在 2008 年由 Alibaba 捐献开源，很快成为了国内开源服务框架选型的事实标准框架 ，得到了各行各业的广泛应用。在 2017 年，Dubbo 正式捐献到 Apache 软件基金会并成为 Apache 顶级项目，目前已经发展到了Dubbo3.x的版本， 是一款 RPC 服务开发框架。 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。

        Spring Cloud是一系列框架的整合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。其中最出名的就是Spring Cloud Netflix和Spring Cloud Alibaba两大类。

        Dubbo是基于RPC形式的通信，而Spring Cloud是基于Rest形式的通信，其对比如下

	Dubbo	SpringCloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

        最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。这两种方式各有优劣，从一定程度上，后者牺牲了服务调用的性能，但也避免了原生RPC带来的问题。而且REST比RPC更为灵活，在强调快速演化的微服务环境下，显得更加合适。

        Spring Cloud的功能比Dubbo更加强大，可以与其他Spring项目完美融合

Spring Cloud Netflix

Spring Cloud Netflix最出名且最常用的五大组件分别是

• 服务注册与发现：Eureka
• 断路器：Hystrix
• 服务网关：Zuul
• 负载均衡
  • 客户端负载均衡：Ribbon
  • 服务端负载均衡：Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口)
• 分布式配置：Config

Eureka

        Eureka是Netflix的一个子模块，也是核心模块。Eureka是一个基于Rest的服务，用于定位服务，以实现云端中间层服务发现和故障转移。功能类似于Dubbo的注册中心（Zookeeper）。包含两个组件：Eureka Server和Eureka Client

• Eureka Server（服务注册服务）：各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
• Eureka Client（Java客户端）：用于简化Eureka Server的交互，同时内置使用轮询负载算法的负载均衡器。在应用启动后，将会向Eureka Server发生心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）

Eureka的自我保护机制

        某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存。在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。设计初衷就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。

        使用自我保护模式，可以让Eureka集群更加的健壮、稳定。可以使用eureka.server.enable-self-preservation=false 禁用自我保护模式

Eureka和ZooKeeper的区别

        著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。

        Zookeeper保证的是CP(一致性和分区容错性)、Eureka则是AP(可用性和分区容错性)。

        当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于leader选举时间过长，30~120s，且选举期间zk集群都是不可用的，这会直接导致选举期间注册服务瘫痪。这是不可容忍的。

        Eureka在设计优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依赖可以提供注册和查询服务。如何某个Eureka注册失败，则自动切换至其他节点，所以只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。

简单对比一下CAP和ACID

• ACID的特点：Atomicity（原子性）、Consistency（一致性）、Isolation（独立性）、Durability（持久性）
• CAP的特点：Consistency（强一致性）、Availability（可用性）、Partition tolerance（分区容错性）
• CAP的3进2原则：CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

Ribbon

        提供客户端的软件负载均衡算法。Ribbon会自动根据配置的某个负载算法去连接机器，也可以自定义负载均衡算法。

Ribbon内置的七大负载均衡算法

• RoundRobinRule：轮询
• RandomRule：随机
• AvailabilityFilteringRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问
• WeightedResponseTimeRule：根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率越高，刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够，会切换到WeightedResponseTimeRule
• RetryRule：先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务
• BestAvailableRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务
• ZoneAvoidanceRule：默认规则，复合判断server所在区域的性能和server的可用性选择服务器

Feign

        是一个声明式的Web服务客户端，使得编写Web服务客户端变得非常容器。只需要创建一个接口，然后在上面添加@FeignClient注解即可。

Hystrix断路器

        Hystrix能保证在一个依赖服务出现问题的时候，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，从而避免了服务故障的蔓延。给予事先定义的响应结果，总比直接报错也友好的多

服务雪崩、熔断与降低

• 服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃
• 服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。Spring Cloud熔断机制通过Hystrix实现，Hystrix会监控微服务之间的调用状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。注解为@HystrixCommand
• 服务降级：当整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

Zuul

        包含了对请求的路由和过滤两个最主要的功能

• 路由：将外部请求转发到具体的微服务实例上
• 过滤：负责将请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础

        Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。Zuul服务最终还是会注册进Eureka。

        Zuul、Eureka、微服务之间的关系，就类似于小区保安，小区物业和业主的关系，物业知道有哪些业主，业主需要去物业登记，当请求（外卖或物业）保安根据物业登记的业务住址，告诉请求（外卖或物业）该前往那栋楼。

Config分布式配置中心

        Spring Cloud为微服务架构中的微服务提供集合化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

        当需要改变或添加环境配置时，之前的常规操作，都是需要打包重启服务，才能读取到最新的配置信息，而使用Spring Cloud Config可以进行非常灵活的配置，实时生效