消息队列微服务相关操作

目录

1. 实现zabbix监控自建的rabbitmq集群
2. 实现zabbix 监控自建kafka集群
3. 扩展阅读：https://dubbo.apache.org/zh/blog/java/codeanalysis/3.0.8/
4. 完成Maven私服搭建，并且输出博客

实现zabbix监控自建的rabbitmq集群

搭建rabbitmq集群

集群规划

rabbitMQ安装

官方文档

https://www.rabbitmq.com/install-debian.html

配置文件修改

主机名解析：加到集群里的每一个服务器上
root@k8s-server1:~# vim /etc/hostname   #修改主机名
mq1.example.local
root@k8s-server1:~# vim /etc/hosts
10.0.0.201 mq1 mq1.example.local
启动MQ
root@k8s-server1:~# systemctl start rabbitmq-server.service 
root@k8s-server1:~# systemctl enable rabbitmq-server.service
root@10ubuntu-yangk:~# systemctl status rabbitmq-server.service
systemctl status rabbitmq-server

验证：

root@k8s-server1:~# ss -tnl    #查看端口

查看插件，管理插件

rabbitmq-plugins list
Web管理插件
[  ] rabbitmq_management               3.11.8
启用插件：
rabbitmq-plugins enable rabbitmq_management

效果：http://10.0.0.201:15672/

创建账号

rabbitmqctl add_user **** 12****
rabbitmqctl set_user_tags jack administrator

实现效果：

python 连接MQ导入数据测试：

import pika

#用户名密码
cert = pika.PlainCredentials("","")
# 建立一个实例
conn = pika.BlockingConnection(
    pika.ConnectionParameters('10.0.0.201',cert)  # 默认端口5672，可不写
)
# 声明一个管道，在管道里发消息
channel = conn.channel()
# 在管道里声明queue
channel.queue_declare(queue='')
# RabbitMQ a message can never be sent directly to the queue, it always needs to go through an exchange.
channel.basic_publish(exchange="",
                      routing_key="",  # queue名字
                      body="Hello World!")  # 消息内容
print(" 开始队列")
conn.close()  # 队列关闭

验证：

每个服务器部署mq：

集群版本要保持一致，实现效果：

停止mq，拷贝cookie

Rabbitmq的集群是 依赖于erlang的集群来工作的，所以必须先构建起erlang的集群环境，而Erlang的集群中各节点是通过一个magic cookie来实现的，这个cookie存放在/var/lib/rabbitmq/.erlang.cookie中，文件是400的权限，所以必须保证各节点cookie保持一致，否则节点之间就无法通信。
1.保证cookie文件一致：
先把mq全停了
systemctl stop rabbitmq-server
ll /var/lib/rabbitmq/.erlang.cookie
把201的值拷到另外两台机子上

全部开启

systemctl start rabbitmq-server
systemctl status rabbitmq-server
cat /var/lib/rabbitmq/.erlang.cookie
2.三台服务器都加上解析：
10.0.0.201 mq1 mq1.example.local
10.0.0.202 mq2 mq2.example.local
10.0.0.203 mq3 mq3.example.local
3.查看集群状态：
root@10ubuntu-yangk:~# rabbitmqctl cluster_status
要重启服务器，否则主机名不生效
默认是磁盘节点

先停止写入：以203为节点，其中1台使用磁盘模式，其它节点使用内存模式，
3.1停止app
rabbitmqctl stop_app
3.2清空元数据：
rabbitmqctl reset

主机相互添加（201加到203），启动app

root@mq1:~# rabbitmqctl join_cluster rabbit@mq3 --ram	
--ram	表示是内存角色
启动app
root@mq1:~# rabbitmqctl start_app
同上，202也加到203
在203上查看集群状态
rabbitmqctl cluster_status

3.5 将集群设置为镜像模式：其中一个服务器执行一次就行：

root@mq3:~# rabbitmqctl set_policy ha-all "#"  '{"ha-mode":"all"}'

写到一个服务器之后都会同步到另外两个服务器
因为清理过数据，所以要重新创建账号：
rabbitmqctl add_user j*** 1*****
rabbitmqctl set_user_tags jack administrator
登录进去，可以看到集群状态：

