SpringBatch介绍：SpringBatch 是一个大数据量的并行处理框架。通常用于数据的离线迁移，和数据处理，⽀持事务、并发、流程、监控、纵向和横向扩展，提供统⼀的接⼝管理和任务管理;SpringBatch是SpringSource和埃森哲为了统一业界并行处理标准为广大开发者提供方便开发的一套框架。 官方地址：github.com/spring-projects/spring-batch SpringBatch 本身提供了重试，异常处理，跳过，重启、任务处理统计，资源管理等特性，这些特性开发者看重他的主要原因; SpringBatch 是一个轻量级的批处理框架; SpringBatch 结构分层，业务与处理策略、结构分离; 任务的运行的实例状态，执行数据，参数都会落地到数据库; 快速入门 pom.xml 添加 <dependency> <gro...

对于Spring Boot的Actuator模块相信大家已经不陌生了，尤其对于其中的/health、/metrics等强大端点已经不陌生（如您还不了解Actuator模块，建议先阅读《Spring Boot Actuator监控端点小结》）。但是，其中还有一个比较特殊的端点/info经常被大家所忽视，因为从最初的理解，它主要用来输出application.properties配置文件中通过info前缀来定义的一些属性，由于乍看之下可能想不到太多应用场景，只是被用来暴露一些应用的基本信息，而基本信息本身也可以在与Spring Cloud结合时作为服务治理的注册信息统一管理，所以这个端点的用处并不是很大。 然而实际上，该端点除了描述应用信息之外，也还可以用来描述Git版本信息，并且整合方法非常简单，下面我们就来看看如何使用/info端点暴露当前应用的Git版本信息。 POM配置首先，我们...

相信关注我们Spring Cloud中文社区（bbs.springcloud.com.cn）的朋友们最近已经在最新的横幅中发现了一个全新的社区：spring4all.com，相信从名字大家也能猜到该域名寓意Spring For All，那么我们为什么要重新创建这样一个社区呢？ 关于Spring For All截止至今天，我们的论坛注册用户也已经有1000+名了，在维护Spring Cloud中文社区的过程中，我们收到了各种各样关于Spring Boot和Spring Cloud的不同问题。虽然我们论坛的核心定位在Spring Cloud，但是很多问题并非由Spring Cloud本身负责的，而是其他Spring项目所负责。那么为了说清楚这些内容，还是需要用户对Spring的其他相关项目有一定的了解之后才能弄明白其基本原理。 事实上，我们在实战过程中，就算采用了Spring Boo...

上集我们阐述了使用微服务体系架构的关键障碍是领域模型，事务和查询，这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了，就涉及这三个难题。 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合（和服务）之间的数据一致性。 在本集中，我们将会向你介绍使用事件的时候遇到了一个新的问题，就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题，事件源是一种以事件为中心的业务逻辑设计和持久化的方法。之后，我们会阐述微服务架构下的查询困难的问题。然后向你介绍一种称为命令查询责任分离（CQRS）的方法来实现可扩展和高性能的查询。 可靠地更新状态和发布事件从表面上看，使用事件来保持聚合之间的一致性似乎很简单。 当一个服务创建或更新数据库的一个聚合时，它只是简单地发布一个事件。但是，这只...

在前几天发布的《Spring Cloud实战小贴士：Zuul统一异常处理（一）》一文中，我们详细说明了当Zuul的过滤器中抛出异常时会发生客户端没有返回任何内容的问题以及针对这个问题的两种解决方案：一种是通过在各个阶段的过滤器中增加try-catch块，实现过滤器内部的异常处理；另一种是利用error类型过滤器的生命周期特性，集中地处理pre、route、post阶段抛出的异常信息。通常情况下，我们可以将这两种手段同时使用，其中第一种是对开发人员的基本要求；而第二种是对第一种处理方式的补充，以防止一些意外情况的发生。这样的异常处理机制看似已经完美，但是如果在多一些应用实践或源码分析之后，我们会发现依然存在一些不足。 不足之处下面，我们不妨跟着源码来看看，到底上面的方案还有哪些不足之处需要我们注意和进一步优化的。先来看看外部请求到达API网关服务之后，各个阶段的过滤器是如何进行调度的：...

