consul

获取镜像 docker pull consul 启动镜像 开发： docker run -d --name=dev-consul -p 8500:8500 consul 集群： • 部署server端 本环境仅仅部署一个server端和一个client端！ docker run -d -p 8500:8500 --name node1 consul agent -server -bootstrap-expect 3 -data-dir=/tmp/consul -client="0.0.0.0" -ui 查看 node1 ip地址 docker exec -it node1 ip a 部署client端 docker run -d --name node2 consul agent -server -join 172.17.0.2 docker run -d --name node3 consul agent -server -join 172.17.0.2 docker run -d --name node4 consul agent -server -join 172.17.0.2 查看容器运行 docker ps 查看集群节点 docker exec node1 consul members 来源： https://www.cnblogs.com/lidezhen/p

前言 上一篇文章使用 Consul 和 Registrator 在 docker 的容器环境中搭建了服务注册和发现集群。在服务发现和注册的基础上，本文将引入 Nginx 反向代理服务器和 Consul-template 组件，实现动态的服务负载均衡。 正文 1. 工具介绍 1.1. Nginx 一个高性能的 HTTP 和反向代理服务器，用于前端访问流量到后台应用服务器负载均衡和请求转发。 1.2. Consul-template Consul-template 是 HashiCorp 基于 Consul 所提供的可扩展的工具，通过监听 Consul 中的数据变化，动态地修改一些配置文件中地模板。常用于在 Nginx 、 HAProxy 上动态配置健康状态下的客户端反向代理信息。 2. 实现原理 通过 Nginx 自身实现负载均衡和请求转发； 通过 Consul-template 的 config 功能实时监控 Consul 集群节点的服务和数据的变化； 实时的用 Consul 节点的信息替换 Nginx 配置文件的模板，并重新加载配置文件； Consul-template 和 nginx 必须安装在同一台机器上，因为 Consul-template 需要动态修改 nginx 的配置文件 nginx.conf ，然后执行 nginx -s reload 命令进行路由更新

Spring Cloud是一个分布框架 Spring Cloud里边包括了目前最新的所有组件共21个 1.spring cloud config 配置管理工具包，可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及SVN 2.spring cloud bus 事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化。经常与Spring Cloud Config联合实现热部署。 3.Eureka 云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移 4.Hystrix 熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点，从而对延迟和故障提供强大的容错能力 5.Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul相当于是设备和Netiflix流应用的web网站后端所有请求的前门。 6.Archaius 配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。 7.Consul 封装了Consul操作,consul是一个服务发现与配置工具，与Docker容器可以无缝集成。 8.Spring Cloud for Cloud Foundry 通过Oauth2协议绑定服务到CloudFoundry

Spring Cloud Ribbon Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。 当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务实例列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。 而当Ribbon与Consul联合使用时，ribbonServerList会被ConsulServerList来扩展成从Consul获取服务实例列表。同时由ConsulPing来作为IPing接口的实现。 我们在使用Spring Cloud Ribbon的时候，不论是与Eureka还是Consul结合，都会在引入Spring Cloud Eureka或Spring Cloud Consul依赖的时候通过自动化配置来加载上述所说的配置内容，所以我们可以快速在Spring Cloud中实现服务间调用的负载均衡。 下面我们通过具体的例子来看看如何使用Spring Cloud

前言 最近项目逐步转向基于.Net Core，目前dotnet core 虽然已出3.0了但还没有特别成熟的框架，要实现微服务，必须要解决配置中心的问题 。不管是不是微服务，节点多了配置文件一个个更改非常麻烦，今天分享一个基于Consul 实现轻量级的配置中心方案。 实现思路基于Consul的Key/value ，多个Consul 节点之间可以自动同步配置，我们的程序中就是实现ConfigurationProvider，监听Consul变化 代码 using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Threading; using System.Threading.Tasks; using Microsoft.AspNetCore; using Microsoft.AspNetCore.Hosting; using Microsoft.Extensions.Configuration; using Microsoft.Extensions.Logging; using Winton.Extensions.Configuration.Consul; namespace Bo.ServiceB { public class Program {

本文根据洪斌10月27日在「3306π」技术 Meetup - 武汉站现场演讲内容整理而成。 主要内容： 本次分享将介绍目前数据迁移、数据同步、数据消费，多IDC架构中数据复制技术所面临问题及现有的产品和方案，并分享新开源的能在异构数据存储之间提供高性能和强大复制功能的DTLE相关技术内容。 提纲： 1. MySQL Replication 2. DTLE核心场景 3. DTLE设计原则 4. DTLE相关介绍（架构/集群机制/拓扑结构/技术栈/功能/限制） 5. Demo演示 6. 云间同步案例 大家好，我今天分享的主题是关于爱可生在前不久开源的数据传输中间件DTLE，也可简称为DTS。爱可生作为一家以MySQL为主的技术服务公司，在我们服务企业客户过程中，经常会遇到各种数据同步的需求，能做数据同步的软件很多，但未能找到满足我们所有需求的软件，所以我们决定自研一款数据传输软件，结合我们客户的需求场景做了DTLE，并选择在10月24号“程序员节”向社区开源。 今天主要是对DTLE的一些技术架构，跟大家分享。 1. MySQL Replication MySQL如此受欢迎，其原因和MySQL原生支持了 Replication密不可分。基于replication能力社区也是玩出了各种拓扑架构。 1.1 MySQL Replication架构 这张图对DBA们应该并不陌生

　　Consul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。它具有很多优点。包括：基于 raft 协议，比较简洁； 支持健康检查, 同时支持 HTTP 和 DNS 协议 支持跨数据中心的 WAN(广域网) 集群 提供图形界面 跨平台，支持 Linux、Mac、Windows。 　　consul是使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。 　　raft（分布式一致性协议）：见《 一致性算法之：Raft 》　 　　@client 　　CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 　　@server 　　SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样

待解决问题：此处依赖需要用 spring-cloud-consul-config，用 spring-cloud-starter-consul-config 会提示找不到；那 spring-cloud-starter-consul-config 和 spring-cloud-consul-config 区别是什么？从网上没有搜到答案，待跟进。 问题来自： https://github.com/cag2050/spring_cloud_consul_producer1_demo 来源： https://www.cnblogs.com/cag2050/p/11602449.html

https://blog.csdn.net/fly910905/article/details/100023415 来源： https://www.cnblogs.com/772933011qq/p/11583842.html

本系列七篇文章列表如下： 微服务实战（一）：微服务架构的优势与不足 微服务实战（二）：使用API Gateway 微服务实战（三）：深入微服务架构的进程间通信 微服务实战（四）：服务发现的可行方案以及实践案例 微服务实践（五）：微服务的事件驱动数据管理 微服务实践（六）：选择微服务部署策略 微服务实践（七）：从单体式架构迁移到微服务架构 这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。 为什么要使用服务发现? 设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。 而对于一个现代的，基于云微服务的应用来说，这却是一个很麻烦的问题。其架构如图所示： 服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变，因此，客户端代码需要使用一种更加复杂的服务发现机制。 目前有两大类服务发现模式： 客户端发现 和 服务端发现 。 我们先来来讨论一下客户端发现。 客户端发现模式 当使用 客户端发现模式 时