#Spring Cloud

Spring Cloud
我们在构建分布式系统的时候，经常需要控制对共享资源的互斥访问。这个时候我们就涉及到分布式锁（也称为全局锁）的实现，基于目前的各种工具，我们已经有了大量的实现方式，比如：基于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，否则就...

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

Spring Cloud
去年在博客上连载了《Spring Cloud构建微服务架构》的系列博文，虽然这部分内容得到了不少关注者们的支持，但是不得不说这些内容只是适用于Spring Cloud入门阶段对各个组件的初步认识。所以，今年除了将会继续更新《Spring Cloud构建微服务架构》系列的连载之外，准备再开一个新系列：《SpringCloud实战小贴士》，该系列文章内容将会聚焦在下面三个点上： 常见问题的解析 构建使用的技巧 实战设计的思考 开篇：Spring Cloud的版本依赖关系之前在《聊聊Spring Cloud版本的那些事儿》一文中，我们已经介绍了Spring Cloud版本命名的由来以及版本号的规则，并列举了各个版本的依赖内容，以帮助我们选择合适的版本进行微服务实践。 由于Spring Cloud的发展速度非常快，版本的更新非常频繁，同时成体系化的中文文档与教程又比较缺乏，所以很多初学者...

Spring Cloud
从去年6月开始编写《Spring Cloud构建微服务架构》系列博文开始，受到了不少同行的关注与支持。随后也开通了多个交流群、创建了相关的论坛（http://bbs.springcloud.cn），虽然Spring Cloud在国内变得越来越火热，但是这一块相关的书籍在国内外一直都还是处于空白状态。由于官方文档过于概要和简略，对于一些初学者来说学习门槛较高，所以从去年开始编写这本详细介绍Spring Cloud的书籍。希望能够帮助广大Spring Cloud关注者学习和使用它来帮助我们快速的构建起企业级的微服务架构系统。 Spring Cloud下属子项目非常之多，本书并未能覆盖所有。因此，在这里附上目录说明以及一些目前已经发布在博客的内容供所有Spring Cloud的支持者参详。 《Spring Cloud实战》目录第一章 基础知识 什么是微服务架构 与单体系统的区别 如何实施微...

Spring Boot
在之前的所有Spring Boot和Spring Cloud相关博文中，都会涉及Spring Boot工程的创建。而创建的方式多种多样，我们可以通过Maven来手工构建或是通过脚手架等方式快速搭建，也可以通过《Spring Boot快速入门》一文中提到的SPRING INITIALIZR页面工具来创建，相信每位读者都有自己最喜欢和最为熟练的创建方式。 本文我们将介绍嵌入的Intellij中的Spring Initializr工具，它同Web提供的创建功能一样，可以帮助我们快速的构建出一个基础的Spring Boot/Cloud工程。 菜单栏中选择File=>New=>Project..，我们可以看到如下图所示的创建功能窗口。其中Initial Service Url指向的地址就是Spring官方提供的Spring Initializr工具地址，所以这里创建的工程实际上也...

Spring Cloud
当我们在Spring Cloud应用中使用Consul来实现服务治理时，由于Consul不会自动将不可用的服务实例注销掉（deregister），这使得在实际使用过程中，可能因为一些操作失误、环境变更等原因让Consul中存在一些无效实例信息，而这些实例在Consul中会长期存在，并处于断开状态。它们虽然不会影响到正常的服务消费过程，但是它们会干扰我们的监控，所以我们可以实现一个清理接口，在确认故障实例可以清理的时候进行调用来将这些无效信息清理掉。 开始以为只要简单的调用注销接口就能轻松完成，但是实际实践的发现并非如此。因此，分享一下整个实现过程以及中间遇到的一些坑。 借鉴Spring Cloud Consul在实现之初，先参考了Spring Cloud Consul在关闭程序时候实现的注销方法，具体如下： public class ConsulLifecycle extends A...

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/