Zuul

基于SpringCloud分布式架构 为什么要使用分布式架构 Spring Cloud 专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖 分布式/版本化配置 服务注册和发现 路由 Service-to-Service 调用 负载均衡 断路器 分布式消息传递 这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务。 这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差。 但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。 分布式基础组件 Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。 Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。 Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务

本篇讲述Spring Cloud 微服务及其组件的专业技术。微服务系统作为分布式系统的一种形式，.必然会带有分布式系统的各种弊病，因此本篇也会介绍分布式系统的一些常见知识，以更好满足企业构建系统的需求。 本篇从企业的真实需求出发，理论结合实际，深入讲解SpringCloud微服务和分布式系统的知识。文中既包括SpringCloud微服务的各类常用组件的讲解，又包括分布式系统的常用知识的介绍。 SpringCloud组件方面主要讲解服务注册和服务发现(Eureka) 、服务调用(Ribbon 和OpenFeign)、断路器(Hystrix 和Resilience4j)、网关(Zuul和Gateway)、配置(Config)、全链路追踪(Sleuth) 、微服务的监控(Admin)等;分布式系统方面主要讲解分布式数据库、分布式缓存、会话和权限以及发号机制等。本篇的实践部分通过Apache Thrift 讲解了远程过程调用(RPC)在分布式系统中的应用，并且分析了处理高并发的一些常用方法，最后还通过一个简单的实例讲解了微服务系统的搭建。 本篇篇幅有些长总共4大部分，20个章节： 第一部分概述和基础 第二部分Spring Cloud微服务 第三部分分布式技术 第四部分微服务系统实践 第一部分概述和基础 第1章分布式和微服务概述 第2章技术基础 第二部分Spring Cloud微服务

QuickStart 基于SpringCloud体系实现，简单购物流程实现，满足基本功能：注册、登录、商品列表展示、商品详情展示、订单创建、详情查看、订单支付、库存更新等等。 github源码地址： https://github.com/backkoms/simplemall 每个业务服务采用独立的MYSQL数据库，初期考虑用到如下组件： 服务注册、发现: eureka 配置管理:spring config , spring security 集群容错: hystrix（待实现） API网关: zuul（待实现） 服务负载:feign+ribbon api文档输出:swagger2 代码简化:lombok 消息队列:rabbitmq 分布式锁: redis （待实现） 链路跟踪:spring cloud sletuh ->zipkin 安全认证:oauth2/JWT(待实现) 服务监控:spring-boot-admin 各模块介绍 模块名称 端口 简介 admin-server 9002 服务监控中心，监控所有服务模块 conf-server 9004 分布式配置中心，结合spring-security/rabbitmq同时使用 eureka-server 9003 服务注册中心，提供服务注册、发现功能 sleuth-server 9001

数据库是docker做安装，应用也是docker做安装，所以数据库这里的配置不能写成这个样子 容器之间是不能通过127.0.0.1去访问的，虽然他们都是在同一台机器上。但是他们是两个完全不同的两个虚拟环境。 这些都是要变化的，所以我们要考虑多环境。 首先我们有两种方式可以去做，一种方式是SpringBoot里面本身给我们提供了。profile. 我们在provider里面有演示多个profile的形式。 这里我们就不使用profile的形式了。 以为这个数据库的地址可能是经常会变化的。profile更适合的是，你在测试环境、预发环境、生产环境，他们三个值相对固定，但是在每一个环境里面又不同， 举个例子，比如说我们logback的日志， 比如说开发环境，我们可以在dev的目录下， 测试环境可以在test之类的目录下，这种情况比较适合profile的形式。 这种可变的变量呢？ 用这种方式去引入，冒号后免的是默认值。 这形式是什么意思呢？它会读取我们的环境变量。MYSQL_HOST如果你的环境变量有它则就会读进来，如果没有默认值就是127.0.0.1 这些都是MySql给我们提供的一些基础的内容，大家如果不知道呢，可以对这块进行深入的了解。 这样就变成环境变量的引入形式了。 然后把cinema的服务也改了 hall服务也改 user服务 改的这四个 打包操作 直接打我们的父包工程就可以了

前言 “ 微服务 ” 架构在这几年被广泛传播， 变得非常火热. 以至于关于微服务架构相关的开源框架和工具都变得越来越活跃，比如： Net和xOSS、 Dubbo、 Apache T加ft 等。 Spring Cloud 也因为 Spring 社区在企业应用领域的广泛知名度和强大影响力， 受到了广大 架构师与开发者的高度关注。 从接触 Spring Cloud 开始， 我除了被其庞大的项目结构霞撼之外， 还被其所要完成的远大 目标所吸引。 该项目不同于其他 Spring 的优秀项目， 它不再是一个基础框架类， 而是一个更高层次的、 架构视角的综合性大型项目， 其目标旨在构建一套标准化的微服务解决方案， 让架构师、 开 发者在使用微服务理念构建应用系统的时候， 面对各个环节的问题都可以找到相应的组件来 处理。 引用网友戏称的一个比喻 ： Spring Cloud 可以说是 Spring 社区为微服务架构提供的一个“ 全家桶 ” 套餐。 由于 “ 套餐 ” 中的组件通过一个社区进行包装与整合， 使得 “ 套餐 ” 中各个组件之间的 配合变得更加和谐， 这可以有效减少我们在组件的选型和整合上花费的精力， 所以它可以帮 助我们快速构建起基础的微服务架构系统。 目录 第一章 （基础知识） 第二章 （微服务构建Springboot） 第三章 （服务治理： Spring Cloud Eureka）

