Spring Cloud系列（一）：微服务架构简介

一、微服务概述

　　1、微服务是什么

　　微服务架构的核心就是服务的拆分，把传统的单体式应用，根据一定的维度（比如业务）拆分为一个一个的服务，每一个服务都有自身特定的功能，又都能够独立的部署，甚至可以拥有自己的存储技术。这样的一个一个的小型服务就是微服务。

　　2、微服务架构是什么

　　微服务架构是一种架构风格，是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(HTTP REST API)。这些服务围绕业务能力构建并且可独立部署。这些服务可用不同的语言开发，使用不同的数据存储技术。

　　3、微服务和微服务架构区别

　　微服务强调的是服务的大小，一般根据业务维度，职责单一原则，而微服务架构是指把一个一个的微服务管理起来，对外提供一套完整的服务体系。

　　4、微服务的优缺点

　　优点：

　　① 相对复杂的单体应用，拆分为多个微服务解决了业务复杂性问题；

　　② 开发相对比较简单，只需要了解自己服务的一个业务即可；

　　③ 每个服务都可以有专门开发团队来开发；

　　④ 服务的耦合度降低，职责比较单一；

　　⑤ 每个微服务可以独立的部署，并且可更加服务自身的一个需求进行动态的扩展；

　　⑥ 每个微服务可以拥有自己特点的技术架构，数据存储技术等；

　　缺点：

　　① 增加了运维成本，之前一个war或者一个jar，现在需要维护管理大量的服务；

　　② 增加了服务间的调用成本；

　　③ 微服务应用是分布式系统，由此会带来固有的复杂性，比如分布式事务，分布式锁等；

　　④ 由于服务调用比较复杂，需要引入调用链追踪，系统监控等一些监控工具；

　　5、单体和微服务

二、微服务架构核心组件

　　1、注册中心

　　2、服务调用

　　3、服务熔断

　　4、服务网关

　　5、配置中心

三、常见的微服务架构

　　1、Dubbo

　　① 服务容器Container负责启动，加载，运行服务提供者。

　　② 服务提供者Provider在启动时，向注册中心注册自己提供的服务。

　　③ 服务消费者Consumer在启动时，向注册中心订阅自己所需的服务。

　　④ 注册中心Registry返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

　　⑤ 服务消费者Consumer，从提供者地址列表中，基于负载均衡算法，选其中一个提供者进行调用，如果调用失败，再选另一台调用。

　　⑥ 服务消费者Consumer和提供者Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。

　　2、Spring Cloud

　　① 服务注册(Register)：Eureka Client会通过发送REST请求向Eureka Server注册自己的服务，提供自身IP、端口、微服务名称等信息。Eureka Server接收到注册请求后，就会把这些信息存储在一个双层的Map中。

　　② 服务续约(Renew)：在服务注册后，Eureka Client会维护一个心跳来持续通知Eureka Server，说明服务一直处于可用状态，防止被剔除。Eureka Client在默认的情况下会每隔30秒(eureka.instance.leaseRenewallIntervalInSeconds)发送一次心跳来进行服务续约。

　　③ 服务同步(Replicate)：Eureka Server集群中多个Eureka Server之间会互相进行注册，不同Eureka Server之间会进行服务同步，用来保证Eureka Server集群内的所有实例中的数据一致性（从这个架构来看，Eureka Server所有实例所处的角色都是对等的，没有类似Zookeeper、选举过程，也不存在主从，所有的节点都是主节点。Eureka官方将Eureka Server集群中的所有实例称为"对等体（peer）"）。

　　④ 获取服务(Get Registry)：服务消费者（Eureka Client）在启动的时候，会发送一个REST请求给Eureka Server，获取上面注册的服务清单，并且缓存在Eureka Client本地，默认缓存30秒(eureka.client.registryFetchIntervalSeconds)。同时，为了性能考虑，Eureka Server也会维护一份只读的服务清单缓存，该缓存每隔30秒更新一次。

　　⑤ 服务调用(Make Remote Call)：服务消费者在获取到服务清单后，就可以根据清单中的服务列表信息，查找到其他服务的地址，从而进行远程调用。

　　⑥ 服务下线(Cancel)：当Eureka Client需要关闭或重启时，就不希望在这个时间段内再有请求进来，所以，就需要提前先发送REST请求给Eureka Server，告诉Eureka Server自己要下线了，Eureka Server在收到请求后，就会把该服务状态置为下线（DOWN），并把该下线事件传播出去。

　　⑦ 服务剔除(Evict)：服务实例可能会因为网络故障等原因导致不能提供服务，而此时该实例也没有发送请求给Eureka Server来进行服务下线，所以，还需要有服务剔除的机制。Eureka Server在启动的时候会创建一个定时任务，每隔一段时间（默认60秒），从当前服务清单中把超时没有续约（默认90秒，eureka.instance.leaseExpirationDurationInSeconds ）的服务剔除。

　　⑧ 自我保护：既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enableself-preservation: false)