• SpringBoot入门教程
  • SpringBoot进阶教程
  • Spring系列源码分析
  • 等等…(后面之前写下来未发布的SpringCloudSpringCoud Gateway系列的文章应该也放到这个专栏里面)。

如果你更喜欢docsify文档风格的阅读体验,可以访问spring.throwx.cn,同步更新:

此专栏有任何问题,可以联系我,如果不是上班时间或者太忙,我会第一时间回应。

前提

作为Java开发者,很多场景下会使用SpringBoot开发Web应用,目前微服务主流SpringCloud全家桶也是基于SpringBoot搭建的。SpringBoot应用部署到服务器上,需要编写运维管理脚本。本文尝试基于经验,总结之前生产使用的Shell脚本,编写一个可以复用的SpringBoot应用运维脚本,从而极大减轻SpringBoot应用启动、状态、重启等管理的工作量。本文的Shell脚本在CentOS7中正常运行,其他操作系统不一定适合。如果对一些基础或者原理不感兴趣可以拖到最后,直接拷贝脚本使用。

阅读全文

前提

最近创业公司的项目组基于业务需要,开发一套新的微服务,考虑到选用的组件必须是主流、社区活跃、生态完善以及方便迁移到云上等因素,引入了SOFAStack全家桶。微服务开发里面,一个很重要的功能就是服务发现与注册,笔者花了点时间做了一个SOFABootSOFARpc结合Nacos实现微服务发现注册与远程调用的示例。

阅读全文

前提

最近由于业务发展,需要调研一套完善和主流的基础架构,进行中台化(微服务)的实施,考虑到技术栈切换到SOFAStack。既然整个体系都切换到蚂蚁金服的技术栈,那么自然考虑一些基础组件如服务注册发现、配置管理等都切换为阿里的技术栈。考虑到目前比较热的服务发现组件是Nacos,需要调研SpringBoot服务接入Nacos的可行性,为以后强制要求新服务使用SOFAStack + Nacos的技术栈进行服务开发打下基础。

阅读全文

前提

当我们在生产环境部署了SpringBoot应用的时候,虽然可以通过Jenkins的构建状态和Linuxps命令去感知应用是否在新的一次发布中部署和启动成功,但是这种监控手段是运维层面的。那么,可以提供一种手段能够在应用层面感知服务在新的一次发布中的构建部署和启动是否成功吗?这个问题笔者花了一点时间想通了这个问题,通过这篇文章提供一个简单的实现思路。

阅读全文

前提

在日常使用SpringMVC进行开发的时候,有可能遇到前端各种类型的请求参数,这里做一次相对全面的总结。SpringMVC中处理控制器参数的接口是HandlerMethodArgumentResolver,此接口有众多子类,分别处理不同(注解类型)的参数,下面只列举几个子类:

  • RequestParamMethodArgumentResolver:解析处理使用了@RequestParam注解的参数、MultipartFile类型参数和Simple类型(如longint等类型)参数。
  • RequestResponseBodyMethodProcessor:解析处理@RequestBody注解的参数。
  • PathVariableMapMethodArgumentResolver:解析处理@PathVariable注解的参数。
阅读全文

前提

前段时间在做一个对外的网关项目,涉及到加密和解密模块,这里详细分析解决方案和适用的场景。为了模拟真实的交互场景,先定制一下整个交互流程。第三方传输(包括请求和响应)数据报文包括三个部分:

  • 1、timestamp,long类型,时间戳。
  • 2、data,String类型,实际的业务请求数据转化成的Json字符串再进行加密得到的密文。
  • 3、sign,签名,生成规则算法伪代码是SHA-256(data=xxx&timestamp=11111),防篡改。

为了简单起见,加密和解密采用AES,对称秘钥为"throwable"。上面的场景和加解密例子仅仅是为了模拟真实场景,安全系数低,切勿直接用于生产环境。

阅读全文

前提

在微服务架构中,下游依赖出现问题如果上游调用方不做请求降级处理,下游的异常依赖没有被隔离,很有可能出现因为一两个服务或者小到一两个接口异常导致上游所有服务不可用,甚至影响整个业务线。请求降级处理目前比较主流的依然是Netfilx出品的HystrixHystrix的工作原理是:

  • 把请求基于线程池或者信号量隔离,一旦下游服务在指定配置的超时时间内无法响应会进入预设或者默认的降级实现。
  • 每个请求的状态都会记录下来,在一个滑动窗口内处理失败的比率超过设定的阈值就会触发熔断器(Circle Breaker)开启,熔断器开启之后所有请求都会直接进入预设或者默认的降级逻辑。
  • 熔断器打开后,且距离熔断器打开的时间或上一次试探请求放行的时间超过设定值,熔断器器进入半开状态,允许放行一个试探请求。
  • 请求成功率提高后,基于统计数据确定对熔断器进行关闭,所有请求正常放行。

