consul

一、Consul基础介绍 　　Consul用Golang实现，因此具有天然可移植性（支持Linux、windows和Mac OS X）；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可 无缝配合 。 　　关于Consul的更多介绍，比如优点，这里就不再赘述了，上网一搜就可以随处找到了。但是，必须贴一个和其他类似软件的对比： 　　此外，关于Consul的架构以及相关的角色，如下图所示： 　　要想利用Consul提供的服务实现服务的注册与发现，我们需要建立Consul Cluster。在Consul方案中，每个提供服务的节点上都要部署和运行Consul的Client Agent，所有运行Consul Agent节点的集合构成Consul Cluster。Consul Agent有两种运行模式： Server 和 Client 。这里的Server和Client只是Consul集群层面的区分，与搭建在Cluster之上的应用服务无关。以Server模式运行的Consul Agent节点用于维护Consul集群的状态，官方建议每个Consul Cluster至少有 3个或以上 的运行在Server Mode的Agent，Client节点不限。 　　Consul支持多数据中心，每个数据中心的Consul

一、kong 1、使用kong来做服务网关，目前kong使用的是0.13版本现在地址：https://docs.konghq.com/install,kong的社区版没有dashboard，可以使用kong-dashboard,项目地址：https://github.com/PGBI/kong-dashboard。方便使用和管理。目前kong还不支持直接代理grpc，nginx-1.13.10以后版本开始支持代理grpc。kong0.13使用的是1.13.6，以后会支持grpc代理。 2、简单安装使用 使用yum安装，设置repo： # cat kong.repo [kong] name=kong baseurl=https://kong.bintray.com/kong-community-edition-rpm/centos/7 gpgcheck=0 enabled=1 @配置kong： PostgreSQL 9.5+ Cassandra 3.x.x 本次使用的是postgresql9.5.需要提前安装，使用yum安装，配置repo： #cat pgdg-95-redhat.repo [pgdg95] name=PostgreSQL 9.5 $releasever - $basearch baseurl=https://download.postgresql.org/pub

在prometheus监控系统，prometheus的职责是采集，查询和存储和推送报警到alertmanager。本文主要介绍下prometheus的配置文件。 全局配置文件简介 按 Ctrl+C 复制代码 按 Ctrl+C 复制代码 global： 此片段指定的是prometheus的全局配置， 比如采集间隔，抓取超时时间等。 rule_files： 此片段指定报警规则文件， prometheus根据这些规则信息，会推送报警信息到alertmanager中。 scrape_configs: 此片段指定抓取配置，prometheus的数据采集通过此片段配置。 alerting: 此片段指定报警配置， 这里主要是指定prometheus将报警规则推送到指定的alertmanager实例地址。 remote_write: 指定后端的存储的写入api地址。 remote_read: 指定后端的存储的读取api地址。 global片段主要参数 # How frequently to scrape targets by default. [ scrape_interval: <duration> | default = 1m ] # 抓取间隔 # How long until a scrape request times out. [ scrape_timeout: <duration> |

Consul在生产环境下运行模式分为两种：Server模式和Client模式（dev模式属于开发模式不在这里讨论），我们先用Server模式搭建一个Consul集群,示意图如下： Consul Server A、B、C是启动的三个Consul服务运行于Server模式下，其中Consul Server C 是“总指挥”，他们的Leader，Consul Server A和B是Follower当“替补”，他们都可以提供注册和查询微服务器的功能。Leader负责给其他Follower同步数据和监控各个节点的健康，Leader是由他们仨根据Raft一致性算法选举出来的，Server模式运行的Consul服务不能太多，推荐3或5个，因为太多开会选举性能不佳，并且个数要求是奇数（选举算法要求）。 spring-cloud-provider是模拟的服务提供者程序，spring-cloud-provider-second也是模式的服务提供者程序只是返回内容上不太一样（便于区分是哪个服务返回），他们都在Consul中注册同一个服务名称：service-provider，spring-cloud-consul-consumer是模拟服务消费者程序，负责使用service-provider服务。 为了测试方便我们使用docker进行部署，上述服务可以从以下地址下载： Mac安装Docker

