11

GCP消息队列Pubsub详解,简单好用还不用自己运维

 2 years ago
source link: https://www.pkslow.com/archives/gcp-pubsub
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
GCP消息队列Pubsub详解,简单好用还不用自己运维 | 南瓜慢说官方网站技术之前,先读诗书:

前年伐月支,城下没全师。

GCP的Pubsub是一种异步消息传递服务,可将生产事件的服务与处理事件的服务隔离开。消息队列的作用就不多作介绍了,与Kafka、RabbitMQ等差不多。使用Pubsub一个重要原因是不用自己去管理整个中间件的运维,将专业的事交给专业的团队去做。这样,其实也是一种节约成本的方式。

GCP还提供了更低费用的Pubsub Lite,这里不多作介绍了。

2.1 基本概念

一些重要的核心概念:

  • 主题:生产者向其发送消息的资源;
  • 订阅:单个特定主题的消息流资源,任何一个订阅都要从属于某个主题,对哪个主题感兴趣,就订阅哪个主题;
  • 消息:传输的数据和特性;
  • 发布者:也叫生产者,负责将消息发到主题;
  • 订阅者:也叫消费者,负责将消息从订阅中读取。

他们的关系:发布者发消息到某个特定主题,而主题下有一个或多个订阅,订阅者从订阅读取消息。所以发布者和订阅者的关系有如下:

如下图所示:

2.2 消息传递过程

整个消息传递的流程大致如下:

(1)发布者向主题发送消息,消息包含要发送的数据和消息的特性;

(2)系统收到消息后,会存在GCP的系统中;

(3)系统将主题的消息转发到订阅中去;

(4)Pubsub将消息推送给订阅者,或者订阅者拉取消息;

(5)订阅者收到信息后,返回Ack确认信息;

(6)Pubsub移除已确认的消息。

2.3 集成其它组件

整个GCP的Stack可以相互集成,其它组件如Pubsub集成如下:

3 Pubsub快速入门

3.1 使用gcloud命令行

使用SDK命令行工具gcloud的入门操作如下:

# 创建主题
$ gcloud pubsub topics create pkslow-topic

# 创建订阅
$ gcloud pubsub subscriptions create pkslow-sub --topic=pkslow-topic

# 发布消息
$ gcloud pubsub topics publish pkslow-topic --message="www.pkslow.com"

# 接收消息
$ gcloud pubsub subscriptions pull pkslow-sub --auto-ack

3.2 使用客户端库

Pubsub支持的语言很丰富,包括Python、Java、C++、Go、Node.js、PHP等,一般项目都可以使用得上。之前的文章《整合Spring Cloud Stream Binder与GCP Pubsub进行消息发送与接收》讲解了Java的整合,这里先不再展开讲解。

4 消息排序

消息排序是一个很有用的特性,它能保证消息的顺序,即发布者发的是消息A-B-C-D,接收就应该是A-B-C-D,而不是A-B-D-C或其它。Pubsub的消息排序需要发布者和订阅者双方配合:

(1)发布者必须在发消息时指定排序键(Ordering Key),这个Key不是告诉Pubsub按什么排序,而是告诉Pubsub我哪些消息要排序。排序都是按时间的,Key的作用是同一个Key的所有消息都要排序。不同Key的消息,没有顺序关系,不需要排序。所以,要为需要按时间顺序的消息指定同一个Key。

(2)订阅需要打开排序特性,不然即使消息有Ordering Key,也不会排序。

排序特性是很有用的,但会带来性能的损伤。

遇到的一些难点:

(1)对于Java开发,Spring Cloud Stream还没有支持Pubsub排序功能,所以需要使用Google的SDK来开发,或者对Spring Cloud Stream进行改造。

(2)对于多消费者的情况,Pubsub会尽量把同一个Key的消息分发到一个消息者中以保证有序性。这样会造成在Auto Scale的情况下,有时难以让其它消费者捡起消息来消费,这个可以通过配置Outstanding的大小来控制。

5.1 监控

GCP有成熟的监控套件Cloud Monitoring,我们直接用就可以了。可以查看发送了多少消息、多少消息待消费等。

5.2 消费者自动扩容

如果消费者的处理速度太慢,可以增加它的数量来解决问题。方案是根据Pubsub滞留的消息数来自动扩容。可以有两个方案,一个是利用Keda来做,另一个是利用Cloud Monitor来做。两者都是类似的,获取队列的大小,然后通过Kubernetes的HPA进行弹性伸缩。

Keda的相关文章可以看:《Kubernetes使用Keda进行弹性伸缩,更合理利用资源

Pubsub使用起来还是挺简单的,毕竟只用写生产者和消费者即可。但细节也很多,有空再慢慢道来吧。


Autoscaling with Cloud Monitoring


欢迎关注微信公众号<南瓜慢说>,将持续为你更新...

推荐阅读:
如何制定切实可行的计划并好好执行
容器技术(Docker-Kubernetes)
SpringBoot-Cloud相关
Https专题


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK