微服务巡礼 Spring Cloud 体系使用(六)Spring Cloud Config

以前的章节提过,项目一多起来,各种配置随便复制粘贴,明明是一样的配置却要不断在各个项目中复制粘贴,而且复制粘贴中容易造成问题,万一其中的配置有问题,一个一个项目去找去修改错误的配置,那可是非常麻烦、非常令人沮丧。所以会出现配置中心,只需要修改部分地方,各个应用根据情况更新,著名的框架有携程的Apoll配置中心,而Spring Cloud自然也有自己的配置中心,Spring Cloud Config。 一睹为快 很明显,Spring Cloud Config是基于Git储存的分布式配置中心,使用Git作为配置仓库,如何将应用和配置服务中心联系起来。 构建配置中心 创建Spring Boot工程,命名随便,在pom.xml添加依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId>…

微服务巡礼 Spring Cloud 体系使用(五)Spring Cloud Zuul

前面几篇文章已经可以构建一个小型微服务,对个人开发者真是绰绰有余了,但个人开发者一般用PHP、Node这种语言来得比较快捷,用Java未免过重。 现在所有服务都被拆分一个一个应用,应用之间的通信通过接口访问,在后端有个基本认识,接口通信一定要有数据校验、鉴权的操作,一开始应用少做这种操作简单,但当应用集群上去之后,一个一个手动更改将会是噩梦,所有对于接口之间的访问操作我们有下面介绍的API网关 Spring Cloud Zuul 同理,我们引入这个组件,不可能像Ribbon、Feign引入到个体,但每个服务都会经过Eureka注册中心,Zuul根据这个特点,将API网关服务结合到Eureka服务上,可以获得所有实例服务信息,不再需要人工介入,对于路由规则的维护,Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射,大部分情况下可以满足需求。将鉴权、限制操作这些非强业务性的服务独立出来,使微服务更为专注业务开发,而运维只要集中精力在Eureka和Zuul上即可。 下面说说Zuul的简单使用。 构建网关 创建一个Spring-Boot基础工程,命为gateway,pom.xml文件为 <parent> <groupId>org.springframework.boot</groupId&…

微服务巡礼 Spring Cloud 体系使用(四)Spring Cloud Feign

前面的文章其实已经可以简单运行一个微服务应用,有服务器发现、负载均衡、断路器。而在平时开发中,我们发现负载均衡、断路器两者必定会出现,因为每个服务都必须包含负载均衡和错误处理,既然如此的设计那肯定有更高层次的封装整合这两个框架的使用。它就是Spring Cloud Fegin,基于Netflix Feign实现,除了提供这两者的强大功能之外,它还提供一种声明式的Web服务客户端方式。 通过Feign,可帮助我们更加便捷、优雅地调用HTTP API,在Spring Cloud中,使用Feign非常简单--创建一个接口,并在接口上添加一些注解,代码就完成,同时搞定对服务提供方的接口绑定,简化在使用Spring Cloud Ribbon时自行封装服务调用客户端的开发量。 快速入门 创建一个feign-consumer的工程,pom.xml文件如下 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId&…

微服务巡礼 Spring Cloud 体系使用(三)Spring Cloud Ribbon 和Spring Cloud Hystrix

其实这两个服务是非常复杂,但由于篇幅限制和时间精力,本人这里只简单介绍如何使用,源码分析这些需要靠读者们自己领悟了。 Spring Cloud Ribbon 上一节我们说了服务注册和服务提供,现在简单说一下服务消费,通过Spring Cloud Ribbon实现,是一套基于HTTP和TCP的客户端负载均衡工具,在Netflix Ribbon基础上实现。通过它,我们能轻松将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。要注意,它仅仅是工具类框架,不必像其他服务需要独立部署,但无处不在,所有微服务之间的调用转发都是通过Ribbon实现。 负载均衡的重要性不用说,面对突发大流量,保障系统正常运行非常重要一道关卡。 我们现在实现一个简单的Ribbon服务。 惯例pom.xml配置 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId>…

微服务巡礼 Spring Cloud 体系使用(二)Spring Cloud Eureka

服务治理是微服务架构中最为核心和基础的模块,散落在各处的服务要如何才能实现互相通信,一个控制中心非常重要(虽然不可避免使注册服务过于集中化),这个中心要实现发现散落各处的服务并将这些服务调用到需要的消费者。那么先根据我们自己的想象,要是自己做个控制中心,该怎样设计。 1、发现服务 2、服务调度 3、问题处理机制 那么按照这个思路,我们来学习Spring Cloud体系下服务治理怎样做。 Spring Cloud Eureka 是Spring Cloud Netflix微服务套件中的一部分,基于Netflix Eureka做二次封装,主要负责完成微服务架构中的服务治理功能。服务治理底层有很多选择,也可以选Zookeeper、dubbo(底层也是Zookeeper)。以前业务中只有一个实例中心SOA,维护这份地址调用配置基本是复制粘贴就搞定,除了各个api项目在静态配置如果要修改SOA地址比较麻烦之外,配个携程阿波罗配置分发中心其实还好,但因为中心只有两点关系,不存在需要经过中心调用的第三点,处理相对比较容易。 然而在微服务体系下,控制中心并不做任何业务处理,如果微服务应用不断增加,各个服务之间调用情况越来越多,如果还是靠人工配置调用关系会非常容易出错,如果要做集群、水平扩展,这些情况必是大大影响工作推进,运维压力大。那么这时,一个服务中心必须出现,相比散落各处的服务,只有一个服务的运维其实已经比较轻松。…

微服务巡礼 Spring Cloud 体系使用(一)Spring-Boot

微服务出现的时间并不长,是一个相对比较新的热点,这几年来有不少关于它的报道,本人以前也稍微听说过微服务,但并没有真正深入了解过相关概念,在工作中接触的机会并不多,平时学习也没有注意。正所谓百闻不如一见,公司最近引入微任务,一开始是打算使用Dubbo,经过权衡后打算使用Spring Cloud一站式全家桶应用减少学习和运维的成本,由于我们已经有一定Docker的使用积累,Spring Cloud推荐使用Docker部署的方式刚好切中我们的技术栈,我与Spring Cloud由此得以相识,并在使用中不断理解Spring Cloud和微服务概念。 相对来说,使用PHP的时间长过Java,由于天生的语言特性,配合Yii或者Laravel框架,接口开发速度比较可观,上线部署使用Docker和Walle都非常方便快速,业务快速迭代也能hold住,PHP 7自身性能也极为可观,因此都是以单体应用开发为主,一个单体应用提供总接口做成SOA服务,api端配合Swoole负责调用。回头想想这也是有微服务的影子,只是服务上的粗细度较为粗(事实上这个粗细度不好把握),业务的划分只是在内部逻辑上有明显区分,实际对外提供则是单一接口。 现在我们以微服务做比较,以前总服务接口中包含支付业务、普通业务、定时业务、活动业务等等各种各样的服务,包含在单一体系中,在长期业务迭代中,总体服务会变得越来越臃肿(所谓的技术债务,服务器的配置被迫越来越高)。达到一定程度后,在后面开发中会重构类似微服务的架构,将总服务拆分,支付业务成为一个SOA,…