余思博客

写在前面前面学习了Spring Cloud Bus整合RabbitMQ的相关内容，接下来开始学习Spring Cloud Bus整合Kafka，同样也能实现消息总线的功能。 Kafka简介Kafka是一个由LinkedIn开发的分布式消息系统，于2011年年初开源，现在由Apache基金会负责维护与开发。Kafka使用Scala语言编写，被用作LinkedIn的活动流和运营数据处理的管道，现在也被许多企业广泛用作数据流管道和消息系统。 Kafka设计目标Kafka是基于消息发布-订阅模式实现的消息系统，其主要的设计目标如下：（1）消息持久化。以时间复杂度为O(1)的方式提供消息持久化能力，对于TB级别以上的数据也能保证常数时间复杂度的访问性能。（2）高吞吐。在廉价的商用机器上也可以支持单机每秒1万条以上的吞吐量。（3）分布式。支持消息分区以及分布式消费，并保证分区内的消息顺序。（4）跨平台。支持不同语言的客户端，如Java、PHP、Python等。（5）实时性。支持实时数据处理和离线数据处理。（6）伸缩性。支持水平扩展。 Kafka中的一些基本概念同样Kafka中有一些比较重要的基础概 ...

写在前面前面我们只是单纯的介绍了消息代理、AMQP以及RabbitMQ的基础知识和基本使用，接下来我们开始学习Spring Cloud Bus组件的配置，并一个Spring Cloud Bus与Spring Cloud Config结合的例子来实现配置信息的实时更新。 不过在此之前需要回忆一下前面的知识，在学习Spring Cloud Config的时候我们学习了如何实现配置信息的实时更新：通过使用POST方法来提交/refresh接口或者Git仓库的Web Hook来手动触发，进而实现Git仓库中的内容修改导致程序属性的更新。显然这种方式是不合理的，所有操作都是人工进行，随着系统的不断扩展，这势必会导致维护成本的增加，使用消息代理中间件可以很好的解决这个问题，因为它可以将消息路由到一个或者多个目的地。 由于Spring Cloud基于Spring Boot，而在前面我们已经进行了Spring Boot和RabbitMQ的整合，那么接下来就是在Spring Cloud Bus中使用RabbitMQ了。 请注意，这里不需要创建新的应用，而是使用到前面关于Spring Cloud Conf ...

写在前面在微服务的架构系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题，让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，因此我们称之为消息总线。在消息总线上的各个实例都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，如配置信息的变更或者其他一些管理操作。 在前面我们学习了分布式配置组件Spring Cloud Config，接下来开始学习另一个和它同等重要的组件：消息总线SpringCloud Bus，不过我们会从基础的消息代理入手，一步步的由浅入深学习Spring Cloud Bus这个消息总线组件。通过使用Spring Cloud Bus消息总线，我们可以非常容易的搭建起消息总线，同时实现了一些消息总线中的常用功能，如配合Spring Cloud Config实现微服务应用配置信息的动态更新等。 消息代理消息代理(Message Broker)是一种消息验证、传输、路由的架构模式。它在应用程序之间起到通信调度并最小化应用之间的依赖的作用，使得应用可以高效地解耦通信过程。消息代理是一个中间件产品，它的核心是一个消息的路由程序 ...

写在前面前面我们对Spring Cloud Config分布式配置中心的服务端进行了较为细致的学习，接下来开始学习对于客户端的配置。 URI指定配置中心在前面我们在config-client项目的bootstrap.properties启动文件中添加了spring.cloud.config.uri=http://localhost:4001/这一参数，用于指定配置中心的地址。那么问题来了，为什么需要通过手动来设置配置中心的地址呢？因为Spring Cloud Config的客户端在启动的时候，默认会从工程的classpath中加载配置信息并启动应用。只有我们配置了spring.cloud.config.uri这一参数的时候，客户端应用才会尝试连接Spring Cloud Config的服务端来获取远程配置信息并初始化Spring环境配置。同时在前面也多次提到，必须将该参数配置在bootstrap.properties启动文件、环境变量或是其他优先级高于应用Jar包内的配置信息中，这样客户端才能正确加载到远程配置。 如果开发者不配置spring.cloud.config.uri这一参数， ...

健康监测当使用占位符来配置URI的时候，Spring Cloud Config会为配置中心服务端创建一个健康监测器，该检测器中默认构建了一个application为app的仓库。而根据之前的配置规则：{application}-config.git，该检测器会不断地检查https://github.com/licheetools/app-config仓库是否可以连通（此处的app就是上面的{application}）。此时我们可以访问配置中心的/health端点来查看它的健康状态，如果无法连通https://github.com/licheetools/app-config仓库，那么配置中心的可用状态将是DOWN。虽然我们依然可以通过URI的方式来访问该配置中心，但是当我们将这个配置中心当做一个服务来使用的时候，那么它的状态将会影响到它的服务可用性判断，因此了解它的健康监测配置对于微服务架构来说显得尤为重要。 其实我们可以直接在Git仓库中创建一个名为app-config的配置库，让健康检测器能够访问到它。当然了，我们也可以配置一个实际存在的仓库来进行连通检测。举个例子，笔者已经在Gi ...