外部的应用或网站通过外部网关服务消费各种服务，内部的生产者本身也可能是消费者，内部消费行为通过内部网关服务消费。 一个内部网关和一个外部网关以及一个Consul Client部署在一台服务器上，这样的网关服务器至少2组，外部网关前面还会有负载均衡设备，内部网关服务使用Consul Client进行查询后使用，内部网关的负载均衡由Consul负责了。 在 Consul集群Server+Client模式 的基础上，我们更新并启动网关服务和消费者服务，演示环境中我们只启动一个网关服务进行模拟。 删除spring-cloud-gateway和spring-cloud-consul-consumer这两个容器。 docker pull bluersw / spring - cloud - gateway : v3 docker run -- name = spring - cloud - gateway - d - p 9000 : 9000 bluersw / spring - cloud - gateway : v3 / opt / consul /./ consul agent - data - dir = /opt/ consul / data - config - dir = /opt/ consul / config - node = gw - cc - join 172.17

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 增加management.endpoints.web.exposure.include=refresh,health,info spring.application.name=spring-cloud-config-client server.port=9006 spring.cloud.consul.host=127.0.0.1 spring.cloud.consul.port=8500 #设置不需要注册到 consul 中 spring.cloud.consul.discovery.register=false #显示的暴露接入点 management.endpoints.web.exposure.include=refresh,health,info 在使用配置中心的类上添加@RefreshScope注解： @RestController //刷新触发地址/actuator/refresh @RefreshScope public class ConfigTestController { //配置信息通过@Value注解读取

参考： https://blog.csdn.net/achenyuan/article/details/80389410 consul安装目录：/usr/local/bin/consul consul配置目录： 1.quick-start: consul agent -dev -http-port 8888 -ui -client 0.0.0.0 -dev 开发模式 -http-port 暴露http端口 -ui 开启consulUI 默认开启 -client 0.0.0.0 允许公网访问 访问 ip:8888/可以看到consul主界面 来源：博客园 作者： 爬上巨人的肩膀 链接：https://www.cnblogs.com/xiaohan970121/p/11609090.html

eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代：目前仍然进行版本迭代 集成支持：支持Dubbo 、SpringCloud

一、Eureka原理 1、架构图 首先来看eureka的官方结构图 　　其中，在Eureka集群配置中，处于不同节点的Eureka通过Replicate进行数据同步；Application Server为服务提供者，Client为服务消费者。 2、基本原理 在Eureka响应的过程中，有三个角色，分别是Eureka、服务提供者、服务消费者； 在服务启动后，服务提供者向Eureka注册自己的信息，如调用地址、提供服务信息等 Eureka为服务注册中心，向外暴露自己的地址，负责管理、记录服务提供者的信息，同时将符合要求的服务提供者地址列表返回服务消费者 服务消费者向Eureka订阅服务，表达自己的需求，然后得到服务提供者消息，远程调用即可 Eureka包含两个组件：Eureka Server和Eureka Client，作用如下: Eureka Client是一个Java客户端，主要用来简化和Eureka Server的交互 Eureka Server提供服务发现的能力，各个微服务启动时，通过Eureka Client向Eureka Server注册自己的信息，Server储存该服务的信息 微服务启动后，周期性(默认为30s)地向Server发送心跳信息，以续约自己的信息，超时(默认为90s)未接受到心跳信息，Server将注销该服务节点 在Eureka

1.镜像官方网址： https://hub.docker.com/_/consul 2.pull 镜像： docker pull consul:1.6.0 3.创建容器（默认http管理端口：8500） docker run -p 8500:8500 consul:1.6.0 4.访问管理网址 http://localhost:8500/ 来源：博客园 作者： cag2050 链接：https://www.cnblogs.com/cag2050/p/11471298.html