Spring
微服务:
微服务的概念源于2014年3月Martin Fowler所写的一篇文章Microservices” 。
微服务架构是一种架构模式,它提倡将单一应用程序划分成组小的服务.服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API).每个服务都围绕具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等另外,应尽量避免统的集中式的服务理机制.对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。微服务是种架构风格,一个大型复杂软件应用由一 个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松精合的。每个微服务仅关注于完成件任务并很好地完成该任务。在所有情况下,每个任务代表着个小的业务能力。
概述
spring cloud为开发人员提供了快速构建分布式系统中的一些常见模式的工具(例如配置管理服务发现、断路由、智能路由、微服务、控制总线)。分布式系统的协调导致了样板模式,使用spring cloud开发人员可以快速地支持实现这些模式的服务
背景
应用框架的演变
1.单一应用架构
2.垂直应用架构
3.分布式服务架构
4.流动计算架构
spring框架
spring boot
Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的打始措建以及开发过程。该框架使用了特定的方式来进行配置从而使开发人员不再需要定义样板化的配置。Spring Boot不是什么新的框架,它默认配置了很多框架的使用方式,就像maven整合了所有的jar包,Spring Boot整合了所有的框架(不知道这样比喻是否合适。Spring Boot简化了基于Spring的应用开发,通过少量的代码就能创建一个独立的、 产品级别的Spring应用。Spring Boot为Spring平台及第方库提供开箱即用的设置,这样你就可以有条不紊地开始。
Spring Boot的核心思想就是约定大于配置,多数Spring Boot应用只需要很少的Spring配置。采用Spring Boot可以大大的简化你的开发模式,所有你想集成的常用框架,它都有对应的组件支持。
spring cloud
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发.如服务发现注册配置中心消息总线负载均衡断路器数据监控等,都可以用Sping Boo的开发风格做到键启动和部署。Spring Coud并没有重复制造轮子:它只是将目前各家公司开发的比较成熟经得起考验的服务框架很合起来;通过Spring B风格进行再封装屏蔽掉了复杂的开发工具包。开爱和实视原理,最终给开发者留出了 喜简单易懂易都着和易维护的分布式系统
特性
●spring cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖
●分布式/版本化配置.服务注册和发现.路由
●service-to-service调用.负载均衡
●断路由
●分布式消息传递
组件
spring cloud config
●远程配置服务。
●远程配置是每个都必不可少的中间件,远程配置的特点一般需要:多节点主备、配置化动态修改、配置本地化缓存、动态修改的实时推送等。
● config允许配置文件放在git上或者svn上,和spring boot的集成非常容易,但是缺点就是修改了git上的配置以后,只能个个的请求每个service的接口 ,让他们去更新配置,需要配合消息总线和队列结合使用
spring cloud bus
●事件消息总线,用于在集群(例如,配置变化事件)中传播状态变化。经常与SpringCloud Config联合使用。
●spring cloud config本身不能向注册过来的服务提供实时更新的推送。比如我们配置放在了git上,那么当修改github上配置内容的时候,最多可以配置webhook到台config-server上,但是config-server自己不会将配置更新实时推送到各个服务上。
● bus的作用就是将大家链接在 条总线上,这条线上的所有server共享状态,当webhook到bus.上的某台server的时候 ,其他server也会收到相同的hook状态。但是bus的使用需要依赖于MQ, bus直接继承了RabbitMq & kafka ,只需要在Sspring中直接配置地址即可
spring cloud bus
●事件消息总线,用于在集群(例如,配置变化事件)中传播状态变化。经常与SpringCloud Config联合使用。
●spring cloud config本身不能向注册过来的服务提供实时更新的推送。比如我们配雪放在了git,那么当修改github上配置内容的时候,最多可以配置webhook到一台config-server.上,但是config-server自己不会将配置更新实时推送到各个服务上。
●bus的作用就是将大家链接在一 条总线上,这条线上的所有server共享状态,当webhook到bus上的某一台server的时候 ,其他server也会收到相同的hook状态。但是bus的使用需要依赖于MQ, bus直接继承了RabbitMq & kafka,只需要在spring中直接配置地址即可
eureka
●spring cloud的服务发现组件。
●eureka负责服务注册和服务发现,为了高可用,一般需要多 个eureka
serverd相互注册,组成集群。Eureka Server的同步遵循着个非常简单的原则:只要有一条边将节点连接,就可以进行信息传播与同步。
●eureka内部对于注册的service主要通过心跳来监控service是否已经挂掉,默认心跳时间是15s。这就意味着,当个服务提供方挂掉以后,服务订阅者最长可能30s以后才发现。
●service启动连上eureka之后,会同步份服务列表到本地缓存 ,服务注册有更新时, eureka会推送到每个service。
● eureka也会有一些策略防止由于某个服务所在网络的不稳定导致的所有服务心跳停止的雪崩现象。
●eureka自带web页面,在页面上能看到所有的服务注册情况和eureka集群状态。
● eureka支持服务自己主动下掉自己:请sevice的下列地址.可以让服务从eureka上下掉自己,同时service进程也会自己停掉自己。curd -H
consul
●也是一个服务发现工具,而且自带key-value存储服务健康检查和web页面。
●能联行首方dcer镜像,直接使用docker cnsu集群用户服务发现的话.运维成本会直线下降
ribbon
●客户端负载均衡组件。
●服务发现以后,每个service在本地知道自己要调用的服务有多少台机器,机器的ip是什么,端口号是多少,那这个service在本地需要有一个负载均衡策略,为每一次请求选择一台目标机器进行调用,而ribbon做的就是负载均衡策略的选择。
● ribbon提供了多种负载均衡策略,包括BestAvailableRule.
AvailabilityFilteringRuleWeightedResponseTimeRule. RetryRule、 RoundRobinRule、 RandomRule、
ZoneAvoidanceRule等,没记错的话,默认是ZoneAvoidanceRule.当然,也可以自定义自己的负载均衡策略,比如被调用服务需要灰度发布或者A/B测试的话,就可以在ribbon这一-层做自定义。
feign
●声明式、模板化的HTTP客户端。
●微服务之间的调用本质还是http请求,如果对于每个请求都需要写请求代码,增加请求参数,同时对请求结果做处理,就会存在大量重复工作,而feign非常优雅的帮助我们解决了这个问题,只需要定义一个interface ,fegin就知道http请求的时候参数应该如何设置。同时, feign也集成了ribbon,只要在微服务中依赖了ribbon , feign默认会使用ribbon定义的负载均衡策略。
●feign并不是仅只能使用在有eureka或者ribbon的微服务系统中,任何系统中,只要涉及到http调用第三方服务,都可以使用feign帮我们解决http请求的代码重复编写
hystrix
●断路器,类似于物理电路图中的断路器。
●正常情况下,当整个服务环境中,某个服务提供方由于网络原因、数据库原因或者性能原因等,造成响应很慢的话.调用方就有可能短时间内累计大量的请求线程,最终造成调用方down,甚至整个系统崩溃。而加入hystrix之后,如果hystrix发现某个服务的某台机器调用非常缓慢或者多次调用失败,就会短时间内把这条路断掉,所有的请求都不会再发到这台机器上。
●如果某个服务所有的机器都挂了, hystrix会迅速失败,马上返回,保证被调用方不会有大量的线程堆积。
●Feign默认集成了hystrix. *上面有提到,使用eureka时,当个服务提供方挂掉以后,服务订阅者最长可能3s以后才知道那这30s就会出现大的调用失败。如果在系统里面集成了hystix,就会马上把挂掉的这台服务提供方断路掉,让请求不再转发到这台机器上,大量减少调用失败。
●hystrix执行断坚操作议后 并不表示这条路就永远断了,而是会定时间间隔内缓慢尝试去请求这条路,如果能请求成功.断路就会恢复。
zuul
●是个网关组件提供动态路由监控弹性安全等边缘服务的推架。
●安简华量Fropetis文件 不需要与具体的代码就可以实现将请求转发到相应的服务上去。还可以定制化些fiter做验证 隔离限流文件处理等切面,对于网关来说,使用zuul能减少大的代码。
turbine
●是聚合服务器发送事件流数据的一个工具,用来监控集群Fhystrix的metrics情况
●在复杂的分布式系统中,相同服务的节点经常需要部署上百甚至上千个,很多时候,运维人员希望能够把相同服务的节点状态以一个 整体集群的形式展现出来,这样可以更好的把握整个系统的状态。
●turbine提供把多个hystrix.stream的内容聚合为一个数据源供Dashboard展示
Spring Cloud Starters
●spring boot熱插拔、提供默圦配置、幵箱即用的依頼。
●starter 是spring bpot框架非常基咄的部分。可以自定义starter
端口信息
8080:服务注册中心的端口
9000:生产者端口
9001:消费者端口
8888:网关的端口
服务器信息
| IP | 服务 |
|---|---|
| 1.1.1.3 | maven |
| 1.1.1.4 | maven |
部署maven
两台节点都部署,过程略……
部署Eureka注册中心
两台节点都部署
解压软件包
1 | tar zxf spring-cloud-examples.tar.gz -C /usr/local/ |

项目打包
1 | mvn package |
构建完之后操作
两台节点构建完成之后执行以下操作开启服务注册中心
1 | java -jar target/spring-cloud-eureka-0.0.1-SNAPSHOT.jar |
打开新终端
激活新终端的环境变量文件并放行端口、沙盒
1 | source /etc/profile |
访问
1.1.1.3:8080

访问
1.1.1.4:8080

部署Producer生产者
第一台节点打开新终端
构建生产者,服务注册与发现中心
1 | source /etc/profile |
修改HelloController文件
第一台节点
作为两个节点的区分
1 | vi src/main/java/com/neo/controller/HellpController.java |
项目打包
1 | mvn package |
节点二打开新终端
1 | source /etc/profile |
项目打包
1 | mvn package |
生产和消费构建完成执行操作
两台节点都构建完成后执行以下操作开启生产者的9000端口
1 | cd /usr/local/spring-cloud-examples/eureka-producer-consumer/spring-cloud-producer |
放行防火墙
1 | 放行9000端口防火墙、沙盒 |
执行后,再次打开浏览器刷新一下(这里就会显示8000端口和9000端口)

最后验证
/hello?name=haha(haha这个名字随意指定)
1 | curl 1.1.1.3:9000/hello?name=haha |
部署Consumer消费者
节点一
修改配置文件
1 | cd /usr/local/spring-cloud-examples/eureka-producer-consumer/spring-cloud-consumer |
项目打包
1 | mvn package |
运行消费者,开启9001端口
1 | java -jar target/spring-cloud-consumer-0.0.1-SNAPSHOT.jar |
打开另一个终端并放行防火墙的9001端口、沙盒
1 | source /etc/profile |
再次打开浏览器,查看9001端口是否存在

节点二
访问消费者端口
1 | curl http://1.1.1.3:9001/hello/haha |
haha定义的是一个名字,访问时反馈的名字
不断刷新会变换生产者的返回信息,是因为Spring Cloud的Ribbon负载均衡组件的作用进行集群轮询
部署网关zuul
节点一
修改配置文件
1 | cd /usr/local/spring-cloud-examples/spring-cloud-zuul/spring-cloud-zuul/ |
项目打包
1 | mvn package |
运行网关8888端口
1 | java -jar target/spring-cloud-zuul-1.0.0.BUILD-SNAPSHOT.jar |
放行防火墙
1 | source /etc/profile |

刷新

8888端口启动完成
节点二
访问网关端口
访问多次实现轮询效果(必须带有token值,可随便写)
1 | curl 'http://1.1.1.3:8888/spring-cloud-producer/hello?name=zx&token=123' |
模拟故障
断掉节点二的9000端口的生产者
再次访问
1 | curl 'http://1.1.1.3:8888/spring-cloud-producer/hello?name=zx&token=123' |
再次访问
1 | curl 'http://1.1.1.3:8888/spring-cloud-producer/hello?name=zx&token=123' |
不会显示轮询效果,因为节点二的生产者中断
开启节点二的9000端口
等待几秒钟,让它进行重试
再次访问,就会实现轮询效果
1 | curl 'http://1.1.1.3:8888/spring-cloud-producer/hello?name=zx&token=123' |
重新启动消费者9001端口
节点二访问
1 | curl http://1.1.1.3:9001/hello/zx |
部署hystrix熔断器
节点一修改配置文件
1 | cd /usr/local/spring-cloud-examples/spring-cloud-hystrix/spring-cloud-consumer-hystrix/ |
项目打包
1 | mvn package |
启动熔断器(带有熔断机制的消费者)
1 | java -jar target/spring-cloud-consumer-hystrix-0.0.1-SNAPSHOT.jar |

验证访问,轮询效果
1 | curl http://1.1.1.4:9001/hello/zx |
断开节点一的网络信息,再次访问(反馈消息发送失败)
1 | curl http://1.1.1.4:9001/hello/zx |
等待几秒钟,再次访问(多次访问只会反馈节点二的信息,不会在接收节点一的信息)
1 | curl http://1.1.1.4:9001/hello/zx |
恢复节点一的网络信息,等待几秒再次访问,就又会实现轮询效果
1 | curl http://1.1.1.4:9001/hello/zx |
部署zipkin链路追踪
部署前需要关掉之前启动的网关和生产者端口
修改配置文件
1 | cd /usr/local/spring-cloud-examples/spring-cloud-sleuth-zipkin/zipkin-server/ |
项目打包
1 | mvn package |
开启zipkin
1 | java -jar target/zipkin-server-1.0.0.BUILD-SNAPSHOT.jar |
打开eureka浏览器查看服务是否注册

部署生产者
节点一
1 | cd /usr/local/spring-cloud-examples/spring-cloud-sleuth-zipkin/spring-cloud-producer/ |
项目打包
1 | mvn package |
启动生产者
1 | java -jar target/spring-cloud-producer-1.0.0.BUILD-SNAPSHOT.jar |
部署网关
节点一
1 | cd /usr/local/spring-cloud-examples/spring-cloud-sleuth-zipkin/spring-cloud-zuul/ |
项目打包
1 | mvn package |
启动网关
1 | java -jar target/spring-cloud-zuul-1.0.0.BUILD-SNAPSHOT.jar |

打开节点二验证访问
1 | curl 1.1.1.3:8888/producer/hello?name=zx |
访问追踪首页
http://1.1.1.3:9000

部署微服务监控
主要功能:对微服务的存活性进行检测并进行邮件报警
停掉所有微服务端口
节点一
1 | cd /usr/local/spring-cloud-examples/spring-boot-admin-eureka/spring-cloud-eureka |
开启另一个终端
部署生产者
1 | source /etc/profile |

再次开启另一个终端
部署第二个生产者
1 | cd /usr/local/spring-cloud-examples/spring-boot-admin-eureka/spring-cloud-producer-2 |

打开浏览器搜索“qq邮箱”
登录2个邮箱
一个是发送邮件的
一个是接收邮件的
以下是:发送邮件的信箱的配置



复制以上授权
再次开启另一个终端
1 | cd /usr/local/spring-cloud-examples/spring-boot-admin-eureka/spring-boot-admin-server |
访问
1.1.1.3:8080

接着去收件人的qq邮箱中可以查看到发件人发送的邮件