这里不对Hystrix的细节做更深入分析,而是接着谈谈Spring Cloud Gateway中如何使用Hystrix,主要包括内置的Hystrix过滤器和定制过滤器结合Hystrix实现我们想要的功能。除了要引入spring-cloud-starter-gateway依赖之外,还需要引入spring-cloud-starter-netflix-hystrix

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
    </dependencies>    
阅读全文

前提

  • 本文编写的时候使用的Spring Cloud Gateway版本为当时最新的版本Greenwich.SR1

我们在使用Spring Cloud Gateway的时候,注意到过滤器(包括GatewayFilterGlobalFilter和过滤器链GatewayFilterChain),都依赖到ServerWebExchange

public interface GlobalFilter {

    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

public interface GatewayFilter extends ShortcutConfigurable {

	Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

public interface GatewayFilterChain {

    Mono<Void> filter(ServerWebExchange exchange);
}    

这里的设计和Servlet中的Filter是相似的,当前过滤器可以决定是否执行下一个过滤器的逻辑,由GatewayFilterChain#filter()是否被调用来决定。而ServerWebExchange就相当于当前请求和响应的上下文。ServerWebExchange实例不单存储了RequestResponse对象,还提供了一些扩展方法,如果想实现改造请求参数或者响应参数,就必须深入了解ServerWebExchange

阅读全文

前提

我们平时在用SpringMVC的时候,只要是经过DispatcherServlet处理的请求,可以通过@ControllerAdvice@ExceptionHandler自定义不同类型异常的处理逻辑,具体可以参考ResponseEntityExceptionHandlerDefaultHandlerExceptionResolver,底层原理很简单,就是发生异常的时候搜索容器中已经存在的异常处理器并且匹配对应的异常类型,匹配成功之后使用该指定的异常处理器返回结果进行Response的渲染,如果找不到默认的异常处理器则用默认的进行兜底(个人认为,Spring在很多功能设计的时候都有这种“有则使用自定义,无则使用默认提供”这种思想十分优雅)。

SpringMVC中提供的自定义异常体系在Spring-WebFlux中并不适用,其实原因很简单,两者底层的运行容器并不相同。WebExceptionHandlerSpring-WebFlux的异常处理器顶层接口,因此追溯到子类可以追踪到DefaultErrorWebExceptionHandlerSpring Cloud Gateway的全局异常处理器,配置类是ErrorWebFluxAutoConfiguration

阅读全文

前提

最近在做老系统的重构,重构完成后新系统中需要引入一个网关服务,作为新系统和老系统接口的适配和代理。之前,很多网关应用使用的是Spring-Cloud-Netfilx基于Zuul1.x版本实现的那套方案,但是鉴于Zuul1.x已经停止迭代,它使用的是比较传统的阻塞(B)IO + 多线程的实现方案,其实性能不太好。后来Spring团队干脆自己重新研发了一套网关组件,这个就是本次要调研的Spring-Cloud-Gateway

简介

Spring Cloud Gateway依赖于Spring Boot 2.0, Spring WebFlux,和Project Reactor。许多熟悉的同步类库(例如Spring-DataSpring-Security)和同步编程模式在Spring Cloud Gateway中并不适用,所以最好先阅读一下上面提到的三个框架的文档。

Spring Cloud Gateway依赖于Spring BootSpring WebFlux提供的基于Netty的运行时环境,它并非构建为一个WAR包或者运行在传统的Servlet容器中。

阅读全文

前提

org.springframework.core.env.Environment是当前应用运行环境的公开接口,主要包括应用程序运行环境的两个关键方面:配置文件(profiles)和属性。Environment继承自接口PropertyResolver,而PropertyResolver提供了属性访问的相关方法。这篇文章从源码的角度分析Environment的存储容器和加载流程,然后基于源码的理解给出一个生产级别的扩展。

本文较长,请用一个舒服的姿势阅读。

阅读全文

前提

最近公司在联合运维做一套全方位监控的系统,应用集群的技术栈是SpringCloud体系。虽然本人没有参与具体基础架构的研发,但是从应用引入的包和一些资料的查阅大致推算出具体的实现方案,这里做一次推演,详细记录一下整个搭建过程。

阅读全文