consul

为什么要使用服务发现? 假设我们写的代码会调用 REST API 或者 Thrift API 的服务。为了完成一次请求，代码需要知道服务实例的网络位置（IP 地址和端口）。运行在物理硬件上的传统应用中，服务实例的网络位置是相对固定的；代码能从一个偶尔更新的配置文件中读取网络位置。 对于基于云端的、现代化的微服务应用而言，这却是一大难题，正如下图所示。 服务实例的网络位置都是动态分配的。由于扩展、失败和升级，服务实例会经常动态改变，因此，客户端代码需要使用更加复杂的服务发现机制。 服务发现有两大模式：客户端发现模式和服务端发现模式。我们先来了解客客户端发现模式。 客户端发现模式 使用客户端发现模式时，客户端决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端查询服务注册表，后者是一个可用服务实例的数据库；然后使用负载均衡算法从中选择一个实例，并发出请求。 客户端从服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。 下图显示了这种模式的架构： 服务实例的网络位置在启动时被记录到服务注册表，等实例终止时被删除。服务实例的注册信息通常使用心跳机制来定期刷新。 Netflix OSS 是客户端发现模式的绝佳范例。Netflix Eureka 是一个服务注册表，为服务实例注册管理和查询可用实例提供了 REST API 接口

学习一个东西，首先要搞清楚这个东西是什么，有什么用，怎么用。最近会坚持写博客，将最近学习的SpringCloud的过程记录下来，很多东西往往看了一遍过一段时间就会遗忘，用博客记录下来是一个很好的方式，在整理的过程中才能查漏补缺，知道自己哪些地方掌握的不牢，哪些地方可能是之前学习没有想到的地方。 一、什么是SpringCloud 在说SpringCloud之前，不得不提一下微服务，微服务是可以独立部署，水平扩张，独立访问(或者有单独的数据库)的服务单元。当一个单体系统越来越庞大时，带来的业务逻辑混乱，相互关联复杂等问题越来越凸显，而微服务则专注于单一的任务，通过微服务之间的相互调用实现业务联系，SpringCloud则是这些这些微服务的大管家，通过服务注册,集群，负载均衡，熔断机制，配置中心，消息总线，网关等来监控整个服务的运行。 SpringCloud是一系列有序框架的集合，通过SpringBoot简化了基础分布式系统的开发，如服务注册,集群，负载均衡，熔断机制，配置中心，消息总线，网关都可以通过SpringBoot一键启动和部署，SpringBoot专注于单体服务的开发，实现快速开发部署，SpringCloud则专注于全局管理，管理整个微服务的生态。最终给开发者一套简便，易于开发维护的分布式系统。 二、SpringCloud组成 　　SpringCloud由Spring

当我们服务越来越多，如果服务配置了弹性伸缩，或者当服务不可用时，我们需要随时动态掌握可以使用的服务数量，并向可提供响应的服务发送请求。这时我们需要服务发现功能，当新增服务时，服务可以自动向consul注册，客户端直接向consul发送请求，获取可用服务的地址和端口；当服务不可用时，动态的更新consul，删除该服务在consul中的列表 docker安装consul docker run --name consul1 -d -p 8500:8500 -p 8300:8300 -p 8301:8301 -p 8302:8302 -p 8600:8600 consul:latest agent -server -bootstrap-expect 2 -ui -bind=0.0.0.0 -client=0.0.0.0 8500 http 端口，用于 http 接口和 web ui 8300 server rpc 端口，同一数据中心 consul server 之间通过该端口通信 8301 serf lan 端口，同一数据中心 consul client 通过该端口通信 8302 serf wan 端口，不同数据中心 consul server 通过该端口通信 8600 dns 端口，用于服务发现 -bbostrap-expect 2: 集群至少两台服务器，才能选举集群leader -ui

目前项目在使用consul做服务注册与发现，做SpringSecurityOAuth2 权限认证的authorization_code模式的时候发现一个异常坑爹的问题 这是开始的服务注册代码块 bootstrap.yml： spring: cloud: consul: port: 8500 host: localhost discovery: serviceName: auth locator: lower-case-service-id: true enabled: true register: true 这是注册完后的健康检查 他会把你的主机地址给注册上来。 平时使用可能没问题，但是 当做OAuth2的 authorization_code 模式认证的时候，会出现跨域异常情况如下： 这是请求路径： http://localhost:8001/auth/oauth/authorize?response_type=code&client_id=client_name&redirect_uri=http://localhost:8001/auth/callback&scope=auth 访问后跳转到默认的登录界面： 仔细看，url位置访问地址变成了之前注册的主机名 从而导致的结果就是，点击登录界面出现下图： 没有权限 返回401。 问题就出在了，跳转回主机名导致了跨域问题。