zabbix监控rabbitMQ

主机信息

zbx-server IP: 10.0.0.132 安装zabbix_server

mq1 IP: 10.0.0.201 安装zabbix_agent

rabbitmq01安装配置agent

rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/7/x86_64/zabbix-release-5.0-1.el7.noarch.rpm
apt clean all
apt install zabbix-agent  -y
3.1修改配置文件：
root@mq1:~# vim /etc/zabbix/zabbix_agentd.conf
Server=127.0.0.1,10.0.0.132
Hostname=mq1
UnsafeUserParameters=1         #  --使UnsafeParameter选项支持通配符

重启agent

root@mq1:~# systemctl restart zabbix-agent.service
root@mq1:~# systemctl enable zabbix-agent.service
验证端口root@mq1:~# netstat -ntlp | grep 10050

4. web界面配置：

成功：

实现zabbix 监控自建kafka集群

搭建kafka集群

扩展：新秀Pulsar和kafka的区别：

2013 年雅虎创建了 Pulsar，并于 2016 年把 Pulsar 捐给了 Apache 基金会。Pulsar 现已成为 Apache 的顶级项目，获得举世瞩目的认可。雅虎和 Twitter 都在使用 Pulsar，雅虎每天发送 1000 亿条消息，两百多万个主题。这样的消息量，听起来很不可思议吧，但确实是真的！
接下来我们了解下 Kafka 痛点以及 Pulsar 对应的解决方案。

1. Kafka 很难进行扩展，因为 Kafka 把消息持久化在 broker 中，迁移主题分区时，需要把分区的数据完全复制到其他 broker 中，这个操作非常耗时。
2. 当需要通过更改分区大小以获得更多的存储空间时，会与消息索引产生冲突，打乱消息顺序。因此，如果用户需要保证消息的顺序，Kafka 就变得非常棘手了。
3. 如果分区副本不处于 ISR（同步）状态，那么 leader 选取可能会紊乱。一般地，当原始主分区出现故障时，应该有一个 ISR 副本被征用，但是这点并不能完全保证。若在设置中并未规定只有 ISR 副本可被选为 leader 时，选出一个处于非同步状态的副本做 leader，这比没有 broker 服务该 partition 的情况更糟糕。
4. 使用 Kafka 时，你需要根据现有的情况并充分考虑未来的增量计划，规划 broker、主题、分区和副本的数量，才能避免 Kafka 扩展导致的问题。这是理想状况，实际情况很难规划，不可避免会出现扩展需求。
5. Kafka 集群的分区再均衡会影响相关生产者和消费者的性能。
6. 发生故障时，Kafka 主题无法保证消息的完整性（特别是遇到第 3 点中的情况，需要扩展时极有可能丢失消息）。
7. 使用 Kafka 需要和 offset 打交道，这点让人很头痛，因为 broker 并不维护 consumer 的消费状态。
8. 如果使用率很高，则必须尽快删除旧消息，否则就会出现磁盘空间不够用的问题。
9. 众所周知，Kafka 原生的跨地域复制机制（MirrorMaker）有问题，即使只在两个数据中心也无法正常使用跨地域复制。因此，甚至 Uber 都不得不创建另一套解决方案来解决这个问题，并将其称为 uReplicator (https://eng.uber.com/ureplicator/)。
10. 要想进行实时数据分析，就不得不选用第三方工具，如 Apache Storm、Apache Heron 或 Apache Spark。同时，你需要确保这些第三方工具足以支撑传入的流量。
11. Kafka 没有原生的多租户功能来实现租户的完全隔离，它是通过使用主题授权等安全功能来完成的。

kafka部署

官方文档：https://kafka.apache.org/quickstart

Kafka需要zookeeper，就使用zookeeper的三台服务器：201、202、203

下载安装kafka并且修改配置文件

tar xvf kafka 2.13-2.71.tqz
进入目录修改配置文件：
root@k8s-server1:/apps# cd kafka_2.13-2.7.1/
root@k8s-server1:/apps/kafka_2.13-2.7.1# vim config/server.properties
broker.id=1
broker.id=3
三个分别修改监听地址：
listeners=PLAINTEXT://10.0.0.201:9092
listeners=PLAINTEXT://10.0.0.202:9092
listeners=PLAINTEXT://10.0.0.203:9092
修改三台服务器的路劲：
复制会话：
root@k8s-server1:~# mkdir /data/kafka
root@10ubuntu-yangk:~#  mkdir /data/kafka
root@10ubuntu-yangk:~# mkdir /data/kafka
log.dirs= /data/kafka
log.dirs= /data/kafka
log.dirs= /data/kafka
三台服务器修改分片数量，也可以在程序中指定：老师是3
num.partitions=1
数据在kafka默认保存时间：默认一周
log.retention.hours=168
zookeeper的集群地址：（三台一样）
zookeeper.connect=10.0.0.201:2181,10.0.0.202:2181,10.0.0.203:2181

启动：

官方启动：
# Start the Kafka broker service
$ bin/kafka-server-start.sh config/server.properties
/apps/kafka/bin/kafka-server-start.sh /apps/kafka/config/server.properties &

进入zookeeper验证：

可以看到三个kafka成功注册到zookeeper中。

测试kafka读写数据

http://kafka.apache.org/quick tart
3.5.1：创建topic：创建名为logstashtest，partitions（分区]为3，replication（每个分区的副本数/每个分区的分区因子）为3的topic（主题）：
在任意kafaka服务器操作：
#/usr/local/kafka/bin/kafka-topics.sh--create--zookeeper
10.0.0.201:2181,10.0.0.202:2181,10.0.0.203:2181
--partitions 3
-replication-factor 3--topic magedu
指定分区：
在任一个kafka服务器运行：
root@k8s-server1:/apps/kafka_2.13-2.7.1# /apps/kafka/bin/kafka-topics.sh --create  --zookeeper 10.0.0.201:2181,10.0.0.202:2181,10.0.0.203:2181 --partitions 3 --replication-factor 1 --topic m43    #杰哥这里改成3个分片有改成一个了。

Zookeeper断开重连，会发现kafka分区已经写入：

kafka集群模拟写入消费数据

通过终端模拟生产者
/apps/kafka/bin/kafka-console-producer.sh --broker-list  10.0.0.201:9092,10.0.0.202:9092,10.0.0.203:9092 --topic m43
>msg1
>msg2

用kafka tool来查看数据

消费数据

到203上去消费：
/apps/kafka/bin/kafka-console-consumer.sh --topic m43 --bootstrap-server 10.0.0.201:9092,10.0.0.202:9092,10.0.0.203:9092 --from-beginning

zabbbix监控kafka集群

打开zabbix server centos7 .2 并连接
http://10.0.0.132/zabbix/

kafka版本查看以及监控指标

root@k8s-server1:~# find / -name "libs"
/apps/kafka_2.13-2.7.1/libs
root@k8s-server1:~# cd /apps/kafka_2.13-2.7.1/libs
root@k8s-server1:/apps/kafka_2.13-2.7.1/libs# ls -l kafka*

监控指标：

AllTopicsMessagesInPerSec  #所有的topic的消息速率(消息数/秒)
AllTopicsBytesInPerSec     #所有的topic的流入数据速率(字节/秒)
{Produce|Fetch-consumer|Fetch-follower}-RequestsPerSec  #producer或Fetch-consumer或Fetch-follower的请求速率(请求次数/秒)
AllTopicsBytesOutPerSec    #所有的topic的流出数据速率(字节/秒)
LogFlushRateAndTimeMs      #刷日志的速率和耗时
UnderReplicatedPartitions  #正在做复制的partition的数量(|ISR| < |all replicas|)
ActiveControllerCount      #当前的broker是否为controller
LeaderElectionRateAndTimeMs #选举leader的速率
UncleanLeaderElectionsPerSec #Unclean的leader选举速率
PartitionCount               #该broker上的partition的数量
LeaderCount                  #Leader的replica的数量
ISRShrinksPerSec             #ISR的收缩(shrink)速率
ISRExpandsPerSec             #ISR的扩大(expansion)速率
([-.\w]+)-MaxLag             #follower落后leader replica的最大的消息数量
([-.\w]+)-ConsumerLag        #每个follower replica落后的消息速率
PurgatorySize                #等待producer purgatory的请求数
{Produce|Fetch-Consumer|Fetch-Follower}-TotalTimeMs  #一个请求(producer,Fetch-Consumer,Fetch-Follower)耗费的所有时间
{Produce|Fetch-Consumer|Fetch-Follower}-QueueTimeMs  #请求(producer,Fetch-Consumer,Fetch-Follower)在请求队列中的等待时间
“{Produce|Fetch-Consumer|Fetch-Follower}-RemoteTimeMs #请求(producer,Fetch-Consumer,Fetch-Follower)等待follower花费的时间
{Produce|Fetch-Consumer|Fetch-Follower}-ResponseSendTimeMs #发送响应花费的时间

编辑kafka配置文件，开启JMX

root@k8s-server1:/apps/kafka_2.13-2.7.1/bin# vim kafka-server-start.sh
export JMX_PORT="12345"

重启：
/apps/kafka/bin/kafka-server-stop.sh /apps/kafka/bin/kafka-server-start.sh /apps/kafka/config/server.properties &

安装java-gateway并修改配置文件

安装zabbix-java-gateway
[root@zbx-server ~]# yum install zabbix-java-gateway –y
修改配置文件，启用JMX监视器的数量：
[root@zbx-server~]# vim /etc/zabbix/zabbix_java_gateway.conf
搜索：START_POLLERS
注释删掉就可以了，java进程多的话可以多启动一些
其他默认配置

修改zabbix server文件指定zabbix-java-gateway地址

[root@zbx-server ~]# vim /etc/zabbix/zabbix_server.conf
JavaGateway=127.0.0.1
StartJavaPollers=5         #监视器数量和上面保持一致就可以了

启动zabbix-java-gateway
systemctl restart zabbix-server && systemctl start zabbix-java-gateway  && systemctl enable zabbix-java-gateway

验证：

 netstat -ntlp |grep 10052

433web端配置：

添加主机和JMX代理：

选择模板：

成功：

扩展阅读：https://dubbo.apache.org/zh/blog/java/codeanalysis/3.0.8/

什么是Dubbo

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。
在云原生时代，Dubbo 相继衍生出了 Dubbo3、Proxyless Mesh 等架构与解决方案，在易用性、超大规模微服务实践、云原生基础设施适配、安全性等几大方向上进行了全面升级。
Dubbo 的开源故事
Apache Dubbo 最初是为了解决阿里巴巴内部的微服务架构问题而设计并开发的，在十多年的时间里，它在阿里巴巴公司内部的很多业务系统的到了非常广泛的应用。最早在 2008 年，阿里巴巴就将 Dubbo 捐献到开源社区，它很快成为了国内开源服务框架选型的事实标准框架，得到了业界更广泛的应用。在 2017 年，Dubbo 被正式捐献 Apache 软件基金会并成为 Apache 顶级项目，开始了一段新的征程。
Dubbo 被证实能很好的满足企业的大规模微服务实践，并且能有效降低微服务建设的开发与管理成本，不论是阿里巴巴还是工商银行、中国平安、携程、海尔等社区用户，它们都通过多年的大规模生产环境流量对 Dubbo 的稳定性与性能进行了充分验证。后来 Dubbo 在很多大企业内部衍生出了独立版本，比如在阿里巴巴内部就基于 Dubbo 衍生出了 HSF，HSF 见证了阿里巴巴以电商业务为首的微服务系统的快速发展。自云原生概念推广以来，各大厂商都开始拥抱开源标准实现，阿里巴巴将其内部 HSF 系统与开源社区 Dubbo 相融合，与社区一同推出了云原生时代的 Dubbo3 架构，截止 2022 年双十一结束，Dubbo3 已经在阿里巴巴内部全面取代 HSF 系统，包括电商核心、阿里云等核心系统已经全面运行在 Dubbo3 之上。

为什么需要 Dubbo，它能做什么？