微服务架构变得越来越流行了。它是模块化的一种方法。它把一整块应用拆分成一个个服务。它让团队在开发大型复杂的应用时更快地交付出高质量的软件。团队成员们可以轻松地接受到新技术，因为他们可以使用最新且推荐的技术栈来实现各自的服务。微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性。 但微服务不是万能的。特别是在 领域模型、事务以及查询这几个地方，似乎总是不能适应拆分。或者说这几块也是微服务需要专门处理的地方，相对于过去的单体架构。 在这篇文章中，我会描述一种开发微服务的方法，这个方法可以解决这些问题。主要是通过领域模型设计，也就是DDD以及事件源（Event Sourcing）以及CQRS。让我们首先来看看开发人员在开发微服务的时候会遇到哪些问题吧。 微服务开发过程中的挑战模块化在开发大型复杂的应用的时候是非常有必要的。 现在许多应用大到一个人根本无法完成。而且复杂到...

在上一篇《Spring Cloud源码分析（四）Zuul：核心过滤器》一文中，我们详细介绍了Spring Cloud Zuul中自己实现的一些核心过滤器，以及这些过滤器在请求生命周期中的不同作用。我们会发现在这些核心过滤器中并没有实现error阶段的过滤器。那么这些过滤器可以用来做什么呢？接下来，本文将介绍如何利用error过滤器来实现统一的异常处理。 过滤器中抛出异常的问题首先，我们可以来看看默认情况下，过滤器中抛出异常Spring Cloud Zuul会发生什么现象。我们创建一个pre类型的过滤器，并在该过滤器的run方法实现中抛出一个异常。比如下面的实现，在run方法中调用的doSomething方法将抛出RuntimeException异常。 public class ThrowExceptionFilter extends ZuulFilter { pri...

通过之前发布的《Spring Cloud构建微服务架构（五）服务网关》一文，相信大家对于Spring Cloud Zuul已经有了一个基础的认识。通过前文的介绍，我们对于Zuul的第一印象通常是这样的：它包含了对请求的路由和过滤两个功能，其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。然而实际上，路由功能在真正运行时，它的路由映射和请求转发都是由几个不同的过滤器完成的。其中，路由映射主要通过pre类型的过滤器完成，它将请求路径与配置的路由规则进行匹配，以找到需要转发的目标地址；而请求转发的部分则是由route类型的过滤器来完成，对pre类型过滤器获得的路由地址进行转发。所以，过滤器可以说是Zuul实现API网关功能最为核心的部件，每一个进入Zuul的HTTP请求都会经过...

由于我们在之前所有的入门教程中，对于HTTP请求都采用了简单的接口实现。而实际使用过程中，我们的HTTP请求要复杂的多，比如当我们将Spring Cloud Zuul作为API网关接入网站类应用时，往往都会碰到下面这两个非常常见的问题： 会话无法保持 重定向后的HOST错误 本文将帮助大家分析问题原因并给出解决这两个常见问题的方法。 会话保持问题通过跟踪一个HTTP请求经过Zuul到具体服务，再到返回结果的全过程。我们很容易就能发现，在传递的过程中，HTTP请求头信息中的Cookie和Authorization都没有被正确地传递给具体服务，所以最终导致会话状态没有得到保持的现象。 那么这些信息是在哪里丢失的呢？我们从Zuul进行路由转发的过滤器作为起点，来一探究竟。下面是RibbonRoutingFilter过滤器的实现片段： public class RibbonRouting...

今天在博客的交流区收到一条不错的问题，拿出来给大家分享一下。具体问题如下： 因为项目里面用到了redis集群，但并不是用spring boot的配置方式，启动后项目健康检查老是检查redis的时候状态为down，导致注册到eureka后项目状态也是down。问下能不能设置spring boot不检查 redis的健康状态 "redis": { "status": "DOWN", "error": "org.springframework.data.redis.RedisConnectionFailureException: Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not g...

本文将继续讨论基于Consul的分布式锁实现。信号量是我们在实现并发控制时会经常使用的手段，主要用来限制同时并发线程或进程的数量，比如：Zuul默认情况下就使用信号量来限制每个路由的并发数，以实现不同路由间的资源隔离。 信号量(Semaphore)，有时被称为信号灯，是在多线程环境下使用的一种设施，是可以用来保证两个或多个关键代码段不被并发调用。在进入一个关键代码段之前，线程必须获取一个信号量；一旦该关键代码段完成了，那么该线程必须释放信号量。其它想进入该关键代码段的线程必须等待直到第一个线程释放信号量。为了完成这个过程，需要创建一个信号量VI，然后将Acquire Semaphore VI以及Release Semaphore VI分别放置在每个关键代码段的首末端，确认这些信号量VI引用的是初始创建的信号量。如在这个停车场系统中，车位是公共资源，每辆车好比一个线程，看门人起的就是...

我们在构建分布式系统的时候，经常需要控制对共享资源的互斥访问。这个时候我们就涉及到分布式锁（也称为全局锁）的实现，基于目前的各种工具，我们已经有了大量的实现方式，比如：基于Redis的实现、基于Zookeeper的实现。本文将介绍一种基于Consul 的Key/Value存储来实现分布式锁以及信号量的方法。 分布式锁实现基于Consul的分布式锁主要利用Key/Value存储API中的acquire和release操作来实现。acquire和release操作是类似Check-And-Set的操作： acquire操作只有当锁不存在持有者时才会返回true，并且set设置的Value值，同时执行操作的session会持有对该Key的锁，否则就返回false release操作则是使用指定的session来释放某个Key的锁，如果指定的session无效，那么会返回false，否则就...

这是一篇翻译，关于大家经常质疑的一个问题：API网关Zuul的性能。原文：NETFLIX ZUUL VS NGINX PERFORMANCE作者：STANISLAV MIKLIK 如今你可以听到很多关于“微服务”的信息。Spring Boot是一个用来构建单个微服务应用的理想选择，但是你还需要以某种方式将它们互相联系起来。这就是Spring Cloud试图解决的问题，尤其是Spring Cloud Netflix。它提供了各种组件，比如：Eureka服务发现与Ribbon客户端负载均衡的结合，为内部“微服务”提供通信支持。但是，如果你想要与外界通信时（你提供外部API，或只是从你的页面使用AJAX），将各种服务隐藏在一个代理之后是一个明智的选择。 常规的选择我们会使用Nginx作为代理。但是Netflix带来了它自己的解决方案——智能路由Zuul。它带有许多有趣的功能，它可以用于...

太久没有更新，一时不知道该从哪儿开始，索性就从一个小技巧开始吧。 在之前的《Spring Cloud构建微服务架构》系列博文中，我们经常会需要启动多个实例的情况来测试注册中心、配置中心等基础设施的高可用，也会用来测试客户端负载均衡的调用等。但是，我们一个应用只能有一个端口号，这就使得在本机测试的时候，不得不为同一个服务设置不同的端口来进行启动。 在本地用不同端口启动同一服务实例的方法有很多。最传统的我们可以粗暴地修改配置文件中的server.port属性来分别启动多个实例，这种方法虽然可以实现，但是非常的不方便。比较好的一种方法是在启动的时候通过命令的方式为server.port属性来设置不同的值，这样我们的配置文件就不用反复的进行修改了。 在本文中，我们将介绍另外一种方法：采用随机端口的方式来设置各个服务实例，这样我们不用去编辑任何命令就可以在本地轻松地启动多个实例了。 使用随...

由于最近在做监控方面的工作，因此也读了不少相关的经验分享。其中有这样一篇文章总结了一些基于Spring Boot的监控方案，因此翻译了一下，希望可以对大家有所帮助。 原文：Near real-time monitoring charts with Spring Boot Actuator, Jolokia and Grafana Spring Boot Actuator通过/metrics端点，以开箱即用的方式为应用程序的性能指标与响应统计提供了一个非常友好的监控方式。 由于在集群化的弹性环境中，应用程序的节点可以增长、扩展，并由非常大量的应用实例所组成。对于孤立节点的监控可能即费力又没有什么实际效果。所以，使用基于时间序列的数据聚合工具将获得更好的效果。 本文的目标在于找出一种仅需要通过工具和配置的方式就能实现的解决方案，来对Spring Boot Metrics实现基于时间序...