微服务之Consul 注册中心介绍以及搭建

一、微服务概述

1.1单体架构

单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。

当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用这种模式。但随着项目的业务规模越来越大，团队开发人员也不断增加，单体架构就呈现出越来越多的问题：

• 团队协作成本高：试想一下，你们团队数十个人同时协作开发同一个项目，由于所有模块都在一个项目中，不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支，你绝对会陷入到解决冲突的泥潭之中。
• 系统发布效率低：任何模块变更都需要发布整个系统，而系统发布过程中需要多个模块之间制约较多，需要对比各种文件，任何一处出现问题都会导致发布失败，往往一次发布需要数十分钟甚至数小时。
• 系统可用性差：单体架构各个功能模块是作为一个服务部署，相互之间会互相影响，一些热点功能会耗尽系统资源，导致其它服务低可用。

可见，单体架构的可用性是比较差的，功能之间相互影响比较大。

当然，我们可以做水平扩展。

此时如果我们对系统做水平扩展，增加更多机器，资源还是会被这样的热点接口占用，从而影响到其它接口，并不能从根本上解决问题。这也就是单体架构的扩展性差的一个原因。

而要想解决这些问题，就需要使用微服务架构了。

1.2微服务

微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分成一组小的服务

简而言之：

微服务化的核心就是将传统的单体应用根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务。一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

那么，单体架构存在的问题有没有解决呢？

• 团队协作成本高？
  • 由于服务拆分，每个服务代码量大大减少，参与开发的后台人员在1~3名，协作成本大大降低
• 系统发布效率低？
  • 每个服务都是独立部署，当有某个服务有代码变更时，只需要打包部署该服务即可
• 系统可用性差？
  • 每个服务独立部署，并且做好服务隔离，使用自己的服务器资源，不会影响到其它服务。

综上所述，微服务架构解决了单体架构存在的问题，特别适合大型互联网项目的开发，因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构，分布式就是服务拆分的过程，其实微服务架构正式分布式架构的一种最佳实践的方案。

当然，微服务架构虽然能解决单体架构的各种问题，但在拆分的过程中，还会面临很多其它问题。比如：

• 如果出现跨服务的业务该如何处理？
• 页面请求到底该访问哪个服务？
• 如何实现各个服务之间的服务隔离？

二、Consul 

2.1为什么要引入服务注册中心

微服务所在的IP地址和端口号硬编码到订单微服务中，会存在非常多的问题
（1）如果订单微服务和支付微服务的IP地址或者端口号发生了变化，则支付微服务将变得不可用，需要同步修改订单微服务中调用支付微服务的IP地址和端口号。
（2）如果系统中提供了多个订单微服务和支付微服务，则无法实现微服务的负载均衡功能。
（3）如果系统需要支持更高的并发，需要部署更多的订单微服务和支付微服务，硬编码订单微服务则后续的维护会变得异常复杂。
所以，在微服务开发的过程中，需要引入服务治理功能，实现微服务之间的动态注册与发现

2.2常见的注册中心 

 现在比较流行的也就是Consul和Nacos，这两个注册中心我做的项目当中都涉及到了，Zookeeper没有管理界面，一般不建议使用，而Eureka已经处于停更，并且本身就存在很多bug，一般不建议使用！

2.3Consul 介绍 

Consul 是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案相比，Consul的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其它工具(比如ZooKeeper等) ，使用起来也较为简单。

Consul 使用Go语言编写，因此具有天然可移植性(支持Linux,Windows和Mac OS);安装包仅包含一个可执行文件,方便部署，与Docker等轻量级容器可无缝配合。

Consul 官网：Consul by HashiCorp
Consul 官网介绍：Consul Documentation | Consul | HashiCorp Developer

Consul 中文教程：Spring Cloud Consul 中文文档 参考手册 中文版

SpringCloud官网介绍Consul：Spring Cloud Consul 

Consul集群：在Consul中，每个提供服务的节点上都需要安装和运行Consul Agent，Consul Agent有服务器和客户端两种模式，所有运行Consul Agent的节点一同构成Consul集群。

• Consul Server
  Consul Server主要负责存放和备份使用RAFT协议保持了一致性的数据，通常由奇数个节点构成集群并选举出Leader。