1.NeGet添加 Consul 2.添加consul public static class ConsulRegister { public static void RegistConsul(this IConfiguration configuration) { #region 注册consul string ip = configuration["ip"] ?? "Localhost"; //部署到不同服务器的时候不能写成127.0.0.1或者0.0.0.0,因为这是让服务消费者调用的地址 //int port = int.Parse(configuration["Consul:ServicePort"]);//服务端口 int port = string.IsNullOrWhiteSpace(configuration["port"]) ? 44344 : int.Parse(configuration["port"]); ConsulClient client = new ConsulClient(obj => { obj.Address = new Uri("http://127.0.0.1:8500"); obj.Datacenter = "dc1"; }); //向consul注册服务 Task<WriteResult> result = client.Agent

# 重启docker, 容器不死 方法1： docker run -d --restart=always nginx:latest systemctl restart docker 方法二： 默认所有容器都起，修改配置文件 /etc/docker/daemon.json { "registry-mirrors":["http://b7a9017d.m.caocloud.io"], "insecure-registries":["10.0.0.7:5000"], "live-restore":true } Docker 的几种网络类型 # docker container inspect 可以查看网络类型 # docker network ls none: 不为容器配置任何网络功能 --net=none bridge: docker 默认的网络类型（桥接模式） hosts : 和宿主机共享网络 container: 与另一个运行中的容器共享network namespace docker run -it --network container:容器ID 跨主机网络通讯 macvlan 默认一个屋里网卡，只有一个屋里地址，虚拟多个mac地址 # 创建macvlan网络 docker network create --driver macvlan --subnet 10.0.0.0/24

今天安装Consul的过程中发现一个大坑，前面的安装都挺顺利的，下面是安装的过程 1、下载 Consul ，选择对应的系统版本 2、配置环境变量，在系统--》高级系统设置--》环境变量--》系统变量--》Path去添加即可（D:\consul） 3、cmd指向当前目录，再执行代码 consul agent -dev 启动完成，用浏览器打开http://localhost:8500/就可以看到管理界面了。 问题就出在这里 提示 Consul returned an error. You may have visited a URL that is loading an unknown resource, so you can try going back to the root or try re-submitting your ACL Token/SecretID by going back to ACLs. Try looking in our documentation 这是看到的效果，界面怎么都出不来，网上查了很多资料，大家都没有这个问题，我用的是谷歌浏览器，后来换成火狐浏览器打开就正常显示，真是无语。 来源： https://www.cnblogs.com/chengNet/p/11438955.html

一、Docker主机间容器通信的解决方案 　　 Docker网络驱动 Overlay: 基于VXLAN封装实现Docker原生Overlay网络 Macvlan: Docker主机网卡接口逻辑上分为多个子接口，每个子接口标识一个VLAN。容器接口直接连接Docker主机 网卡接口: 通过路由策略转发到另一台Docker主机 　　 第三方网络项目 　　 隧道方案 　　　　-- Flannel: 支持UDP和VLAN封装传输方式 -- Weave: 支持UDP（sleeve模式）和 VXLAN（优先fastdb模式） -- OpenvSwitch: 支持VXLAN和GRE协议 路由方案 Calico: 支持BGP协议和IPIP隧道。每台宿主机作为虚拟路由，通过BGP协议实现不同主机容器间通信　 回到顶部 二、Docker Overlay Network 　　Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。这样不但能够充分利用成熟的IP路由协议进程数据分发；而且在Overlay技术中采用扩展的隔离标识位数，能够突破VLAN的4000数量限制支持高达16M的用户，并在必要时可将广播流量转化为组播流量，避免广播数据泛滥。 　　因此，Overlay网络实际上是目前最主流的容器跨节点数据传输和路由方案。 　　

Consul是一款由 HashiCorp 公司开源的，用于服务治理的软件， Spring Cloud Consul 对其进行了封装。Consul具有如下特点: 服务注册 - 自动注册和取消注册服务实例的网络位置 运行状况检查 - 检测服务实例何时启动并运行 分布式配置 - 确保所有服务实例使用相同的配置 Consul agent有两种运行模式：Server和Client。这里的Server和Client只是Consul集群层面的区分，与搭建在Cluster之上 的应用服务无关。 以Server模式运行的Consul agent节点用于维护Consul集群的状态，官方建议每个Consul Cluster至少有3个或以上的运行在Server mode的Agent，Client节点不限。 安装Consul Consul下载地址： https://www.consul.io/downloads.html ，本文选择Linux 64bit 版本进行演示。 下载后解压，然后在解压目录下运行 ./consul 命令： 可以看到Consul所包含的命令，使用 consul [命令] --help 可以查看某个命令的具体用法。 执行下面这条命令来启动一个Consul agent： 1 ./consul agent -dev -client 192.168.140.215 -dev

原文链接地址： http://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/ 这里就平时经常用到的服务发现的产品进行下特性的对比，首先看下结论: Feature Consul zookeeper etcd euerka 服务健康检查 服务状态，内存，硬盘等 (弱)长连接，keepalive 连接心跳 可配支持 多数据中心 支持 — — — kv存储服务 支持 支持 支持 — 一致性 raft paxos raft — cap ca ca cp ap 使用接口(多语言能力) 支持http和dns 客户端 http/grpc http（sidecar） watch支持 全量/支持long polling 支持 支持 long polling 支持 long polling/大部分增量 自身监控 metrics — metrics metrics 安全 acl /https acl https支持（弱） — spring cloud集成 已支持 已支持 已支持 已支持 服务的健康检查 Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。