按照微服务架构的定义，采用它的组织能够很好的提高业务迭代效率与系统稳定性，但前提是要先能保证微服务按照期望的方式运行，要做到这一点需要解决服务拆分与定义、数据通信、地址发现、流量管理、数据一致性、系统容错能力等一系列问题。
Dubbo 可以帮助解决如下微服务实践问题：
• 微服务编程范式和工具
Dubbo 支持基于 IDL 或语言特定方式的服务定义，提供多种形式的服务调用形式（如同步、异步、流式等）
• 高性能的 RPC 通信
Dubbo 帮助解决微服务组件之间的通信问题，提供了基于 HTTP、HTTP/2、TCP 等的多种高性能通信协议实现，并支持序列化协议扩展，在实现上解决网络连接管理、数据传输等基础问题。
• 微服务监控与治理
Dubbo 官方提供的服务发现、动态配置、负载均衡、流量路由等基础组件可以很好的帮助解决微服务基础实践的问题。除此之外，您还可以用 Admin 控制台监控微服务状态，通过周边生态完成限流降级、数据一致性、链路追踪等能力。
• 部署在多种环境
Dubbo 服务可以直接部署在容器、Kubernetes、Service Mesh等多种架构下。
• 活跃的社区
Dubbo 项目托管在 Apache 社区，有来自国际、国内的活跃贡献者维护着超 10 个生态项目，贡献者包括来自海外、阿里巴巴、工商银行、携程、蚂蚁、腾讯等知名企业技术专家，确保 Dubbo 及时解决项目缺陷、需求及安全漏洞，跟进业界最新技术发展趋势。
• 庞大的用户群体
Dubbo3 已在阿里巴巴成功取代 HSF 框架实现全面落地，成为阿里集团面向云原生时代的统一服务框架，庞大的用户群体是 Dubbo 保持稳定性、需求来源、先进性的基础。

Dubbo 不是什么？

• 不是应用开发框架的替代者
Dubbo 设计为让开发者以主流的应用开发框架的开发模式工作，它不是各个语言应用开发框架的替代者，如它不是 Spring/Spring Boot 的竞争者，当你使用 Spring 时，Dubbo 可以无缝的与 Spring & Spring Boot 集成在一起。
• 不仅仅只是一款 RPC 框架
Dubbo 提供了内置 RPC 通信协议实现，但它不仅仅是一款 RPC 框架。首先，它不绑定某一个具体的 RPC 协议，开发者可以在基于 Dubbo 开发的微服务体系中使用多种通信协议；其次，除了 RPC 通信之外，Dubbo 提供了丰富的服务治理能力与生态。
• 不是 gRPC 协议的替代品
Dubbo 支持基于 gRPC 作为底层通信协议，在 Dubbo 模式下使用 gRPC 可以带来更好的开发体验，享有统一的编程模型和更低的服务治理接入成本
• 不只有 Java 语言实现
自 Dubbo3 开始，Dubbo 提供了 Dubbo、Golang、Rust、Node.js 等多语言实现，未来会有更多的语言实现。

Dubbo 核心概念和架构

Dubbo 数据面
从数据面视角，Dubbo 帮助解决了微服务实践中的以下问题：
• Dubbo 作为 服务开发框架 约束了微服务定义、开发与调用的规范，定义了服务治理流程及适配模式
• Dubbo 作为 RPC 通信协议实现 解决服务间数据传输的编解码问题

服务开发框架

微服务的目标是构建足够小的、自包含的、独立演进的、可以随时部署运行的分布式应用程序，几乎每个语言都有类似的应用开发框架来帮助开发者快速构建此类微服务应用，比如 Java 微服务体系的 Spring Boot，它帮 Java 微服务开发者以最少的配置、最轻量的方式快速开发、打包、部署与运行应用。
微服务的分布式特性，使得应用间的依赖、网络交互、数据传输变得更频繁，因此不同的应用需要定义、暴露或调用 RPC 服务，那么这些 RPC 服务如何定义、如何与应用开发框架结合、服务调用行为如何控制？这就是 Dubbo 服务开发框架的含义，Dubbo 在微服务应用开发框架之上抽象了一套 RPC 服务定义、暴露、调用与治理的编程范式，比如 Dubbo Java 作为服务开发框架，当运行在 Spring 体系时就是构建在 Spring Boot 应用开发框架之上的微服务开发框架，并在此之上抽象了一套 RPC 服务定义、暴露、调用与治理的编程范式。