• 多数据中心支持
  Consul是支持多个数据中心的，每个Consul的数据中心都必须有至少一个Server用来维护Consul的状态。这些信息包括用于服务发现以及服务路由的相关内容。需要进行跨数据中心的查询等操作的时候，是通过本地数据中心的Consul Server进行的，需要注意的是这种情况下Consul Server之间不会进行Key/Value数据的同步。

补充

Consul是一种开源的分布式服务发现和配置管理工具。它提供了服务注册与发现，健康检查，KV存储，多数据中心，安全服务通信等功能，是构建分布式系统和微服务架构的重要工具。

Consul主要由以下几个组件组成：

1. Agent（代理）：运行在每个节点上的进程，负责与其他Agent通信来完成服务注册、健康检查等工作。

2. Server（服务器）：提供更高级别的服务发现和配置管理功能，同时也承担了集群管理和状态同步等任务。

3. Catalog（目录）：存储所有服务实例的元数据和状态信息，包括服务名称、地址、端口、标签等。

4. Health Check（健康检查）：通过定期进行健康检查来保证服务的可用性，检查结果会被记录在Catalog中。

5. Key-Value Store（键值存储）：提供了一个分布式的KV存储，用于存储和共享配置信息、特性标志等数据。

6. DNS接口：提供了DNS接口来支持服务发现的客户端透明地访问服务。

Consul通过集成多种服务发现、负载均衡和监控工具，如NGINX、HAProxy、LoadBalancer、Prometheus等，可以实现服务治理和故障自愈，提高了系统的可靠性和弹性，是一种非常有用的分布式系统解决方案。 

2.4Consul 特性

• 服务发现：Consul 的客户端可以注册服务，其他客户端可以使用 Consul 发现给定服务的提供者。使用DNS 或 HTTP，应用程序可以轻松找到它们所依赖的服务。
• 健康检查：Consul客户端可以提供任意数量的健康检查，可以与给定的服务关联(“web服务器是否返回200 OK”)，也可以与本地节点关联(“内存利用率是否低于90%”)。操作人员可以使用此信息监视集群运行状况，服务发现组件也可以使用此信息将通信流量路由到远离不健康主机的地方，支持多种方式,HTTP, TCP、 Docker, Shell脚本定制化监控。
• KV 存储：应用程序可以使用Consul的分级 key/value 存储来实现各种目的，包括动态配置、特性标记、协调、leader选举等等。简单的HTTP API使其易于使用。
• 安全服务通信：Consul可以生成和分发服务的TLS证书，以建立相互的TLS连接。可以使用意图来定义允许哪些服务进行通信。可以很容易地管理服务细分，目的可以实时更改，而不是使用复杂的网络拓扑和静态防火墙规则。
• 多数据中心：Consul 支持开箱即用的多个数据中心。这意味着 Consul 的用户不必担心构建额外的抽象层以扩展到多个区域。
• Raft 算法：使用Raft算法完成一致性，Raft将一致性问题分解成了三个独立的部分:leader选举、日志复制、安全性。
• 自带web管理界面：这一点相比于zookeeper注册中心要好一点，zookeeper是没有自带管理界面的。通过管理界面可以清晰的看到注册了多少个服务，以及在管理界面还可以使用服务配置功能。

2.5安装（docker） 

Consul 官网下载地址：Install | Consul | HashiCorp Developer

Consul在windows下和linux下是都可以安装的，并且基本上不用配置就能使用！在此不再赘述

version: '3'
services:
  consul:
    container_name: consul
    image: consul:1.13.3
    restart: always
    environment:
      TZ: Asia/Shanghai
    ports:
      - 18500:8500
    volumes:
      - /opt/disk/docker/volumes/consul/conf:/consul/conf
      - /opt/disk/docker/volumes/consul/data:/consul/data
    privileged: true

编写好 docker-compose.yml 脚本后，在同级目录执行下方命令即可。

docker-compose up -d

要进入上述容器内部，可以使用以下命令：

docker exec -it consul /bin/sh

验证

服务器开放好相应端口或设置好安全组后，访问 http://宿主机IP:映射的端口 （例如按上方配置那就是：http://宿主机IP:18500）即可看到 Consul 界面。

2.6Consul启动命令详解

启动Consul Agent

为了能够使用Consul，在安装之后需要启动Consul Agent。执行命令如下所示：

执行命令：consul agent -dev

