consul和kong的实践（一）

这一篇先介绍consul集群，以及consul和应用服务的结合使用，下一篇是和kong网关的结合。

一.consul的集群安装

以其中一台机器为例：

mkdir /usr/local/consul 创建consul的安装目录
cd /usr/local/consul
wget https://releases.hashicorp.com/consul/1.5.2/consul_1.5.2_linux_amd64.zip 建议大家不要直接使用我给出的下载地址，可以开了代理下好了，再将consul压缩包上传到服务器或者虚拟机。官网下载地址：（我是centos7.x 64位操作系统）
unzip consul_1.5.2_linux_amd64.zip 解压cconsul压缩包，如果没有unzip命名，先安装（yum -y install unzip）consul的压缩包解压以后是非常干净的，只有一个consul的二进制文件。
cp consul /usr/local/bin 将consul文件复制到 /usr/local/bin 目录下面，这样我们不管在什么目录下都可以运行了。
consul version 老规矩，版本号测试一下。
下一步就是开启consul的server服务了，consul分为server和client两种节点。我们现在是先搭建server集群。开启consul server节点有两种方式。

1）直接运行，控制台可查看日志，ctrl+c可直接退出。
  consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=node1
-client=0.0.0.0 -bind=192.168.0.171 -datacenter=dc1
2) 后台运行
      nohup consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=node1
-client=0.0.0.0 -bind=192.168.0.171 -datacenter=dc1  >/tmp/consul/nohup.out 2>&1 &

简单介绍一下参数的意思：

** -server ：定义agent运行在server模式
-ui：开启ui管理
-bootstrap-expect ：在一个datacenter中期望提供的server节点数目，当该值提供的时候，consul一直等到达到指定sever数目的时候才会引导整个集群，该标记不能和bootstrap共用
-client：**consul服务侦听地址，这个地址提供http、dns、rpc等服务，默认是127.0.0.1所以不对外提供服务，如果你要对外提供服务改成0.0.0.0
如果你对更多配置有兴趣，可以移步以下地址：

启动以后我们可以检查一下端口是否监听：netstat -tunlp （如果nestat没装，可以执行 yum -y install net-tools）。可以看到8300 8301 8302以及8500和8600端口都已经监听了。

其中8500是ui端口，在我们集群启动以后，可以用ip:8500/ui 查看，8600是域名解析端口，在我的解决方案里面会使用到。
9. consul members 查看成员，目前只有改节点。

在另外两台虚拟机或者服务器上重复以上操作，第七步命令有一些不同。

consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=node2 -client=0.0.0.0
-bind=192.168.0.155 -datacenter=dc1 -join 192.168.0.171
consul agent -server -ui -bootstrap-expect=3 -data-dir=/tmp/consul -node=node3 -client=0.0.0.0
-bind=192.168.0.169 -datacenter=dc1 -join 192.168.0.171

consul members 此刻就可以看到有三个节点了

12.consul operator raft list-peers

在这里我们可以看到consul集群已经启动了，自动选举node2节点，也就是ip为155的这台机器为leader，如果你断开了这台机器，集群会自动选举下一个leader。
13.现在你可以选择选择三台机器的任意一台机器的ip，访问ip:8500，即可以看到ui管理。（请注意关闭防火墙，或者打开该端口。不然其他机器上访问不到）

二.consul的架构以及和应用程序的结合

目前我们的架构如图：

我们这篇博客要达到的目的：

consul提供的节点有两种模式，上面我们已经提到了，我们之前搭建的就是server，每个应用程序application到consul server之间，需要client的交互。你说client和application是部署在一台机器上面的，这是官方推荐的架构，当然我们也可以有其他选择，这里我采用的是这种，比较简单。（client是一个非常轻量级的进程.用于注册服务,运行健康检查和转发对server的查询，client无状态）
为了做到高可用，我们application服务本身就必须是高可用的，如图所示，比如servicea（文中application等于service概念）我在三台服务器上都部署了，同时通过三个consul client注册了。这样，不管是某台consul client或者某台service挂了，或者某台consul server，都不会影响到我们的使用，其实nginx也可以做到类似功能，不过在服务注册和发现上面，consul更为灵活。
简单介绍了一下我的设计，让我们来继续搭建吧：
机器有限，我就不换机器了，还是在这三台服务器上面去部署了，这次部署consul client 我给你介绍另外一种方式部署，docker，其实consul server的部署也可以用docker，这个选择自己习惯的就行。

1.部署client

  1）yum install -y docker 如果机器已经安装了docker 请直接跳至第四步