Dubbo 作为服务开发框架包含的具体内容如下：

• RPC 服务定义、开发范式。比如 Dubbo 支持通过 IDL 定义服务，也支持编程语言特有的服务开发定义方式，如通过 Java Interface 定义服务。
• RPC 服务发布与调用 API。Dubbo 支持同步、异步、Reactive Streaming 等服务调用编程模式，还支持请求上下文 API、设置超时时间等。
• 服务治理策略、流程与适配方式等。作为服务框架数据面，Dubbo 定义了服务地址发现、负载均衡策略、基于规则的流量路由、Metrics 指标采集等服务治理抽象，并适配到特定的产品实现。
想了解如何使用 Dubbo 微服务框架进行业务编码？从以下 SDK 开始微服务项目开发之旅吧：
• Java
• Golang
• Rust
• Node
通信协议
Dubbo 从设计上不绑定任何一款特定通信协议，HTTP/2、REST、gRPC、JsonRPC、Thrift、Hessian2 等几乎所有主流的通信协议，Dubbo 框架都可以提供支持。 这样的 Protocol 设计模式给构建微服务带来了最大的灵活性，开发者可以根据需要如性能、通用型等选择不同的通信协议，不再需要任何的代理来实现协议转换，甚至你还可以通过 Dubbo 实现不同协议间的迁移。

Dubbo Protocol 被设计支持扩展，您可以将内部私有协议适配到 Dubbo 框架上，进而将私有协议接入 Dubbo 体系，以享用 Dubbo 的开发体验与服务治理能力。比如 Dubbo3 的典型用户阿里巴巴，就是通过扩展支持 HSF 协议实现了内部 HSF 框架到 Dubbo3 框架的整体迁移。
Dubbo 还支持多协议暴露，您可以在单个端口上暴露多个协议，Dubbo Server 能够自动识别并确保请求被正确处理，也可以将同一个 RPC 服务发布在不同的端口（协议），为不同技术栈的调用方服务。
Dubbo 提供了两款内置高性能 Dubbo2、Triple (兼容 gRPC) 协议实现，以满足部分微服务用户对高性能通信的诉求，两者最开始都设计和诞生于阿里巴巴内部的高性能通信业务场景。
• Dubbo2 协议是在 TCP 传输层协议之上设计的二进制通信协议
• Triple 则是基于 HTTP/2 之上构建的支持流式模式的通信协议，并且 Triple 完全兼容 gRPC 但实现上做了更多的符合 Dubbo 框架特点的优化。
总的来说，Dubbo 对通信协议的支持具有以下特点：
• 不绑定通信协议
• 提供高性能通信协议实现
• 支持流式通信模型
• 不绑定序列化协议
• 支持单个服务的多协议暴露
• 支持单端口多协议发布
• 支持一个应用内多个服务使用不同通信协议
Dubbo 服务治理
服务开发框架解决了开发与通信的问题，但在微服务集群环境下，我们仍需要解决无状态服务节点动态变化、外部化配置、日志跟踪、可观测性、流量管理、高可用性、数据一致性等一系列问题，我们将这些问题统称为服务治理。
Dubbo 抽象了一套微服务治理模式并发布了对应的官方实现，服务治理可帮助简化微服务开发与运维，让开发者更专注在微服务业务本身。
服务治理抽象
以下展示了 Dubbo 核心的服务治理功能定义

使用nexus构建私有yum仓库示例：

安装nexus（略）

创建仓库

配置web端：

创建存储：

mkdir /data/nexus/yum -p

配置web端存储

创建成功：

新建repo文件：

vim /etc/yum.repos.d/zabbix-4.4.repo
[zabbix-nexus]
name=zabbix 
baseurl=http://10.0.0.206:8081/repository/zabbix-nexus/
enabled=1
gpgcheck=0

验证：

yum list zabbix-agent

安装测试：

yum install zabbix-agent -y

浏览验证：

成功。