今天我们来分享一下MongDB 整合SpringData 篇,小伙伴们准备好了吗? 一 . 环境搭建 1. 创建项目 1)创建maven项目 2) 确定项目坐标(组、标识、版本) 3)确定项目的位置 4)项目不存在,创建项目 2. 配置项目 1) 配置父项目 因为小喵使用的是Spring Could ,因此需要导入一下坐标 <!--1 确定spring boot的版本--> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.4.RELEASE</version> </parent> <!--2 确定版本--> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <spring-cloud-release.version>Greenwich.RELEASE</spring-cloud-release.version> </properties> <!-- 3 锁定sprig cloud版本-->

系统在生产环境出现问题时，排查问题最好的方式就是查看日志了，日志的记录尽量详细，这样你才能快速定位问题。 如果需要在Zuul中进行详细的日志记录，这两种日志必不可少。 o API请求信息 o API响应信息 前面有介绍过如何获取请求信息，文章请查看《Spring Cloud Zuul过滤器获取请求参数问题》。 今天正好又有一位朋友问我如何获取响应的数据，抽时间给大家写篇文章简单分享下。 熟悉Zuul的朋友都知道，Zuul中有4种类型过滤器，每种都有特定的使用场景，要想记录响应数据，那么必须是在请求路由到了具体的服务之后，返回了才有数据，这种需求就适合用post过滤器来实现了。 这边给大家介绍两种方式获取响应数据： 第一种 try { Object zuulResponse = RequestContext.getCurrentContext().get("zuulResponse"); if (zuulResponse != null) { RibbonHttpResponse resp = (RibbonHttpResponse) zuulResponse; String body = IOUtils.toString(resp.getBody()); System.err.println(body); resp.close(); RequestContext

cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关；但在2.x版本中，zuul的升级一直跳票，springcloud最后自己研发了一个网关代替Zuul，那就是SpringCloud Gateway。 概述 gateway是在spring生态系统之上构建的API网关服务，基于Spring 5, Spring Boot 2和Project Reactor等技术。gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等。 SpringCLoud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架。 作用 • 反向代理 • 鉴权 • 流量控制 • 熔断 • 日志监控 微服务架构中网关的位置 特性 • 基于spring Framework 5, Project Reactor 和 spring boot 2.0 进行构建； • 动态路由：能够匹配任何请求属性； • 可以对路由指定 Predicate（断言） 和 Filter（过滤器）； • 集成Hystrix的断路器功能； • 集成SPringCloud服务发现功能； • 易于编写的 Predicate（断言） 和 Filter（过滤器）； • 请求限流功能； • 支持路径重写。

github https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit spring-cloud-zuul-ratelimit 说明 spring-cloud-zuul-ratelimit是和zuul整合提供分布式限流策略的扩展 对请求的目标URL进行限流（例如：某个URL每分钟只允许调用多少次） 对客户端的访问IP进行限流（例如：某个IP每分钟只允许请求多少次） 对某些特定用户或者用户组进行限流（例如：非VIP用户限制每分钟只允许调用100次某个API等） 多维度混合的限流。此时，就需要实现一些限流规则的编排机制。与、或、非等关系。 支持的限流粒度 服务粒度 (默认配置，当前服务模块的限流控制) 用户粒度 用户限流的实现：如果你的项目整合 Shiro 或者 Spring Security 安全框架，那么会自动维护request域UserPrincipal，如果是自己的框架，请登录成功后维护request域UserPrincipal，才能使用用户粒度的限流。未登录默认是：anonymous ORIGIN粒度 (用户请求的origin作为粒度控制) 某个IP的客户端被限流并不影响其他客户端，即API网关对每个客户端限流是相互独立的 URL 接口粒度 (请求接口的地址作为粒度控制) 以上粒度自由组合，又可以支持多种情况。

问题场景： 一周前正常，现在不正常，通过curl 访问单个工程能显示链路。如果通过网关入口访问不显示。 回顾： 一周前将spring cloud的zuul网关改成gateway 排查： 看elk日志，gateway将 traceId 打印出来，但是工程没有配置zipkin。 猜测： gateway将 traceId传入到后端服务，但是没有将记录传入到zipkin存储。 解决： 将gateway配置zipkin，链路显示正常 来源： oschina 链接： https://my.oschina.net/xiaominmin/blog/4297703