2017

简介如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或软件即服务(SaaS)。12-Factor 为构建如下的 SaaS 应用提供了方法论: 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性。 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。 这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。 背景本文的贡献者者参与过数以百计的应用程序的开发和部署,并通过 Heroku 平台间接见证了数十万应用程序的开发,运作以及扩展的过程。 本文综合了我们关于 SaaS 应用几乎所有的经验和智慧,是开发此类应用的理想实践标准,并特...

前言在前两篇《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》和《Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)》中,我们对Hystrix提供的服务降级和依赖隔离有了基本的认识。下面我们将继续说说Hystrix的另外一个重要元件:断路器。 断路器断路器模式源于Martin Fowler的Circuit Breaker一文。“断路器”本身是一种开关装置,用于在电路上保护线路过载,当线路中有电器发生短路时,“断路器”能够及时的切断故障电路,防止发生过载、发热、甚至起火等严重后果。 在分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),直接切断原来的主逻辑调用。但是,在Hystrix中的断路器除了切断主逻辑的功能之外,还有更复杂的逻辑,下面我们来看...

前言在上一篇《Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)》中,我们已经体验了如何使用@HystrixCommand来为一个依赖资源定义服务降级逻辑。实现方式非常简单,同时对于降级逻辑还能实现一些更加复杂的级联降级等策略。之前对于使用Hystrix来实现服务容错保护时,除了服务降级之外,我们还提到过线程隔离、断路器等功能。那么在本篇中我们就来具体说说线程隔离。 依赖隔离“舱壁模式”对于熟悉Docker的读者一定不陌生,Docker通过“舱壁模式”实现进程的隔离,使得容器与容器之间不会互相影响。而Hystrix则使用该模式实现线程池的隔离,它会为每一个Hystrix命令创建一个独立的线程池,这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的服务。 通过对依赖服务的线程池隔离实现,可以带...

前言在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会出现因等待出现故障的依赖方响应而形成任务积压,线程资源无法释放,最终导致自身服务的瘫痪,进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患,那么相较传统架构就更加的不稳定。为了解决这样的问题,因此产生了断路器等一系列的服务保护机制。 针对上述问题,在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的,该框架目标在于通过控制那些访问远程系统、服务和第三方库的...

前言 此文所述处理方式为本人在实践过程中研究分析得出的一种解决方案。 本文不仅希望能为 SC 学习者提供一种如题问题的一种解决方案,并且希望通过本文引出各位 SC 的朋友对如题问题的共同探讨和最佳实践方案的分享。 场景及痛点 单个项目是通过 Jersey 来实现 restful 风格的架构 发生异常时异常信息总是提示没有回调方法,不能显示基础服务抛出的异常信息 暂时没有考虑发生异常之后进行回调返回特定内容 业务系统通过 feign 调用基础服务,基础服务是会根据请求抛出各种请求异常的(采用标准http状态码),现在我的想法是如果调用基础服务时发生请求异常,业务系统返回的能够返回基础服务抛出的状态码 当然基础服务抛出的请求异常不能触发 hystrix 的熔断机制 问题解决方案分析解决思路 通过网上一些资料的查询,看到很多文章会说 HystrixBadRequestException...

Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分。其中服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口;而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。Spring Cloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射,所以它除了适用于Spring构建的应用程序之外,也可以在任何其他语言运行的应用程序中使用。由于Spring Cloud Config实现的配置中心默认采用Git来存储配置信息,所以使用Spring Cloud Config构建的配置服务...

通过前两篇《Spring Cloud构建微服务架构:服务消费(基础)》和《Spring Cloud构建微服务架构:服务消费(Ribbon)》,我们已经学会了在Spring Cloud中基本的服务调用方式。本文我们将继续介绍Spring Cloud中的另外一个服务消费的工具:Spring Cloud Feign。 Spring Cloud FeignSpring Cloud Feign是一套基于Netflix Feign实现的声明式服务调用客户端。它使得编写Web服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。它具备可插拔的注解支持,包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign还扩展了对Spring MVC注解的支持,同时还整合了Ribbon和Eureka来提供均衡负载的HT...

通过上一篇《Spring Cloud构建微服务架构:服务消费(基础)》,我们已经学会如何通过LoadBalancerClient接口来获取某个服务的具体实例,并根据实例信息来发起服务接口消费请求。但是这样的做法需要我们手工的去编写服务选取、链接拼接等繁琐的工作,对于开发人员来说非常的不友好。所以,下来我们看看Spring Cloud中针对客户端负载均衡的工具包:Spring Cloud Ribbon。 Spring Cloud RibbonSpring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时,ribbonServerList会被Discov...

通过上一篇《Spring Cloud构建微服务架构:服务注册与发现》,我们已经成功地将服务提供者:eureka-client或consul-client注册到了Eureka服务注册中心或Consul服务端上了,同时我们也通过DiscoveryClient接口的getServices获取了当前客户端缓存的所有服务清单,那么接下来我们要学习的就是:如何去消费服务提供者的接口? 使用LoadBalancerClient在Spring Cloud Commons中提供了大量的与服务治理相关的抽象接口,包括DiscoveryClient、这里我们即将介绍的LoadBalancerClient等。对于这些接口的定义我们在上一篇介绍服务注册与发现时已经说过,Spring Cloud做这一层抽象,很好的解耦了服务治理体系,使得我们可以轻易的替换不同的服务治理设施。 从LoadBalancerCl...

