Spring Cloud

package com.luheng.bloggatewayzuul.filter; import com.luheng.bloggatewayzuul.util.RedisUtil; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import org.springframework.cloud.netflix.zuul.filters.support.FilterConstants; import org.springframework.stereotype.Component; import javax.annotation.Resource; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @Component public class LoginFilter extends ZuulFilter { @Resource private RedisUtil redisUtil; @Override public String filterType() { return FilterConstants.PRE_TYPE;

作者：周童 来自酒店搜索报价中心，主要负责酒店报价缓存，计算相关系统的开发以及性能优化等工作，热爱摩旅。 一个习以为常的细节 之前在做 ReentrantLock 相关的试验，试验本身很简单，和本文相关的简化版如下：**（提示：以下代码均可左右滑动） 就是通过可重入锁的保护并行对共享变量进行自增。 突然想到一个问题： 共享变量 count 没有加 volatile 修饰，那么在并发自增的过程当中是如何保持内存立即可见的呢？ 上面的代码做自增肯定是没问题的，可见 LOCK 不仅仅保证了独占性，必定还有一种机制保证了内存可见性。 可能很多人和我一样，对 LOCK 的认知是如此 “理所应当”，以至于从没有去思考为什么。就好像每天太阳都会从东方升起而不觉得这有什么好质疑的。现在既然问到这儿了，那就准备一探究竟。 几个概念 Java Memory Model (JMM) 即 Java 内存模型，直接引用 wiki 定义： "The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model

作者：周童 来自酒店搜索报价中心，主要负责酒店报价缓存，计算相关系统的开发以及性能优化等工作，热爱摩旅。 一个习以为常的细节 之前在做 ReentrantLock 相关的试验，试验本身很简单，和本文相关的简化版如下：**（提示：以下代码均可左右滑动） 就是通过可重入锁的保护并行对共享变量进行自增。 突然想到一个问题： 共享变量 count 没有加 volatile 修饰，那么在并发自增的过程当中是如何保持内存立即可见的呢？ 上面的代码做自增肯定是没问题的，可见 LOCK 不仅仅保证了独占性，必定还有一种机制保证了内存可见性。 可能很多人和我一样，对 LOCK 的认知是如此 “理所应当”，以至于从没有去思考为什么。就好像每天太阳都会从东方升起而不觉得这有什么好质疑的。现在既然问到这儿了，那就准备一探究竟。 几个概念 Java Memory Model (JMM) 即 Java 内存模型，直接引用 wiki 定义： "The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model

作者：阮一峰 http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，目前的版本是2.0版。 本文对OAuth 2.0的设计思路和运行流程，做一个简明通俗的解释，主要参考材料为RFC 6749。 一、应用场景 为了理解OAuth的适用场合，让我举一个假设的例子。 有一个"云冲印"的网站，可以将用户储存在Google的照片，冲印出来。用户为了使用该服务，必须让"云冲印"读取自己储存在Google上的照片。 问题是只有得到用户的授权，Google才会同意"云冲印"读取这些照片。那么，"云冲印"怎样获得用户的授权呢？ 传统方法是，用户将自己的Google用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。这样的做法有以下几个严重的缺点。 （1）"云冲印"为了后续的服务，会保存用户的密码，这样很不安全。 （2）Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。 （3）"云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。 （4）用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。 （5）只要有一个第三方应用程序被破解

以我个人写的博客系统为例，请求其它微服务API。 一、添加Maven依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> 二、启动类增加@EnableFeignClients package com.springcloud.blog; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; import org.springframework.cloud.openfeign.EnableFeignClients; @SpringBootApplication @EnableEurekaClient @EnableFeignClients public class BlogAdminApplication { public static void main

来源： oschina 链接： https://my.oschina.net/u/4390731/blog/4288302

目录 1.前言 2.瘦身前的Jar包 3.解决方案 一、前言 Spring Boot部署起来虽然简单，如果服务器部署在公司内网，速度还行，但是如果部署在公网，部署起来实在头疼：编译出来的 Jar 包很大，如果工程引入了许多开源组件（Spring Cloud等），那就更大了。 这个时候如果想要对线上运行工程有一些微调，则非常痛苦。 二、瘦身前的Jar包 Tomcat在部署Web工程的时候，可以进行增量更新，Spring Boot也是可以的～ Spring Boot编译出来的Jar包中，磁盘占用大的，是一些外部依赖库（jar包），例如：进入项目工程根目录，执行 mvn clean install 命令，得到的Jar包，用压缩软件打开，目录结构如下： 整个Jar包 18.18 MB, 但是 BOOT-INF/lib 就占用了将近 18 MB： 三、解决方法 步骤1: 正常编译JAR包，解压出lib文件夹 POM文件如下： < build > < plugins > < plugin > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-maven-plugin </ artifactId > < configuration > < mainClass > com.johnnian

什么是网关 在微服务架构里，服务的粒度被进一步细分，各个业务服务可以被独立的设计、开发、测试、部署和管理。这时，各个独立部署单元可以用不同的开发测试团队维护，可以使用不同的编程语言和技术平台进行设计，这就要求必须使用一种语言和平台无关的服务协议作为各个单元间的通讯方式。 换句话说就是网关为所有的请求提供了统一的入口，方便我们对服务请求和响应做统一管理。 为什么要用网关 API 网关是一个处于应用程序或服务（提供 REST API 接口服务）之前的系统，用来管理授权、访问控制和流量限制等，这样 REST API 接口服务就被 API 网关保护起来，对所有的调用者透明。 什么是gateway Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。 gateway工作原理 客户端向Spring Cloud网关发出请求。如果网关处理程序映射确定请求与路由匹配

在 2.3.0 中对 Spring Boot 进行了相当重大的更改，这是使用 Gradle 而非 Maven 构建的项目的第一个版本。 Spring 的每个项目都独立的项目组在开发运营，在用户最常使用的白盒部分（例如 API 设计）保持一致性，对于用户不可见的黑盒部分，各个项目组选择自己适合工具没有统一的约定。 例如： 项目构建工具。Spring Framework 自 2012 年的 3.2.0 起就使用 Gradle 构建，而一年后开始使用 Spring Boot，此后不久又开始使用 Spring Cloud，两者都基于 Maven。 项目 构建工具 Spring Framework Gradle Spring Boot Maven Spring Cloud Maven 为什么要切换 Spring Boot 团队考虑由 Maven 切换到 Gradle 的主要原因 为了减少构建项目所需的时间 。在开发和测试过程中，等待构建完成所花费的时间增加了修复错误和实现新功能所花费的时间。 为了解决这个问题，团队曾尝试利用 Maven 对并行构建的支持。由于 Spring Boot 构建的复杂性，特别是对 Invoker 插件的使用，尝试失败。通过将构建分为四个部分来解决 CI 问题。首先构建项目的主要核心，然后并行构建三个独立的部分。但 CI 的构建仍需要一个小时或更长时间。此外

Spring Boot 默认支持 properties(.properties) 和 YAML(.yml .yaml ) 两种格式的配置文件，yml 和 properties 文件都属于配置文件，功能一样。 Spring Cloud 构建于 Spring Boot 之上，在 Spring Boot 中有两种上下文，一种是 bootstrap，另外一种是 application，下面列举这两种配置文件的区别 加载顺序 若application.yml 和bootstrap.yml 在同一目录下：bootstrap.yml 先加载 application.yml后加载 bootstrap.yml 用于应用程序上下文的引导阶段。bootstrap.yml 由父Spring ApplicationContext加载。 配置区别 bootstrap.yml 和 application.yml 都可以用来配置参数。 bootstrap.yml 用来程序引导时执行，应用于更加早期配置信息读取。可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。一旦bootStrap.yml 被加载，则内容不会被覆盖。 application.yml 可以用来定义应用级别的， 应用程序特有配置信息，可以用来配置后续各个模块中需使用的公共参数等。 属性覆盖问题 启动上下文时， Spring Cloud