consul源码笔记

从本周开始对consul的源码做一个简单的阅读和了解，希望能持续下去吧。

consul是使用go编写的，在阅读过程中可能会涉及到对go语法的相关笔记，这个会分开两个系列文章去更新。

1agent的定义(agentgo)

agent是一个常驻进程部署在所有机器上，可以分client和server两种模式运行(client模式只负责转发请求，轻量级)。

config为agent的配置，包括nodeID等核心的配置都在里

delegate为Server或者client的对象，取决于进程启动选择的方式

2程序入口(agentgo)

这里主要是构建一个Server或者client的对象，我们接下来看一个server对象是如何构建的

我们看下server对象的重要属性，跟raft协议相关的对象封装在这里。

这里做的事情很简单，启动服务器并输出日志。

最后我们看起构建一个raft对象具体做了哪些事情。

       Spring Cloud分布式微服务应用，通常在微服务之间采用的Feign进行通信，实现简单快捷的调用，底层采用的>

服务端配置完成

启动服务端，服务将会自动推送到consul

启动客户端（消费者）

在消费者端编写测试文件

访问接口 >

Consul是一个服务网格（微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控）解决方案，它是一个一个分布式的，高度可用的系统，而且开发使用都很简便。它提供了一个功能齐全的控制平面，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心。

这里提供两台Centos：local12，local13

安装方式：

安装Consul后必须运行Agent，可以选择服务器或客户端模式。每个数据中心至少有一个服务器（推荐3~5个服务器集群）。

简单起见，先启动一个Agent的开发模式：

1、定义一个服务

2、查询一个服务

1、创建node1，consul server

2、创建node2,consul client

3、加入集群

4、查询节点

类似Redis，一般也就用来做服务配置。

简单了解下命令就好：

访问下： >

微服务加上如今的服务发现，在基础设施即代码（指使用脚本配置计算基础设施，而不是手动配置计算机的方法）的过程中，我们正在不断的尝试各种实践方案。如何在云基础设施下结合业务场景，通过负载均衡、服务发现、容器化来实现业务链自动化，这就是本文给大家带来的分享。

困扰和烦恼

首先来看下我们其中一个平台之前的大体架构：

随着业务的递增，我们遇到了以下的问题：

什么是服务发现？

在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。

在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，Redis 的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。

然而，服务发现组件记录了（大规模）分布式系统中所有服务的信息，其它服务可以据此找到这些服务。DNS 就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、 健康 监控、多种查询和实时更新等。服务发现是支撑大规模 SOA 的核心服务。

Consul 介绍

Consul 是一个支持多数据中心分布式高可用，用于服务发现和配置共享的开源工具。它具有开箱即用、可跨系统平台部署（在任何基础架构上连接任何应用）等特点。Consul 的三个主要应用场景：服务发现、服务隔离、服务配置。Consul 关键特性：

Consul 之服务发现

Consul 之服务配置

首先 Consul 集群内的所有数据都是可共享的，任何一个节点都是可以同时获取到集群内最新的数据信息。然后通过一些例如 Key/Value、Server、Node 等等数据进行文本内容渲染，从而达到一个变更的全程实时自动化。例如根据 Key/Value 信息渲染：

例如根据服务信息渲染：

在传统运维方式上可以有哪些改变

传统方式如何向微服务化转变

入口的动态自动化

容器和服务发现始终只是在对内部的通信实现，如何将这些服务快速方便的对外实现通信，并且能够高度自动化呢？我们通过将 HA 作为各类后端服务的对外统一入口；配置 backend 服务时，配置的是 Consul 中的服务域名。从而作为内部和外部通信的一个通信转发枢纽。

HA 的域名动态解析

首先看看容器化下的服务地址是怎样通过 Consul 完成变更的。

然后为什么是 HA 的 DNS 动态解析？这个不是 DNS 的锅么？

在常见的代码更新、服务配置变更、迁移、扩容等需要容器重建时，会导致 N 个容器同时发生 Consul 域名解析变更（当然也是预期内的变更），这个时候需要使用了 Consul 域名的服务在访问失败时能够去重新解析一次域名获取新的 IP，完成解析的自动变更。

需要注意的是这里有个坑，原来使用 HAProxy 15 版本，后端服务配置使用域名时，启动服务后只解析一次（和 Nginx 类似）域名，这时如果已解析的服务挂掉或进行了切换等，即使异常节点已屏蔽，访问 HA 时依然会出现例如 503 等异常（即使 DNS 已经发生了改变，但 HA 服务本身缓存了旧 IP 等于地址未更新）。后续查询官网得知 HAProxy 16+ 才支持了动态DNS。

如何利用 HA 的域名解析配置实现后端路由动态化

首先，HA配置增加一段 resolvers 定义，用来实现 HA 的域名动态解析。

其次，对不同业务环境隔离的路由分发，同样需要增加 HA 的 frontend 配置进行流量隔离。

最后，在 HA 的 backend 处引用前面定义的 resolvers 和 frontend，实现到后端RS的动态转发。

WEB 配置内容自动托管

文件内容更新：使用 Consul 的 K/V watch 功能，一旦有新服务上线/下线时，配置自动化接入和自动化下线流程，更新 Web 服务配置并 reload（触发脚本完成），完成整个流程的自动化。

后端服务自动加入集群

云主机节点自动初始化自身后进行服务注册，自动导入流量。

总的来说，我们根据业务特性，使用 HA、Consul、Docker 这样的一个组合来实现高度可扩展性、稳定性，及流程的基本全自动化过程。

业务链高度自动化，从上线到下线，整个流程包括服务上线、配置变更、产品发布、功能迭代、下线回收等全自动衔接完成。

整个过程至少实现了：

现在（图 A）和原有（图 B）对比如下：

作者：丁易锋，网易 游戏 资深运维工程师，主要工作方向为网易 游戏 项目运维支持。专注于运维技术的突破，以及为产品提供更加高质量和便捷的服务支撑。

本文转载自公众号：网易 游戏 运维平台，原文。

以上就是关于consul源码笔记全部的内容，包括:consul源码笔记、Spring Cloud 整合Grpc-注册中心（Eureka/Consul）、hyperf实现简单的rpc服务(win10 + docker+consul)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！