Spring Boot中的双刃剑:自动化配置在之前发布的Spring Boot基础教程系列文章中,我们通过各种功能性示例体验了Spring Boot的自动化配置给我们所带来的超便利的新开发方式。但是,在一些情况下Spring Boot的自动化配置也会给我们惹来不少的麻烦,比如这些场景: 项目依赖复杂的情况下,由于依赖方的依赖组织不够严格,可能引入了一些实际我们不需要的依赖,从而导致我们的项目满足一些特定的自动化配置。 传统Spring项目转换为Spring Boot项目的过程中,由于不同的组织方式问题,引发自动化配置加载的错误,比如:通过xml手工组织的多数据源配置等。 上面这些原因都会导致不必要的自动化配置加载而导致应用无法启动或触发/health的健康检查不通过等问题。比如,我们在改造传统Spring项目到Spring Boot项目中碰到的一些错误: 六月 21, 2017 ...

已经有非常长的时间没有更新《Spring Cloud构建微服务架构》系列文章了,自从开始写Spring Cloud的专题内容开始就获得了不少的阅读量和认可,当然也有一些批评,其中也不乏一些很中肯的意见和深度的问题,对我来说也是进一步提高的契机,在此感谢所有关注我博客的读者们。 由于之前主要精力都花在的编写《Spring Cloud微服务实战》一书上,所以该系列文章就没有得到持续的维护和更新。由于漫长的写书过程和繁琐的出版流程,在本书一面世的时候,在版本上已经落后于当前的最新版本。虽然在书中前前后后加入了一些版本更新的注意事项,但是认识过程不是一蹴而就的,总是随着实践的深入慢慢发现的。所以,决定重写一下该系列文章,一方面将Spring Cloud的版本更新到Dalston,另一方面重新组织内容并增加一些之前没有写过的重要组件。希望通过这个系列,来帮助准备使用Spring Cloud的...

原文是 Martin Flower 于 2014 年 3 月 25 日写的《Microservices》。 微服务“微服务架构(Microservice Architecture)”一词在过去几年里广泛的传播,它用于描述一种设计应用程序的特别方式,作为一套独立可部署的服务。目前,这种架构方式还没有准确的定义,但是在围绕业务能力的组织、自动部署(automated deployment)、端智能(intelligence in the endpoints)、语言和数据的分散控制,却有着某种共同的特征。 “微服务(Microservices)”——只不过在满大街充斥的软件架构中的一新名词而已。尽管我们非常鄙视这样的东西,但是这玩意所描述的软件风格,越来越引起我们的注意。在过去几年里,我们发现越来越多的项目开始使用这种风格,以至于我们身边的同事在构建企业级应用时,把它理所当然的认为这是...

该系列课程中的示例代码使用springBatch版本为3.0.7;讲解可能会讲一些4.0.X的特性示例代码地址:https://git.oschina.net/huicode/springbatch-learn 在这里说到FlatFile的时候,其实XML,CSV,TXT三种文件格式中XML是不属于FlatFile 的,XML在Batch中是属于StaxEvent,但是本章主要讲述SpringBatch对于文件的读写,所以放到一起说明。 本文主要讲解通过SpringBatch来处理文本格式的文件,在实际的业务中也许文本文件转DB data或者DB data转文本文件的情形更多。 说明:在spring官方文档中的说明都是基于xml配置的方式来实现ItemReader、ItemWriter、Job、Step的配置的,为了符合springBoot的配置方式,示例代码都是配置代码实现的。...

关于Lombok,其实在网上可以找到很多如何使用的文章,但是很少能找到比较齐全的整理。我也一直寻思着想写一篇各个注解用法的总结,但是一直都没有付诸行动。今天看到了微信公众号”原力注入”推送的这篇文章,总结的内容很全,所以分享给所有关注我博客的朋友们。 Lombok简介 Project Lombok makes java a spicier language by adding ‘handlers’ that know >how to build and compile simple, boilerplate-free, not-quite-java code. 如Github上项目介绍所言,Lombok项目通过添加“处理程序”,使java成为一种更为简单的语言。作为一个Old Java Developer,我们都知道我们经常需要定义一系列的套路,比如定义如下的格式对象。 ...

之前在我博客的问答平台和Spring4All社区均有关于Spring Cloud的发布策略实现问题。虽然大家都给力很多不错的思路和建议,但是都没有Charles He的这篇文章详细。因此经得作者同意,在这里转载了该篇内容,为了更好的阅读体验,稍作一些格式调整,分享给更多Spring Cloud爱好者。更多关于Spring Cloud的干货内容请持续关注我的博客和Spring4All社区。 Spring Cloud 实践源码地址:https://github.com/charlesvhe/spring-cloud-practice 项目结构config 配置中心端口:8888,方便起见直接读取配置文件,生产环境可以读取git。application-dev.properties为全局配置。先启动配置中心,所有服务的配置(包括注册中心的地址)均从配置中心读取。 consumer 服...