写在前面在前面我们成功的搭建起一个具备基本结构的配置管理服务端和客户端，也学习了一些基本的配置，接下来将进一步深入学习Spring Cloud Config中有关服务端的知识。 基础架构在学习服务端相关配置信息之前，先复习一下之前搭建的入门例子中使用的基础架构，如下图所示： 接下来好好分析一下上述架构，可以看到里面包含4种组件，5个元素，相关的分析如下所示： 远程Git仓库：用于存储配置文件，一般自己学习可以使用GitHub或者Gitee，公司一般会基于GitLab搭建属于自己的Git服务器。这里存放的就是针对应用名为config-server，但是application名为envy的多环境配置文件：envy-{ profile }.yml。 Config Server分布式配置中心：即此处构建的分布式配置中心（项目名称为config-server），里面配置了所要连接的Git仓库的位置、账户、密码等信息。 Config Server本地Git仓库：在Config Server的文件系统中，每次客户端请求获取配置信息时，Config Server从Git仓库中获取最新配置到本地，然 ...

SpringCloud Config是一个全新项目，用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，它分为服务端和客户端这两个部分。（建议使用properties格式的配置文件） 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口。 客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。 SpringCloud Config实现了对服务端和客户端中环境变量和属性配置的抽象映射，因此它除了适用于Spring构建的应用程序，而且还可以在其他任何语言运行的应用程序中使用。 SpringCloud Config实现的配置中心默认采用Git来存储配置信息，所以使用SpringCloud Config构建的配置服务器，天然就支持对微服务应用配置信息的版本管理，而且可以通过Git客户端工具来方便地管理和访问配置内容。当然它也提供了对其他存储方式的支持，如SVN仓库，本地化文件系统。 快速入门接下来将演示如何构建一个 ...

写在前面在前面我们学习了Spring Cloud Zuul中的两类路由功能：传统路由方式和面向服务的路由方式的简单使用，接下来将进一步学习路由的相关知识。 传统路由配置所谓的传统路由配置其实就是不依赖于服务发现机制的情况，也就是直接在配置文件中来具体指定每个路由表达式与服务实例的映射关系，进而实现API网关对外部请求的路由。 既然不依赖服务治理框架提供的服务发现功能，那么在实际情况中需要根据服务实例的数量来采取不同的配置方式，进而实现路由规则。 单实例配置对于单实例的配置，我们可以通过zuul.routes.<route>.path和zuul.routes.<route>.url参数对的方式来进行配置，如下所示： 12345zuul: routes: user-service: path: /user-service/** url: http://localhost:8080/ 通过上面的配置，只要是符合/user-service/**规则的请求路径，都会被转发到http://localhost:8080/地址。举个例子，假设当一个 ...

请求路由上面只是搭建完成了API网关服务，但是里面什么也没有，接下来我们将通过一个简单的例子来往这个API网关服务中增加请求路由的功能。 首先需要将之前的服务注册中心（eureka-server）、服务提供者（eureka-client，服务名为hello-service）、服务消费者(feign-consumer)都启动起来，每个项目只需启动一个服务实例即可，然后访问Eureka信息面板的地址http://localhost:1111即可看到如下信息： 传统路由方式为了加深大家对于Zuul的理解，这里先学习使用传统的路由方式来实现请求路由的功能。使用Spring Cloud Zuul实现路由功能非常简单，只需要对api-gateway服务增加一些关于路由规则的配置，就可以实现传统的路由转发功能，在application.yml配置文件中添加如下配置： 12345zuul: routes: api-test-url: path: /api-test-url/** url: http://localhost:8083 以上配置定义了发往API网关服务的请求中 ...

写在前面通过前面的学习，我们已经对Spring Cloud Netflix下的核心组件了解了一大半。这些组件基本涵盖了微服务架构中最为基础的几个核心设施，利用这些组件我们已经可以构建起一个简单的微服务架构系统。如使用Spring Cloud Eureka实现高可用的服务注册中心以及服务的注册与发现；使用Spring Cloud Ribbon或者Feign来实现服务间负载均衡的接口调用；使用Spring Cloud Hystrix实现线程隔离并加入熔断机制，以避免微服务架构中因个别服务出现异常而引起级联故障蔓延，提高了系统的健壮性。 基于上述思路，截止到目前我们可以设计出类似于下图所示的基础系统架构： 接下来仔细分析一下该架构的特点。在该架构中，我们的服务集群包含内部服务ServiceA和ServiceB，它们都会向Eureka Server集群进行注册与订阅服务，而Open Service是一个对外的RESTful API服务，它通过F5、Nginx等网络设备或工具软件实现对各个微服务的路由与负载均衡，并公开给外部的客户端调用。 接下来我们将重点研究对外服务这一块Edge Servi ...