Zuul

不点蓝字，我们哪来故事？ 秒杀功能 参数校验 在任何时候，当你要处理一个应用程序的业务逻辑，数据校验是你必须要考虑和面对的事情。应用程序必须通过某种手段来确保输入进来的数据从语义上来讲是正确的。在通常的情况下，应用程序是分层的，不同的层由不同的开发人员来完成。很多时候同样的数据验证逻辑会出现在不同的层，这样就会导致代码冗余和一些管理的问题，比如说语义的一致性等。为了避免这样的情况发生，最好是将验证逻辑与相应的域模型进行绑定。 用 JSR 303 – Bean Validation 规范 ： Bean Validation 中的 constraint 表 1. Bean Validation 中内置的 constraint Constraint 详细信息 @Null 被注释的元素必须为 null @NotNull 被注释的元素必须不为 null @AssertTrue 被注释的元素必须为 true @AssertFalse 被注释的元素必须为 false @Min(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 @Max(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值 @DecimalMin(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 @DecimalMax(value) 被注释的元素必须是一个数字

目录 Eureka Ribbon和Feign Zuul Hystrix Config 总结如下 我们先认识一下SpringCloud的各个组件，然后知其所以然。 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用

背景 我们都知道，在微服务架构风格里，一个应用会被拆分成多个小的服务系统，并且这些小系统都可以自成体系，可以拥有自己的数据库、框架语言等。它们通常都可以提供接口来被各种应用程序调用。 但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中。 打个比方：要查看一个电商平台的商品详情页，这个商品详情页包括标题、价格、库存、评价等等，这些数据可能在不同的微服务系统之中，如下所示： • 产品 - 负责提供商品的标题，描述，规格等。 • 价格 - 负责对产品进行定价，价格策略计算，促销价等。 • 库存 - 负责产品库存。 • 评价 - 负责用户对商品的评论，回复等。 现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？ 由于用的是多个服务系统的架构，所以依靠单个数据库的 join 查询结果不可行，那么该怎么访问各个服务呢？ 按照微服务设计的指导原则，我们的微服务可能存在下面的问题： • 服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。 • 服务的划分可能随着时间而变化。 • 服务的实例或者Host+端口可能会动态的变化。 那么，对于前端的UI需求也可能会有以下几种： • 粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次

SpringCloud 学习总结（一） SpringCloud 学习总结（二） 服务容错保护Hystrix Hystix是Netflix开源的一个延迟和容错库，其中提供了基础的熔断功能，用于隔离访问远程服务、第三方库，防止出现级联失败。关于Hystrix更详细的原理，可以参考官方文档： https://github.com/Netflix/Hystrix/ 雪崩问题： 在微服务框架中，系统间都通过微服务进行调用，在微服务之间会存在这相互依赖关系。假设每个微服务运行在不同的进程中，依赖的调用只则需要使用远程调用方式。如果其中一个网络出现问题，或者延迟，此时，调用方式在不断的调用，后方的依赖会出现故障。当响应过多时，就可能出现雪崩效应，造成系统的崩溃。 下图中，我们可以看到微服务中，服务间复杂的调用关系，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路： 如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，某个服务出现异常： 例如：微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞： 服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。 Hystix解决雪崩问题： 线程隔离(服务降级)

作者：白羽毛 来源：toutiao.com/i6888099913867985422/ 我们先认识一下SpringCloud的各个组件，然后知其所以然。 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下

背景 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存：提升系统访问速度和增大系统能处理的容量 降级：当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉 限流：解决服务雪崩，级联服务发生阻塞时，及时熔断，防止请求堆积消耗占用系统的线程、IO等资源，造成其他级联服务所在服务器的崩溃 这里我们主要说一下限流，限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率就可以拒绝服务、等待、降级。 首先，我们需要去了解最基本的两种限流算法。 限流算法 漏桶算法 令牌桶算法 计算器算法 这里主要是提一下，详细了解限流算法请参考下面链接 https://www.cnblogs.com/hopeiscoming/p/12297528.html 限流框架 下面说一下现有流行的限流工具 guava Google的Guava工具包中就提供了一个限流工具类——RateLimiter。RateLimiter是基于“令牌通算法”来实现限流的。 hystrix hystrix主要是通过资源池以及信号量来限流，暂时能支持简单的限流 sentinel 限流比较主流的三种算法：漏桶，令牌桶，滑动窗口。而Sentinel采用的是最后一种，滑动窗口来实现限流的。当然sentinel不仅仅局限于限流

定义 灰度发布就是已一种平滑过渡的方式来发布，通过切换线上新旧版本之间的路由权重，逐步从旧版本切换到新版本；比如要上线新功能，首先只是更新少量的服务节点，通过路由权重，让少部分用户体验新版本，如果没有什么问题，再更新所有服务节点；这样可以在出现问题把影响面降到最低，保证了系统的稳定性。 灰度发布 一个系统往往有接入层比如nginx(Openresty)，网关层比如zuul，以及服务层比如各种rpc框架；在这几层都有路由功能，也就是说这几层都可以做灰度；接入层可以使用nginx+lua来实现灰度，网关层zuul可以结合ribbon来实现灰度，rpc框架如dubbo本身提供了路由功能可以直接做灰度处理；下面看看具体如何去实现； 接入层灰度 接入层我们这里使用功能更强大的Openresty，然后使用lua进行路由转发，相关的路由策略可以配置在分布式缓存redis里面，当然也可以持久化到数据库里面； 准备 准备一台Openresty，两台web服务器tomcat(端口分别是8081，8082)，以及redis；为了方便模拟在redis里面配置白名单，如果在白名单里面就走8082，不在则走8081； Openresty配置 需要在Openresty中配置支持lua，以及相关路由的lua脚本，nginx.conf配置如下： http { ... lua_package_path "

默认过滤的header spring-cloud-netflix-core-1.2.6.RELEASE-sources.jar!/org/springframework/cloud/netflix/zuul/filters/ZuulProperties.java /** * List of sensitive headers that are not passed to downstream requests. Defaults to a * "safe" set of headers that commonly contain user credentials. It's OK to remove * those from the list if the downstream service is part of the same system as the * proxy, so they are sharing authentication data. If using a physical URL outside * your own domain, then generally it would be a bad idea to leak user credentials. */ private Set<String> sensitiveHeaders = new

前言 过去十几年里，广义的“微服务”架构以其小团队快速创建和迭代服务带来的架构弹性、扩展性、敏捷性，天然匹配了互联网业务快速发展和变化的特点，在各大互联网公司取得了巨大的成功。时至云原生应用时代，已不再是是否采用微服务架构的问题，而是何时采用以及如何在生产上实战的问题。 今天分享的这份学习资料：讲解将如何基于Spring Cloud生态体系进行微服务实战的方方面面的细节都涵盖了，从这个意义上来讲，确实做到了“重新定义”。 本书内容有3大特色： 足够广：详细讲解了Spring Cloud的核心常用组件以及Spring Cloud的增强生态，针对生产实践中常见问题给出可落地的&*佳实践方案，无论您是初学者还是开发人员，还是架构师，都能从此书获益。 有深度：本书对涉及的Spring Cloud组件按照从入门、进阶、实战、扩展增强的顺序循序渐进进行剖析和讲解,帮助作者知其然并知其所以然，授之以渔。 重实践：注重生产实践，通过案例驱动，给出优秀的生产实践方案和优秀的生产配置，帮助读者快速落地企业微服务架构。 本书大牛出版: 本书由Spring Cloud中国社区官方撰写，基于Spring Cloud的Finchley.RELEASE版本，基于Spring Cloud的Finchley.RELEASE版本，核心成员来自原阿里、蚂蚁金服、京东金融等互联网企业，经验丰富。 本书内容有3大特色

九、zuul路由网关 概述 1.1 能干嘛 路由、过滤 路由基本配置 POM <dependencies> <!-- zuul路由网关 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> <!-- actuator监控 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- hystrix容错 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> <