consul

前言 官网介绍Consul是一个分布式服务网格(Service Mesh)解决方案… 而我目前的理解是提供了分布式系统中的服务发现和配置解决方案, 使用go实现, 目前在github的star是15k, 远超Netflix Eureka 关于Consul的架构, 功能, 对比都可参考 官网 , 建议阅读: What is Consul? Consul vs. Other Software 目的 部署启动consul开发环境 —— dev Spring Cloud Consul 基本使用 consul中的服务发现 consul中的配置中心 consul集群部署 (下节) 下载&启动 进入 下载地址 下载对应的版本即可, 解压即得到可执行文件 这里我下载最新版 1.4.4 , 在Windows测试单机开发环境, 在Linux环境测试consul集群部署 进入命令行: 验证版本: consul --version 1 2 3 λ consul --version Consul v1.4.4 Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents) 启动: consul agent -dev

consul客户端必须配置微服务实例名称和ID,微服务启动的时候需要将名称和ID注册到注册中心,后续微服务之间调用也需要用到. 名称可以通过以下两种方式配置,优先级从高到低.两个都不配置则默认服务名称为application spring.cloud.consul.discovery.service-name spring.application.name ID可以通过多个配置项配置,下面的五种配置都可以,优先级从高到低. spring.cloud.consul.discovery.instance-id vcap.application.instance_id spring.application.name和spring.application.instance_id搭配,'-'分隔 spring.application.name和server.port搭配,'-'分隔 spring.application.name spring.application.instance_id 如果不配置启动会报错,相关日志如下,从日志中也可以看出,配置要求必须以字母开始,字母或数字结尾. Caused by: java.lang.IllegalArgumentException: Consul service ids must not be empty, must start with a

在线演示 演示地址： http://139.196.87.48:9002/kitty 用户名：admin 密码：admin 技术背景 如今微服务架构盛行，在分布式系统中，项目日益庞大，子项目日益增多，每个项目都散落着各种配置文件，且随着服务的增加而不断增多。此时，往往某一个基础服务信息变更，都会导致一系列服务的更新和重启，运维也是苦不堪言，而且还很容易出错。于是，配置中心便由此应运而生了。 目前市面上开源的配置中心有很多，像Spring家族的Spring Cloud Config， Apache的Apache Commons Configuration，淘宝的diamond， 百度的disconf， 360的QConf等等，都是为了解决这类问题。当下Spring体系大行其道，我们当然也优先选择Spring Cloud Config了。 Spring Cloud Config Spring Cloud Config 是一套为分布式系统中的基础设施和微服务应用提供集中化配置的管理方案，它分为服务端与客户端两个部分。服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息。客户端则是微服务架构中的各个微服务应用或基础设施，它们通过指定的配置中心来管理服务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。 Spring Cloud

背景 由于公司目前的主要产品使用的注册中心是 consul ， consul 需要用集群来保证高可用，传统的方式（Nginx/HAProxy）会有单点故障问题，为了解决该问题，我开始研究如何只依赖 consul 做集群的注册的方式，经过一天的折腾，总算验证了可以通过 集群版ConsulClient 来进行集群注册，在部署实施过程中也遇到了一些问题，特此记录分享，希望能对有需要的同学有帮助。 主机版集群和docker版集群对比 client+server转发模式的集群部署涉及到两种选择，第一种是直接主机模式部署，2个 client +3个 server ，每个 consul 实例部署一台主机（适合土豪使用），此种模式的好处就是简单暴力，而且运维相对简单。此种模式的架构部署图如下： 我们选择的是另外一种经济节约模式， docker 化部署，好处就是节约资源，劣势就是要管理许多 docker 镜像，在有引入k8s这些容器管理平台之前，后续 docker 的运维会比较麻烦，这种模式的架构部署图如下： 通过以上两种模式的架构图我们很清楚的就能知道主机部署模式是最简单直接的，而 docker 的模式虽然节省了资源，但是加大了复杂性，增加了运维的难度。但是这种模式应该是在目前容器化的环境下很好的选择，原因很简单，因为充分的利用了资源，容器的运维可以交给容器运维平台去完成，比如k8s等