2）systemctl start docker
3）systemctl status docker
4)  docker pull consul:1.5.2
5）docker images 查看镜像，可以看到已经拉到了。
6）docker run --name nodeclient1 -d -p 8501:8500 -p 8311:8301 -p 8312:8302 -p 8601:8600 consul:1.5.2 agent -ui -bind=0.0.0.0 -client=0.0.0.0 -join 192.168.0.171
7）consul members

8）按照架构图里面还需要部署两台，这里就不做演示了，按照上述步骤，大家可以自行部署。
9）部署完了可以在ui界面里面看一下。

2.注册services

consul提供http api的方式注册，如果是.net core的程序可以采用这种方式手动去写脚本，或者代码去注册。我这边是java程序，采用的框架都是springboot，所以引用了springcloud就直接结合了consul的注册，我先介绍一下这种。
1）引用maven包

 <dependency>
   <groupid>org.springframework.cloud</groupid>
   <artifactid>spring-cloud-starter-consul-all</artifactid>
   <version>2.1.1.release</version>
</dependency>
<dependency>
   <groupid>org.springframework.boot</groupid>
   <artifactid>spring-boot-starter-actuator</artifactid>
   <version>2.1.5.release</version>
</dependency>

2）配置bootstrap.yml配置文件，如果你本来项目是application.yml可以直接换成bootstrap.yml.
核心配置贴个图：

spring:
 application:
    name: operating #operating
 cloud:
    consul:
      host: 192.168.0.171  
      port: 8501
      discovery:
        register: true
        hostname: 192.168.0.159
        servicename: ${spring.application.name}
        healthcheckpath: /api/operating/actuator/health
        healthcheckinterval: 15s
        tags: urlprefix-/${spring.application.name}
        #instanceid: ${spring.application.name}:${spring.cloud.client.ip-address}

老规矩给大家介绍一下配置的意思：
host： consul client 的ip。
port: client 的port 。正常是8500，但是我用docker部署的时候用了8501映射了容器的8500,。
hostname：健康检查的ip 也就是你当前应用的ip，其实和前面host一样，你把application和consul client部署在同一台机器的时候，这两个地方可以都填127.0.0.1。
healthcheckpath：如果你没配置context-path，那么就是/actuator/health，我这里配置context-path，所以加上来了。
tags：后期做版本管理，我会用起来，现在无所谓。
instanceid: consul 注册的时候默认是applicationname+port ，我这里将他重写了。所以你看到我将它注释掉了。
3）启动springboot程序。服务注册成功，查看ui管理

三.基于consul集群架构，调用服务

现在我们的服务已经注册到了consul上面了，那么针对目前架构，我们肯定还有两个疑惑。
1.公司服务器内部之间的调用，比如我们已经注册了的rpc服务之间的调用，当然你是restful也所谓。
2.网关层面怎么调用consul。
针对第一点，springcloud是提供部分sdk的，当然如果你是.net core，我不太清楚是否有相关sdk，没有也可以自己写。我先介绍一下，你如果想实现自己sdk的思路。
consul任何一个节点都提供了
节点内部所有存活服务查询
catalog 集群内部所有存活服务查询

servicename 节点内部单个服务查询
servicename 集群内部单个服务查询
tip：servicename替换成你注册的名称

根据上述consul api接口我们是可以拿到你注册的service实际ip和content-path，并且还有tags，那么你还可以利用tags进行版本控制。
那我们先来看看，springcloud替我们做了什么？
引用的包，我们已经引用了。
直接上代码：

public class serverinvoke {
    @autowired
    private loadbalancerclient loadbalancer;
    @autowired
    private discoveryclient discoveryclient;
    
     /**
     * 获取所有服务
     *
     * @return
     */
    private list<serviceinstance> services(string servername) {
        return discoveryclient.getinstances(servername);
    }

    /**
     * 从所有服务中选择一个服务（轮询）
     */
    private serviceinstance discover(string servername) {
        return loadbalancer.choose(servername);
    }
}

很明显可以发现我们可以拿到服务的实际地址，如果你的服务是高可用的，会轮训拿到不同的地址。

针对服务以jsonrpc协议内部调用时

由于公司之前都是基于jsonrpc在调用（.net平台）为了兼容。我写了一个非常简单的sdk，传到了github，如果你公司不是jsonrpc协议，你可以自己写一个，思路上面已经给了提供，在参考一下我写的。（草稿版）

针对服务被外部（网关层调用）

前文已经介绍了，consul是8600端口作为域名解析的，并且consul会为你的服务提供一个域名：servicename.service.consul。所以只需要将你的请求转发到8600即可，你可以采用servicename.service.consul/xxx来访问你的服务，前提是已经转发到了consul的域名解析端口。
测试一下 dig @127.0.0.1 -p 8600 operating.service.consul srv （dig命令安装 yum install bind-utils）