如何使用springCloud搭建一个简单的分布式demo

这里是修真院后端小课堂，每篇分享文从

八个方面深度解析后端知识/技能，本篇分享的是：

【如何使用springCloud搭建一个简单的分布式demo】

大家好，我是IT修真院北京分院第34期的学员岳晓鹏，一枚正直纯洁善良的java程序员，今天给大家分享一下，修真院官网java任务10，深度思考中的知识点——如何使用springCloud搭建一个简单的分布式demo。自己只是实现了spring cloud的注册中心和简单的负载均衡，应该算是spring cloud的简单介绍。

（1）背景介绍：

微服务

微服务架构风格就像是把小的服务开发成单一应用的形式， 运行在其自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP 资源 API）。这些服务都是围绕业务能力来构建，通过全自动部署工具来实现独立部署。这些服务，其可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。

Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

（2）知识剖析：

服务注册中心

使用微服务，微服务的本质还是各种API接口的调用。服务中心是统一管理我们的服务的，使用Spring Cloud Eureka，我们可以将自己定义的API接口注册到Spring Cloud Eureka上，Eureka负责服务的注册与发现，构成Eureka体系的包括：服务注册中心、服务提供者、服务消费者。

路由网关zuul

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，

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

熔断器Hystric

微服务系统是一个分布式架构，服务之间是彼此调用的，当有一个服务出现了故障，而服务的调用方不知道服务出现故障，

此时调用方的请求不断的增加，最后就会调用方形成任务的积压，最终导致自身服务的瘫痪。熔断器的熔断机制类似电路中的短路，当我们某个服务不可用时，直接快速切断该服务的连接，返回一个错误的页面，这样做好处是仅仅是依赖该服务的业务无法正常运作，而其他的不依赖于这个服务的其他服务可以正常运作。

负载均衡组件ribbon

为了提高服务的可用性，我们一般会将相同的服务部署多个实例，负载均衡的作用就是使获取服务的请求被均衡的分配到各个实例中。我们在之前的任务里学了nginx实现了负载均衡，springCloud里提供了ribbon组件给我们，配合springCloud封装好的RestTemlate只需要简单的配置即可实现负载均衡。

Feign跟rebbin一样都是实现负载均衡的组件，不同的是feign里面封装了ribbon和hystric，不用像ribbon那样必须结合RestTemplate即可使用。

服务配置中心config

对于微服务还不是很多的时候，各种服务的配置管理起来还相对简单，但是当成百上千的微服务节点起来的时候，服务配置的管理变得会复杂起来。分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件Spring Cloud Config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。

消息中心bus

Spring Cloud Config中，我们知道的配置文件可以通过Config Server存储到Git等地方，通过Config Client进行读取，

但是我们的配置文件不可能是一直不变的，当我们的配置文件放生变化的时候如何进行更新哪？

一种最简单的方式重新一下Config Client进行重新获取，但Spring Cloud绝对不会让你这样做的，Spring Cloud Bus提供一种操作使得我们在不关闭服务的情况下更新我们的配置。

（3）常见问题：

pring cloud和dubbo的区别？

（4）解决方案：

在微服务相关的这几个方面，服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等来比较下的话，Dubbo 只是实现了服务治理，而 Spring Cloud 子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。

（5）编码实战：

介绍了下hashmap几个概念的实现及put操作的流程

（6）拓展思考：

（7）参考文献：

https://www.cnblogs.com/xiaojunbo/p/7090742.html【1】优快云博客

http://www.ityouknow.com/springcloud/2017/05/01/simple-springcloud.html【2】个人博客

（8）更多讨论：

Q1：什么是客户端负载均衡？

A1：负载均衡一般分为服务端负载均衡和客户端负载均衡，服务端的负载均衡通过硬件（如F5）或者软件（如Nginx）来实现。服务端负载均衡是在硬件设备或者软件模块中维护一份可用服务清单，然后客户端发送服务请求到这些负载均衡的设备上，这些设备根据一些算法均衡的将请求转发出去。而客户端负载均衡则是客户端自己从服务注册中心获取服务清单缓存到本地，然后通过客户单内部算法均衡的去访问这些服务。

Q2：如何在服务端宕机的情况下保证服务运行？
A2：简单来说，这就是熔断器的功能，在服务提供者不能提供服务后，熔断器就会根据检测机制，将服务从注册中心清除，下次有别的请求的时候，就不会去访问已经宕机的服务，返回一个错误信息或导入到别的备用服务上边。有时候会有注册中心宕机的情况，这种情况下，就需要布置注册中心集群，保证注册中心不会全部宕机能好点。
Q3：如何区分spring eureka的生产者和消费者？

A3：因为spring eureka中只有server和client，生产者和消费者都属于client，他们之间没有明确的界限，根据具体行使的功能来进行划分，你提供服务，你就是服务生产者，你从别的client得到服务，你就是消费者，两者可以互换，功能也可以相互重叠，我们习惯上将他们的职责分清。比方说整个cloud中的其余组件，都是client，但是提供不同的功能，比如负载均衡，熔断等功能，只让它进行特定的功能。区分的话，从配置文件的服务名称来进行区分。

（9）鸣谢：

（10）结束语：

今天的分享就到这里啦，欢迎大家点赞、转发、留言、拍砖~