写在最后
还有一份JAVA核心知识点整理（PDF）：JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算…
通过postman发送get请求到http://192.168.74.101:8500/v1/catalog/services查看所有的服务列表
通过postman发送get请求到http://192.168.74.101:8500/v1/catalog/service/服务名查看具体的服务详情
服务删除
通过postman发送put请求到http://192.168.74.101:8500/v1/catalog/deregister删除服务
{
“Datacenter”: “dc1”,
“Node”: “node01”,
“ServiceID”: “mysql-01”
}
2、Consul的KV存储
可以参照Consul提供的KV存储的API完成基于Consul的数据存储
-
key值中可以带/, 可以看做是不同的目录结构。
-
value的值经过了base64_encode,获取到数据后base64_decode才能获取到原始值。数据不能大
于512Kb
- 不同数据中心的kv存储系统是独立的，使用dc=?参数指定。
1、pom文件
org.springframework.cloud
spring-cloud-starter-consul-discovery
org.springframework.boot
spring-boot-starter-actuator
其中 spring-cloud-starter-consul-discovery 是SpringCloud提供的对consul支持的相关依赖。
spring-boot-starter-actuator 适用于完成心跳检测响应的相关依赖。
2、配置服务注册
修改每个微服务的application.yml配置文件，添加consul服务发现的相关配置信息
spring:
…省略
cloud:
consul: #consul相关配置
host: 192.168.74.101 #ConsulServer请求地址
port: 8500 #ConsulServer端口
discovery:
#是否注册
register: true
#实例ID
instance-id: ${spring.application.name}-1
#服务实例名称
service-name: ${spring.application.name}
#服务实例端口
port: ${server.port}
#健康检查路径
healthCheckPath: /actuator/health
#健康检查时间间隔
healthCheckInterval: 15s
#开启ip地址注册
prefer-ip-address: true
#实例的请求ip
ip-address: ${spring.cloud.client.ip-address}
其中 spring.cloud.consul 中添加consul的相关配置
-
host：表示Consul的Server的请求地址
-
port：表示Consul的Server的端口
-
discovery：服务注册与发现的相关配置
-
instance-id ： 实例的唯一id（推荐必填），spring cloud官网文档的推荐，为了保证生成一
个唯一的id ，也可以换成${spring.application.name}: ${spring.cloud.client.ipAddress}
-
prefer-ip-address：开启ip地址注册
-
ip-address：当前微服务的请求ip
3、在控制台中查看服务列表
打开ConsulServer的管理控制台，可以发现三个微服务已经全部注册到Consul中了。
由于SpringCloud对Consul进行了封装。对于在消费者端获取服务提供者信息和Eureka是一致的。同样使用 DiscoveryClient 完成调用获取微服务实例信息。
此图是官网提供的一个事例系统图，图中的Server是consul服务端高可用集群，Client是consul客户
端。consul客户端不保存数据，客户端将接收到的请求转发给响应的Server端。Server之间通过局域网或广域网通信实现数据一致性。每个Server或Client都是一个consul agent。Consul集群间使用了
GOSSIP协议通信和raft一致性算法。上面这张图涉及到了很多术语：
- Agent——agent是一直运行在Consul集群中每个成员上的守护进程。通过运行 consul agent来启
动。
agent可以运行在client或者server模式。指定节点作为client或者server是非常简单的，除非有其
他agent实例。所有的agent都能运行DNS或者HTTP接口，并负责运行时检查和保持服务同步。
- Client——一个Client是一个转发所有RPC到server的代理。这个client是相对无状态的。client唯
一执行的后台活动是加入LAN
-
gossip池。这有一个最低的资源开销并且仅消耗少量的网络带宽。
-
Server——一个server是一个有一组扩展功能的代理，这些功能包括参与Raft选举，维护集群状
态，响应RPC查询，与其他数据中心交互WANgossip和转发查询给leader或者远程数据中心。
- DataCenter——虽然数据中心的定义是显而易见的，但是有一些细微的细节必须考虑。例如，在
EC2中，多个可用区域被认为组成一个数据中心？我们定义数据中心为一个私有的，低延迟和高带
宽的一个网络环境。这不包括访问公共网络，但是对于我们而言，同一个EC2中的多个可用区域可
以被认为是一个数据中心的一部分。
- Consensus——在我们的文档中，我们使用Consensus来表明就leader选举和事务的顺序达成一
致。由于这些事务都被应用到有限状态机上，Consensus暗示复制状态机的一致性。
- Gossip——Consul建立在Serf的基础之上，它提供了一个用于多播目的的完整的gossip协议。
Serf提供成员关系，故障检测和事件广播。更多的信息在gossip文档中描述。这足以知道gossip使
用基于UDP的随机的点到点通信。
-
LAN Gossip——它包含所有位于同一个局域网或者数据中心的所有节点。
-
WANGossip——它只包含Server。这些server主要分布在不同的数据中心并且通常通过因特网或者广域网通信。
在每个数据中心，client和server是混合的。一般建议有3-5台server。这是基于有故障情况下的可用性和性能之间的权衡结果，因为越多的机器加入达成共识越慢。然而，并不限制client的数量，它们可以很容易的扩展到数千或者数万台。
同一个数据中心的所有节点都必须加入gossip协议。这意味着gossip协议包含一个给定数据中心的所有节点。这服务于几个目的：第一，不需要在client上配置server地址。发现都是自动完成的。第二，检测节点故障的工作不是放在server上，而是分布式的。这是的故障检测相比心跳机制有更高的可扩展性。第三：它用来作为一个消息层来通知事件，比如leader选举发生时。
每个数据中心的server都是Raft节点集合的一部分。这意味着它们一起工作并选出一个leader，一个有额外工作的server。leader负责处理所有的查询和事务。作为一致性协议的一部分，事务也必须被复制到所有其他的节点。因为这一要求，当一个非leader得server收到一个RPC请求时，它将请求转发给集群leader。
server节点也作为WAN gossip Pool的一部分。这个Pool不同于LAN Pool，因为它是为了优化互联网更高的延迟，并且它只包含其他Consul server节点。这个Pool的目的是为了允许数据中心能够以lowtouch的方式发现彼此。这使得一个新的数据中心可以很容易的加入现存的WAN gossip。因为server都运行在这个pool中，它也支持跨数据中心请求。当一个server收到来自另一个数据中心的请求时，它随即转发给正确数据中想一个server。该server再转发给本地leader。
这使得数据中心之间只有一个很低的耦合，但是由于故障检测，连接缓存和复用，跨数据中心的请求都是相对快速和可靠的。
Gossip协议
传统的监控，如ceilometer，由于每个节点都会向server报告状态，随着节点数量的增加server的压力随之增大。在所有的Agent之间（包括服务器模式和普通模式）运行着Gossip协议。服务器节点和普通Agent都会加入这个Gossip集群，收发Gossip消息。每隔一段时间，每个节点都会随机选择几个节点发送Gossip消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。示意图如下。
RAFT一致性算法
为了实现集群中多个ConsulServer中的数据保持一致性，consul使用了基于强一致性的RAFT算法。
在Raft中，任何时候一个服务器可以扮演下面角色之一：
- Leader: 处理所有客户端交互，日志复制等，一般一次只有一个Leader.
- Follower: 类似选民，完全被动
- Candidate（候选人）: 可以被选为一个新的领导人。
Leader全权负责所有客户端的请求，以及将数据同步到Follower中（同一时刻系统中只存在一个 Leader）。Follower被动响应请求RPC，从不主动发起请求RPC。Candidate由Follower向Leader转换的中间状态
关于RAFT一致性算法有一个经典的动画http://thesecretlivesofdata.com/raft/，其中详细介绍了选
举，数据同步的步骤。
首先需要有一个正常的Consul集群，有Server，有Leader。这里在服务器Server1、Server2、Server3上分别部署了Consul Server。（这些服务器上最好只部署Consul程序，以尽量维护Consul Server的稳定）
服务器Server4和Server5上通过Consul Client分别注册Service A、B、C，这里每个Service分别部署在了两个服务器上，这样可以避免Service的单点问题。（一般微服务和Client绑定）
在服务器Server6中Program D需要访问Service B，这时候Program D首先访问本机Consul Client提供的HTTP API，本机Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回。
1、准备环境
Agent 以 client 模式启动的节点。在该模式下，该节点会采集相关信息，通过 RPC 的方式向
server 发送。Client模式节点有无数个，官方建议搭配微服务配置
Agent 以 server 模式启动的节点。一个数据中心中至少包含 1 个 server 节点。不过官方建议使用
3 或 5 个 server 节点组建成集群，以保证高可用且不失效率。server 节点参与 Raft、维护会员信
息、注册服务、健康检查等功能。
2、安装consul并启动
在每个consul节点上安装consul服务，下载安装过程和单节点一致。
##从官网下载最新版本的Consul服务
wget https://releases.hashicorp.com/consul/1.5.3/consul_1.5.3_linux_amd64.zip
##使用unzip命令解压
unzip consul_1.5.3_linux_amd64.zip
##将解压好的consul可执行命令拷贝到/usr/local/bin目录下
cp consul /usr/local/bin
##测试一下
consul
启动每个consul server节点
##登录s1虚拟机，以server形式运行
consul agent -server -bootstrap-expect 3 -data-dir /etc/consul.d -node=server-1
-bind=192.168.74.101 -ui -client 0.0.0.0 &
##登录s2 虚拟机，以server形式运行
consul agent -server -bootstrap-expect 2 -data-dir /etc/consul.d -node=server-2
-bind=192.168.74.102 -ui -client 0.0.0.0 &
##登录s3 虚拟机，以server形式运行
consul agent -server -bootstrap-expect 2 -data-dir /etc/consul.d -node=server-3
-bind=192.168.74.103 -ui -client 0.0.0.0 &
-server： 以server身份启动。
-bootstrap-expect：集群要求的最少server数量，当低于这个数量，集群即失效。
-data-dir：data存放的目录，更多信息请参阅consul数据同步机制
-node：节点id，在同一集群不能重复。
-bind：监听的ip地址。
-client：客户端的ip地址(0.0.0.0表示不限制) & ：在后台运行，此为linux脚本语法
至此三个Consul Server模式服务全部启动成功
##在本地电脑中使用client形式启动consul
consul agent -client=0.0.0.0 -data-dir /etc/consul.d -node=client-1
3、每个节点加入集群
在s2，s3，s4 服务其上通过consul join 命令加入 s1中的consul集群中
##加入consul集群
consul join 192.168.74.101
4、 测试
在任意一台服务器中输入 consul members查看集群中的所有节点信息
##查看consul集群节点信息
consul members
（1）节点和服务注销
当服务或者节点失效，Consul不会对注册的信息进行剔除处理，仅仅标记已状态进行标记（并且不可使用）。如果担心失效节点和失效服务过多影响监控。可以通过调用HTTP API的形式进行处理节点和服务的注销可以使用HTTP API:
-
注销任意节点和服务：/catalog/deregister
-
注销当前节点的服务：/agent/service/deregister/:service_id
如果某个节点不继续使用了，也可以在本机使用consul leave命令，或者在其它节点使用consul forceleave 节点Id。
最后
权威指南-第一本Docker书
引领完成Docker的安装、部署、管理和扩展，让其经历从测试到生产的整个开发生命周期，深入了解Docker适用于什么场景。并且这本Docker的学习权威指南介绍了其组件的基础知识，然后用Docker构建容器和服务来完成各种任务：利用Docker为新项目建立测试环境，演示如何使用持续集成的工作流集成Docker，如何构建应用程序服务和平台，如何使用Docker的API，如何扩展Docker。
总共包含了：简介、安装Docker、Docker入门、使用Docker镜像和仓库、在测试中使用Docker、使用Docker构建服务、使用Fig编配Docke、使用Docker API、获得帮助和对Docker进行改进等9个章节的知识。
关于阿里内部都在强烈推荐使用的“K8S+Docker学习指南”—《深入浅出Kubernetes：理论+实战》、《权威指南-第一本Docker书》，看完之后两个字形容，爱了爱了！
总共包含了：简介、安装Docker、Docker入门、使用Docker镜像和仓库、在测试中使用Docker、使用Docker构建服务、使用Fig编配Docke、使用Docker API、获得帮助和对Docker进行改进等9个章节的知识。
[外链图片转存中…(img-7I5AIMpz-1715823286084)]
[外链图片转存中…(img-kHbGxwLj-1715823286085)]
[外链图片转存中…(img-VDKOXGlW-1715823286085)]
[外链图片转存中…(img-RY1aiO8D-1715823286085)]
关于阿里内部都在强烈推荐使用的“K8S+Docker学习指南”—《深入浅出Kubernetes：理论+实战》、《权威指南-第一本Docker书》，看完之后两个字形容，爱了爱了！
1133
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
