Spring Cloud入门

概述

 

• 微服务入门简介
• Spring Cloud入门
• Spring Cloud架构

今天我们交流分享的内容包括以上三个模块，入门、入门、架构。Spring Cloud其实就是微服务，所以我们首先看下微服务相关的内容，其次进行一下Spring Cloud的简单入门了解，最后我们来看下Spring Cloud包含的架构内容，当然也是入门级别的介绍。下面先看微服务。

 

为什么要使用微服务？

 

首先我们来看一个问题，为什么要使用微服务？那微服务没有出现之前我们都是使用单体架构，所以下面我们先了解一下单体架构以及它的特点。

 

单体架构

 概念

 

耦合在一个系统里面

只有一个进程

 

特点

 

测试、部署成本高

可伸缩性差

可靠性差

迭代困难

团队协作效率低下

 

微服务架构

 概念

 

一种架构风格

1：N

单独部署

低耦合高内聚

 

特点

 

灵活部署

可伸缩性好

不是强依赖

独立开发

团队协作效率高

 

但是虽然微服务有很多优点，但是它也有自己带来的问题，例如：部署的服务多，运维和监控成本复杂度上升，接口兼容多版本，新老版本兼容，分布式系统的复杂度，服务容错性、服务负载均衡等。另外还有分布式事务的问题，微服务开发，带来的难题就是分布式事务的处理，CAP理论（一致性、可用性、分区容错性）容错性则可以保证如果只是系统中的部分节点不可用，那么相关的操作仍旧能够正常完成。

 

Spring Cloud入门

 

Spring Cloud是基于Spring Boot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

 

Spring Cloud是一个品牌机，我们自己的微服务是组装机！

 

下面我们看下全家桶里面都是有什么东西？

 

 

Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。

 

Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。

 

Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

 

Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。

 

Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

 

Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。

 

Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

 

Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。

 

Spring Cloud Sleuth：日志收集工具包，服务跟踪，封装了Dapper,Zipkin和HTrace操作。

 

Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。

 

Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。

 

Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

 

Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。

 

Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

 

Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

 

下面我们对其中5个组件，来看看什么是Spring Cloud微服务？

 

Eureka

 

Spring Cloud的核心是restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下问题？

我们普通的服务架构包括业务层、数据层、持久化层，业务层通过restful接口调用，所以有每个业务服务都有自己的微服务地址和端口，所有微服务的地址一定非常的多，所以为了统一管理这些地址信息。

 

也为了及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且要具备HA机制（高可用机制），为了高速并且方便的进行所有服务的注册发现，Spring Cloud里面提供了一个Eureka，Eureka 由两个组件组成： Eureka 服务器 和 Eureka 客户端。Web客户端通过注册中心的客户端来获取注册中心的服务地址信息，业务层将自己的服务注册到注册中心。所有的服务端及访问服务的客户端都需要连接到注册中心，服务在启动时会自动注册自己到Eureka服务器，同时每 30 秒发送一次心跳，每一个服务都有一个名字，这个名字会被注册到Eureka服务器。使用服务的一方只需要使用该名字加上方法名就可以调用到服务。Spring Cloud的服务注册及发现，不仅仅只有Eureka，还支持Zookeeper和Consul。默认情况下是Eureka，spring 封装了Eureka，使其非常简单易用，只需要比传统应用增加一行代码就可以使用了，这一行代码就是一个注解。

对比：Eureka不支持数据中心、Consul支持，完成跨数据中心的同步。除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务。CAP 理论的取舍

Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，java语言开发，一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性，并能 k-v store 服务保证一致性。 而Zookeeper则是CP类型 牺牲可用性，在服务发现场景并没太大优势。总的来看，目前Consul 自身功能，和Spring Cloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。

 

Ribbon

 

对于整个的web端的架构，可以轻松方便进行web程序编写，而后利用nginx进行负载均衡处理，但是你的web端出现立刻负载均衡，，那么业务端呢？应该也有多个业务端进行负载均衡。那么这个时候需要将所有参与到负载均衡的业务端在eureka中注册。通过Ribbon实现负载均衡。负载均衡分为两种：服务端负载均衡和客户端负载均衡，ribbon属于客户端负载均衡。eureka 附带客户端库，为何还要 Ribbon 呢？Ribbon 的负载均衡算法久经考验，可以直接拿来使用

Ribbon 维护了一个服务器列表，如果服务器有宕机现象，Ribbon 能够自行将其剔除；但如果该服务器故障排除，重新启动，或者增加新的负载节点，我们需要手工调用 Ribbon 的接口将其动态添加进 Ribbon 的服务器列表。这样明显不太友好。如何能够在服务节点启动时，自行添加服务列表？—— Eureka。Eureka 提供了 Application Service 客户端的自行注册的功能。此外，Eureka 的缓存机制能够防止大规模宕机带来的灾难性后果。所以ribbon和Eureka完美组合。

 

Feign

 

一个微服务中，有很多操作，一个用户的增加、查询等。在进行客户端使用rest架构调用的时候，往往都需要有一个调用地址，即使现在使用了Eureka作为注册中心，那么他也需要有一个明确的调用地址，可是所有的操作如果都利用调用地址的方式来处理，程序的开发者最方便应用的工具是接口，所以现在希望可以将所有的rest服务的内容以接口方式调用，所以现在出现了一个Feign的功能。

 

Feign是一个声明式的web服务客户端，它使得写web服务变得更简单。使用Feign,只需要创建一个接口并注解。它具有可插拔的注解特性，包括Feign 注解。Feign同时支持可插拔的编码器和解码器。

 

Feign包含了Ribbon和Hystrix

Ribbon实现了注册到Eureka Server上的服务名来调用服务

Feign实现了接口来调用服务。

 

Hystrix

 

在进行整体的微架构设计的问题还是属于RPC，所以就必须考虑熔断处理机制，实际上所谓的熔断机制就好比生活中的保险丝一样，有了保险丝在一些设备出现故障之后依然可以保护家庭电器可以正常使用，如果说现在有若干个微服务，并且这些微服务之间允许互相调用，例如，A微服务调用了B服务，B微服务又调用了C的微服务。假设现在出现了不可控的问题，例如网络故障，机房断电，系统死机等，这个时候，假设导致C服务出了问题。如果在设计过程之中没有处理好熔断机制，那么就容易出现雪崩效应。Spring Cloud里面提供了一个Hystrix来实现熔断处理机制。以保证某一个微服务即使出现问题之后，仍然可以使用。

说起Spring Cloud熔断让我想起了去年股市中的熔断，多次痛的领悟，随意实施的熔断对整个系统的影响是灾难性的，好了接下来我们还是说正事。

Hystrix特性：断路器、fallback、资源隔离

断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.

Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存。

 

Zuul

 

通过Zuul的代理用户只需要知道制定的路由的路径就可以访问微服务的信息，这样更好的提现了java中的key=value的设计思想，而且所有的微服务通过Zuul进行代理之后也可以更加合理的进行名称的隐藏（更加安全）。

 

Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

 

推荐书籍

 

《Spring Cloud微服务实战》