注意事项：Consul会使用hostname作为缺省的节点名称，比如本文示例中的liumiaocn，但是如果hostname中包含.的情况下，Consul中的DNS查询将不会起效，此时需要使用-node选项设定节点名称。 

# consul
使用方法: consul [--version] [--help] <command> [<args>]
 
可用命令包括:
    acl            与Consul的ACL进行交互  # 与Consul的访问控制列表进行交互
    agent          运行Consul代理  # 运行Consul代理
    catalog        与目录进行交互  # 与目录进行交互
    config         与Consul的集中配置进行交互  # 与Consul的集中配置进行交互
    connect        与Consul Connect进行交互  # 与Consul Connect进行交互
    debug          为运维人员记录调试归档  # 为运维人员记录调试归档
    event          触发新事件  # 触发新事件
    exec           在Consul节点上执行命令  # 在Consul节点上执行命令
    force-leave    强制集群成员进入“left”状态  # 强制集群成员进入“left”状态
    info           为运维人员提供调试信息  # 为运维人员提供调试信息
    intention      与Connect服务意图进行交互  # 与Connect服务意图进行交互
    join           告知Consul代理加入集群  # 告知Consul代理加入集群
    keygen         生成新的加密密钥  # 生成新的加密密钥
    keyring        管理八卦层的加密密钥  # 管理八卦层的加密密钥
    kv             与键-值存储进行交互  # 与键-值存储进行交互
    leave          优雅地离开Consul集群并关闭  # 优雅地离开Consul集群并关闭
    lock           执行持有锁的命令  # 执行持有锁的命令
    login          使用身份验证方法登录到Consul  # 使用身份验证方法登录到Consul
    logout         销毁使用login创建的Consul令牌  # 销毁使用login创建的Consul令牌
    maint          控制节点或服务的维护模式  # 控制节点或服务的维护模式
    members        列出Consul集群的成员  # 列出Consul集群的成员
    monitor        从Consul代理流式传输日志  # 从Consul代理流式传输日志
    operator       为Consul运维人员提供集群级工具  # 为Consul运维人员提供集群级工具
    reload         触发代理重新加载配置文件  # 触发代理重新加载配置文件
    rtt            估算节点之间的网络往返时间  # 估算节点之间的网络往返时间
    services       与服务进行交互  # 与服务进行交互
    snapshot       保存、恢复和检查Consul服务器状态的快照  # 保存、恢复和检查Consul服务器状态的快照
    tls            创建CA和证书的内置帮助程序  # 创建CA和证书的内置帮助程序
    validate       验证配置文件/目录  # 验证配置文件/目录
    version        打印Consul版本  # 打印Consul版本
    watch          监视Consul中的更改  # 监视Consul中的更改

查询节点信息

另起一个终端，执行如下命令即可确认Consul节点信息

执行命令：consul members

停止Agent

另起一个终端，执行如下命令即可停止Agent，准确地来说是将此节点从Consul集群中脱离并停止Consul Agent

执行命令：consul leave

2.7可视化UI界面

访问地址

缺省方式下，本地可以通过如下方式进行Consul web UI的访问

访问方式: http://localhost:8500/ui
或者
访问方式: http://localhost:8500

Services

缺省方式下显示的服务页面，在这个页面中可以看到注册了的所有服务的信息，这些信息包括服务的健康状况、标签、类型和源

缺省情况下有一个名为consul的服务，这是自管理的典型做法，点击服务名称即可看到服务的详细信息，比如相应实例的信息：

路由信息

Nodes

在Nodes页面可以确认整个数据中心相关的节点的概要信息，包括每个节点的健康状态，本文使用开发模式只有一个名为liumiaocn的Consul节点。

选择节点可以查看更加详细的信息，比如改节点的健康状况的信息

以及该节点上所注册的服务的信息等

Key/Value

通过Key/Value页面可以在Consul中进行Consul KV的管理

这里我们创建一个Key/Value对，Consul的web UI界面支持多种方式

创建之后会看到Key/Value页面中已经有了一条信息了

ACL

Consul使用访问控制列表ACL（Access Control Lists）来对UI、API、CLI以及服务通信进行安全上的保证，在生产环境中需要配置ACL来进行安全上的设定，而在开发模式下使用者可以看到如下的信息

intention

进行访问控制

