Spring Cloud

Spring Cloud
当我们使用Spring Cloud Ribbon实现客户端负载均衡的时候，通常都会利用@LoadBalanced来让RestTemplate具备客户端负载功能，从而实现面向服务名的接口访问（原理可见《Spring Cloud源码分析（二）Ribbon》一文，如果对Spring Cloud中使用Ribbon进行服务消费还没有概念的话，建议先阅读《Spring Cloud构建微服务架构（二）服务消费者》一文。）。 下面的例子，实现了对服务名为hello-service的/hello接口的调用。由于RestTemplate被@LoadBalanced修饰，所以它具备客户端负载均衡的能力，当请求真正发起的时候，url中的服务名会根据负载均衡策略从服务清单中挑选出一个实例来进行访问。 @SpringCloudApplicationpublic class Application { ...

Spring Cloud
断断续续看Ribbon的源码差不多也有7-8天了，总算告一段落。本文记录了这些天对源码的阅读过程与一些分析理解，如有不对还请指出。 友情提示：本文较长，请选择一个较为舒适的姿势来阅读在之前介绍使用Ribbon进行服务消费的时候，我们用到了RestTemplate，但是熟悉Spring的同学们是否产生过这样的疑问：RestTemplate不是Spring自己就有的吗？跟Ribbon的客户端负载均衡又有什么关系呢？下面在本文，我们来看RestTemplate和Ribbon是如何联系起来并实现客户端负载均衡的。 首先，回顾一下之前的消费者示例：我们是如何实现客户端负载均衡的？仔细观察一下代码之前的代码，我们可以发现在消费者的例子中，可能就是这个注解@LoadBalanced是之前没有接触过的，并且从命名上来看也与负载均衡相关。我们不妨以此为线索来看看源码实现的机制。 从@LoadBal...

Spring Cloud
Spring Cloud Bus除了支持RabbitMQ的自动化配置之外，还支持现在被广泛应用的Kafka。在本文中，我们将搭建一个Kafka的本地环境，并通过它来尝试使用Spring Cloud Bus对Kafka的支持，实现消息总线的功能。由于本文会以之前Rabbit的实现作为基础来修改，所以先阅读《Spring Cloud构建微服务架构（七）消息总线》有助于理解本文。 Kafka简介Kafka是一个由LinkedIn开发的分布式消息系统，它于2011年初开源，现在由著名的Apache基金会维护与开发。Kafka使用Scala实现，被用作LinkedIn的活动流和运营数据处理的管道，现在也被诸多互联网企业广泛地用作为数据流管道和消息系统。 Kafka是基于消息发布/订阅模式实现的消息系统，其主要设计目标如下： 消息持久化：以时间复杂度为O(1)的方式提供消息持久化能力，即使对T...

Spring Cloud
先回顾一下，在之前的Spring Cloud Config的介绍中，我们还留了一个悬念：如何实现对配置信息的实时更新。虽然，我们已经能够通过/refresh接口和Git仓库的Web Hook来实现Git仓库中的内容修改触发应用程序的属性更新。但是，若所有触发操作均需要我们手工去维护Web Hook中的应用位置的话，这随着系统的不断扩张，会变的越来越难以维护，而消息代理中间件是解决该问题最为合适的方案。是否还记得我们在介绍消息代理中的特点时有提到过这样一个功能：消息代理中间件可以将消息路由到一个或多个目的地。利用这个功能，我们就能完美的解决该问题，下面我们来说说Spring Cloud Bus中的具体实现方案。 在《Spring Boot中使用RabbitMQ》一文中，我们已经介绍了关于消息代理、AMQP协议以及RabbitMQ的基础知识和使用方法。下面我们开始具体介绍Spring C...

Spring Cloud
本文接之前的《Spring Cloud构建微服务架构（四）分布式配置中心》，继续来说说Spring Cloud Config的使用。 先来回顾一下，在前文中我们完成了什么： 构建了config-server，连接到Git仓库 在Git上创建了一个config-repo目录，用来存储配置信息 构建了config-client，来获取Git中的配置信息 在本文中，我们继续来看看Spring Cloud Config的一些其他能力。 高可用问题传统作法通常在生产环境，Config Server与服务注册中心一样，我们也需要将其扩展为高可用的集群。在之前实现的config-server基础上来实现高可用非常简单，不需要我们为这些服务端做任何额外的配置，只需要遵守一个配置规则：将所有的Config Server都指向同一个Git仓库，这样所有的配置内容就通过统一的共享文件系统来维护，而客户...

Spring Cloud
看过之前文章的朋友们，相信已经对Eureka的运行机制已经有了一定的了解。为了更深入的理解它的运作和配置，下面我们结合源码来分别看看服务端和客户端的通信行为是如何实现的。另外写这篇文章，还有一个目的，还是希望鼓励大家能够学会学习和研究的方法，由于目前Spring Cloud的中文资料并不多，并不是大部分的问题都能找到现成的答案，所以其实很多问题给出一个科学而慎重的解答也都是花费研究者不少精力的。 在看具体源码前，我们先回顾一下之前我们所实现的内容，从而找一个合适的切入口去分析。首先，服务注册中心、服务提供者、服务消费者这三个主要元素来说，后两者（也就是Eureka客户端）在整个运行机制中是大部分通信行为的主动发起者，而注册中心主要是处理请求的接收者。所以，我们可以从Eureka的客户端作为入口看看它是如何完成这些主动通信行为的。 我们在将一个普通的Spring Boot应用注册到Eu...

Spring Cloud
继续昨天说的计划，解惑一下收到比较多的问题。 有朋友问“为什么在很多文章中，大家引用的Spring版本名字都不一样呢？比如：Angel.SR6，Brixton.SR5等等，它们都有什么区别呢？”，今天我们就聊聊这个轻松一些的话题，说说Spring Cloud版本的那些事儿。 版本命名之前提到过，Spring Cloud是一个拥有诸多子项目的大型综合项目，原则上其子项目也都维护着自己的发布版本号。那么每一个Spring Cloud的版本都会包含不同的子项目版本，为了要管理每个版本的子项目清单，避免版本名与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。 这些版本名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Angel，第二个Release版本：Brixton，以此类推…… 版本号经过上面的解释，不难猜出，之前所提到的A...

Spring Cloud
近期因工作原因减缓了更新频率，同时为了把Spring Cloud中文社区搭建起来也费了不少时间，几乎每天都在挤牙膏般的凑时间出来做一些有意义的事。未能按原计划更新博文，在此对持续关注我博客的朋友们深表歉意。 之前在写Spring Cloud系列文章的时候，列过一个较粗的计划，现在由于收到不少反馈和问题，因此准备做一些调整，先将一些大家关注较为集中的点拉出来写一些内容。 今天这篇主要就说说Eureka Server的高可用问题。 前言在Spring Cloud系列文章的开始，我们就介绍了服务注册与发现，其中，主要演示了如何构建和启动服务注册中心Eureka Server，以及如何将服务注册到Eureka Server中，但是在之前的示例中，这个服务注册中心是单点的，显然这并不适合应用于线上生产环境，那么下面在前文的基础上，我们来看看该如何构建高可用的Eureka Server集群。 单...

Spring Cloud
前段时间，开了个关于Spring Cloud的交流群，短短两周时间就聚集了一批爱好者与实践者，每天在交流群中大家都进行着各种不同深度的探讨，但是这些高质量的聊天记录无法被搜索引擎收纳，导致很多不错的研究内容无法分享给网络上打算使用Spring Cloud或正在使用Spring Cloud的开发者们。 因此一直谋划着要创建一个针对Spring Cloud的中文社区，在此，欢迎所有对微服务架构、对Spring Cloud感兴趣的架构师、程序猿们关注我们社区的发展，可以在这里分享您的使用经验、或是在这里求助您遇到的问题等等，一起来推进和布道Spring Cloud架构体系在企业中的应用。 传送门：http://bbs.springcloud.com.cn/

Spring Cloud
最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务架构。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的。 目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。 那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？ 以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。 Round 1：背景 Dubbo，是阿里巴巴服...

Spring Cloud
通过之前几篇Spring Cloud中几个核心组件的介绍，我们已经可以构建一个简略的（不够完善）微服务架构了。比如下图所示： 我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。本文我们把焦点聚集在对外服务这块，这样的实现是否合理，或者是否有更好的实现方式呢？ 先来说说这样架构...

Spring Cloud
Spring Cloud Config为服务端和客户端提供了分布式系统的外部化配置支持。配置服务器为各应用的所有环境提供了一个中心化的外部配置。它实现了对服务端和客户端对Spring Environment和PropertySource抽象的映射，所以它除了适用于Spring构建的应用程序，也可以在任何其他语言运行的应用程序中使用。作为一个应用可以通过部署管道来进行测试或者投入生产，我们可以分别为这些环境创建配置，并且在需要迁移环境的时候获取对应环境的配置来运行。 配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。当然他也提供本地化文件系统的存储方式，下面从这两方面介绍如何使用分布式配置来存储微服务应用多环境的配置内容。 构建Config Server通过Spring Cloud构建一个Config S...

Spring Cloud
在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，最终导致自身服务的瘫痪。 举个例子，在一个电商网站中，我们可能会将系统拆分成，用户、订单、库存、积分、评论等一系列的服务单元。用户创建一个订单的时候，在调用订单服务创建订单的时候，会向库存服务来请求出货（判断是否有足够库存来出货）。此时若库存服务因网络原因无法被访问到，导致创建订单服务的线程进入等待库存申请服务的响应，在漫长的等待之后用户会因为请求库存失败而得到创建订单失败的结果。如果在高并发情况之下，因这些等待线程在等待库存服务的响应而未...

Spring Cloud
在上一篇《Spring Cloud构建微服务架构（一）服务注册与发现》中，我们已经成功创建了“服务注册中心”，实现并注册了一个“服务提供者：COMPUTE-SERVICE”。那么我们要如何去消费服务提供者的接口内容呢？ RibbonRibbon是一个基于HTTP和TCP客户端的负载均衡器。Feign中也使用Ribbon，后续会介绍Feign的使用。 Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。 下面我们通过实例看看如何...

Spring Cloud
Spring Cloud简介Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品），比如：Spring Cloud Config、Spring Cloud Netflix、Spring Cloud CloudFoundry、Spring Cloud AWS、Spring Cloud Security、Spring Cloud Commons、Spring Cloud Zookeeper、Spring Cloud CLI等项目。 微服务架构“微服务架构”在这几年非常的火热，以至于关于微服务架构相关的产品社区也变得越来越活跃...