consul

CAP 定理 CAP定理：CAP定理又称CAP原则，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（P），就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好） 一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。 我们接下来介绍的服务注册和发现组件中，Eureka满足了其中的AP，Consul和Zookeeper满足了其中的CP Eureka Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。 Eureka 采用的是Server/Client的模式进行设计的。Server是服务注册中心的角色，为Client提供服务的注册与发现功能，维护着注册到自身的Client的相关信息

背景 本文并不介绍服务发现的基本原理。除了一致性算法之外，其他并没有太多高深的算法，网上的资料很容易让大家明白上面是服务发现。 想直接查看结论的同学，请直接跳到文末。 目前，市面上有非常多的服务发现工具，《Open-Source Service Discovery》（http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/）一文中列举了如下开源的服务发现工具。 Name Type AP or CP Language Dependencies Integration Zookeeper General CP Java JVM Client Binding Doozer General CP Go Client Binding Etcd General Mixed (1) Go Client Binding/HTTP SmartStack Dedicated AP Ruby haproxy/Zookeeper Sidekick (nerve/synapse) Eureka Dedicated AP Java JVM Java Client NSQ (lookupd) Dedicated AP Go Client Binding Serf Dedicated AP Go Local CLI Spotify

▶ Spring Boot 依赖与配置 Maven 依赖 <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Greenwich.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> ..... <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-consul-config</artifactId> </dependency> </dependencies> ▶ 使用说明 1、部署 Consul 参考文档：上一篇 2、在 resources 路径下添加配置文件 bootstrap.properties，示例如下： # consul 基本配置 spring.cloud.consul.host=127.0.0

https://blog.csdn.net/u011537073/article/details/69663858 想象一下，如果你在写代码调用一个有REST API或Thrift API的服务，你的代码需要知道一个服务实例的网络地址（IP地址和端口）。运行在物理硬件上的传统应用中，服务实例的网络地址是相对静态的，你的代码可以从一个很少更新的配置文件中读取网络地址。 在一个现代的，基于云的微服务应用中，这个问题就变得复 杂多 了，如下图所示： 服务实例的网络地址是动态分配的。而且，由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，你的客户端代码需要一套更 精细 的服务发现机制。 有两种主要的服务发现模式：客户端服务发现（client-side discovery）和服务器端服务发现（server-side discovery）。我们首先来看下客户端服务发现。 客户端服务发现模式 当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表（service registry）发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构： 一个服务实例被启动时，它的网络地址会被写到注册表上；当服务实例终止时，再从注册表中删除

下载 nginx-upsync-module wget https://github.com/weibocom/nginx-upsync-module/archive/v2.1.0.tar.gz 重新编译nginx --add-module=/root/sortware/nginx-upsync-module-2.1.0 下载consul ungzip解压 cp consul /usr/bin 运行 consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -node=ali -bind=内网地址 -ui -client=0.0.0.0 upstream swoole_server { 　　server nginx.xuedong.vip:9501; 　　upsync 127.0.0.1:8500/v1/kv/upstreams/swoole_test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off; 　　upsync_dump_path /root/servers_test.conf; 　　include /root/servers_test.conf; } reload -s reload

调用示例 同步调用 Pom中添加依赖 <dependency> <groupId>com.weibo</groupId> <artifactId>motan-core</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>com.weibo</groupId> <artifactId>motan-transport-netty</artifactId> <version>RELEASE</version> </dependency> <!-- only needed for spring-based features --> <dependency> <groupId>com.weibo</groupId> <artifactId>motan-springsupport</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.2.4.RELEASE</version> </dependency> 为调用方和服务方创建公共接口 src

工程概述 Motan框架采用模块化设计，使用按需加载，模块有： motan-core：motan核心框架 motan-transport-netty：基于Netty协议的长链接传输协议 motan-registry-consul：consul服务发现组件 motan-registry-zookeeper：zk服务发现组件 motan-springsupport：spring标签解析相关组件 默认配置 protocol协议默认为motan，基于hessian2实现。 负载均衡默认为activeWeight，低并发度优先，refer的某个时刻call的数量越小优先级越高。 容错策略默认为failover，失败自动切换，当出现失败，重试其他服务器。 Failfast快速失败，只发起一次调用，失败立即报错。 配置服务端工作线程数。 配置客户端为每个服务建立的连接数。 注册中心motan:registry 包含以下属性： Name：标识配置名称； regProtocol：标识注册中心协议 Address：标识注册中心地址 服务提供方motan:service 常用属性： Interface：标识服务的接口类名 Ref：标识服务的实现类，引用具体的spring业务实现对象 Export：标识服务的暴露方式，格式为“protocolId：port”，其中protocolId：应对motan

I am deploying a simple hello world nginx container with marathon, and everything seems to work well, except that I have 6 containers that will not deregister from consul. docker ps shows none of the containers are running. I tried using the /v1/catalog/deregister endpoint to deregister the services, but they keep coming back. I then killed the registrator container, and tried deregistering again. They came back. I am running registrator with docker run -d --name agent-registrator -v /var/run/docker.sock:/tmp/docker.sock --net=host gliderlabs/registrator consul://127.0.0.1:8500 -deregister-on

We're dockerizing our micro services app, and I ran into some discovery issues. The app is configured as follows: When the a service is started in 'non-local' mode, it uses Consul as its Discovery registry. When a service is started in 'local' mode, it automatically binds an address per service (For example, tcp://localhost:61001, tcp://localhost:61002 and so on. Hard coded addresses) After dockerizing the app (for local mode only, for now) each service is a container (Docker images orchestrated with docker-compose. And with docker-machine, if that matters) But one service can not interact