可以通过此页面对Intention进行增删改查的操作。

2.8三个注册中心异同点

CAP理论：

• C:Consistency (强一致性)
• A:Availability (用性)
• C:Consistency (强一致性)

CAP理论关注粒度是数据,而不是整体系统设计的策略

AP（Eureka）架构：

当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
结论：违背了一致性C的要求，只满足可用性和分区容错，即AP

 CP(Zookeeper/Consul)：

当网络分区出现后,为了保证一致性,就必须拒接请求,否则无法保证一致性

 2.9分布式配置

问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。比如某些配置文件中的内容大部分都是相同的，只有个别的配置项不同。就拿数据库配置来说吧，如果每个微服务使用的技术栈都是相同的，则每个微服务中关于数据库的配置几乎都是相同的，有时候主机迁移了，我希望一次修改，处处生效。

 

当下我们每一个微服务自己带着一个application.yml，上百个配置文件的管理....../(ㄒoㄒ)/~~

 bootstrap.yml

applicaiton.yml是用户级的资源配置项

bootstrap.yml是系统级的，优先级更加高

 

Spring Cloud会创建一个“Bootstrap Context”，作为Spring应用的`Application Context`的父上下文。初始化的时候，`Bootstrap Context`负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的`Environment`。

 

`Bootstrap`属性有高优先级，默认情况下，它们不会被本地配置覆盖。 `Bootstrap context`和`Application Context`有着不同的约定，所以新增了一个`bootstrap.yml`文件，保证`Bootstrap Context`和`Application Context`配置的分离。

 application.yml文件改为bootstrap.yml,这是很关键的或者两者共存

因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

Consul KV的增删改查

此时从Consul web UI可以看到并没有Key/Value的存在。

也可以用如下命令进行kv的查询

liumiaocn:~ liumiao$ consul kv get -recurse
liumiaocn:~ liumiao$ 

新建数据

使用如下命令即可添加username/liumiaocn的KV对

liumiaocn:~ liumiao$ consul kv put username liumiaocn
Success! Data written to: username
liumiaocn:~ liumiao$ 

在命令行中执行consul kv put username liumiaocn命令。该命令将键值对username:liumiaocn存储到Consul的键值存储中。

查询数据

使用-recurse可以查询所有的数据，目前只有一条数据

liumiaocn:~ liumiao$ consul kv get -recurse
username:liumiaocn
liumiaocn:~ liumiao$ 

也可以在get后直接指定KEY的名称

liumiaocn:~ liumiao$ consul kv get username
liumiaocn
liumiaocn:~ liumiao$ 

可以通过加上detailed参数查询详细信息

liumiaocn:~ liumiao$ consul kv get -detailed username
CreateIndex      32
Flags            0
Key              username
LockIndex        0
ModifyIndex      32
Session          -
Value            liumiaocn
liumiaocn:~ liumiao$ 

也可以通过Consul web UI进行结果的查看

更新数据

更新可以和新建数据使用同样的语法，比如此处将username/liumiaocn更新为username/liumiao，执行结果如下所示：

liumiaocn:~ liumiao$ consul kv put username liumiao
Success! Data written to: username
liumiaocn:~ liumiao$ 

删除数据

指定要删除的KEY即可对数据进行删除，当然也可以使用recurse进行指定部分的全部删除，执行示例日志如下所示：

liumiaocn:~ liumiao$ consul kv get -recurse
username:liumiao
liumiaocn:~ liumiao$ consul kv get -recurse
username:liumiao
liumiaocn:~ liumiao$ consul kv delete username
Success! Deleted key: username
liumiaocn:~ liumiao$ consul kv get -recurse
liumiaocn:~ liumiao$ 

 分布式配置

@RefreshScope // 动态刷新

@RefreshScope是Spring Cloud中的一个注解，用于实现动态刷新配置。当使用Spring Cloud Config时，可以通过该注解实现在不重启应用的情况下，动态更新配置信息。

watch:方式刷新 

重启Consul,之前的配置会消失，下一节持久化解决

2.10SpringCloud使用Consul作为服务注册发现中心

SpringCloud使用Consul作为服务注册发现中心_springcloud consul 服务发现 生产者消费者-CSDN博客

2.11SpringCloud使用Consul作为配置中心

SpringCloud使用Consul作为配置中心_consul配置中心-CSDN博客