1 概述 谈到微服务架构体系，绕不开服务发现这个功能。服务发现机制是简化微服务配置、实现容灾、水平扩缩容、提高运维效率的重要方式。在服务发现工具中，Consul在部署和使用方面与容器结合的天衣无缝，成为越来越多的企业作为服务发现的首选产品。 在微服务开发中，SpringBoot目前是最为广泛使用一个框架。SpringBoot+Consul成为一个比较经典的微服务组合。 作为DevOps软件研发运维一体化的研发管理平台产品，可以完美的支持上述微服务架构。下面我们就以单元测试的示例，来说明在Azure DevOps Server (原名TFS）中如何实现SpringBoot+Consul架构的持续集成（CI）功能。 2. 下载Consul for Windows https://www.consul.io/downloads.html 3. 在代理中将Consul安装为服务器，自动启动 SpringBoot架构的单元测试中，验证服务发现和注册功能是一个比较基础的测试点。在开发人员的计算机中，通常会手动启动一个consul进程，用来实现本地测试。同样，作为服务器端的持续集成工具，我们需要在Azure DevOps Server的服务器上运行Consul服务。 下面我们使用Windows Server中常用的sc.exe工具创建Consul服务。 sc.exe create "Consul

安装consul client consul 客户端检脚本 ============================================================================================= 在192.168.56.122服务器上 ============================================================================================= 1、安装redis yum intstall redis -y 2、配置redis 为主 cat >/etc/redis.conf<<EOF bind 192.168.56.122 127.0.0.1 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize yes supervised no pidfile /var/run/redis_6379.pid loglevel notice logfile /var/log/redis/redis.log databases 16 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error

最终成功版 。 pom引入mavn依赖： <!--consul--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-discovery</artifactId> <version>2.1.2.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-config</artifactId> <version>2.1.2.RELEASE</version> </dependency> 2.yml文件： spring: application: name: demo cloud: consul: config: data-key: data prefix: config format: yaml host: consul的ip地址 port: 端口 discovery: prefer-ip-address: trueserver: port: 8080 3.启动类添加 @EnableDiscoveryClient 注解，sb2

一、Consul服务注册之配置文件方式 1.1 重温Consul实验集群 　　这里我们有三个Consul Server节点，一个Consul Client节点，在Client节点上跑了两个ClientService实例，分别占用8810和8820端口。至于基于Ocelot的API网关服务，还没有实现，留到以后跟各位分享。这里假设我们已经启动了这几个节点，并且能够成功访问这两个ClientService实例（事先把实例启动起来，可以通过IIS，也可以通过命令行启动Kerstel服务器运行）。 　　实例1:192.168.80.71:8810 　　 　　实例2:192.168.80.71:8820 　　 1.2 准备好json配置文件 　　这里我准备了一个如下所示的JSON配置文件（eg.取名为services_config.json），配置了两个服务在里边： 复制代码 { "services":[ { "id": "EDC_DNC_MSAD_CLIENT_SERVICE_01", "name" : "CAS Client Service", "tags": [ "urlprefix-/ClientService01" ], "address": "192.168.80.71", "port": 8810, "checks": [ { "name": "clientservice

Consul可以用于实现分布式系统的服务发现与配置 1.服务注册发现中心 启动Consul consul agent -dev 2.服务端 在 spring boot2X整合Consul 的基础上 添加服务provider，provider1 provider测试方法 package com.xyz.provider.controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class demoController { @RequestMapping("/hello") public String Hello(){ return "hello,provider"; } } provider1测试方法 package com.xyz.provider1.controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController;

由于时间匆忙，要是有什么地方没有写对的，请大佬指正，谢谢。文章有点水，大佬勿喷 这篇博客不回去深度的讲解consul中的一些知识，主要分享的我在使用的时候的一些操作和遇见的问题以及解决办法。当然有些东西官方文档上面也是有的 学习一种工具最好的方式还是去看官方文档，这是血与泪的经验教训。 1.consul集群的搭建 consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。当然与consul类似的工具还有很多几个：ZooKeeper， etcd 这里在讲解之前，我们需要知道的一些基本的东西，这里引用 别人的文章 ， @client CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 @server SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。 @server-leader 中间那个SERVER下面有LEADER的字眼