我有一个问题,围绕着可能是正常设置的微服务和Kafka,我们目前正在设置我的思想。
我们在Kafka有一个主题,多个消费者通过不同的消费群体阅读这个主题。但不知何故,我认为这可能会导致微服务方面的耦合,因为我们有两个消费者从同一主题中读取确切的数据。此外,我们没有任何消息的保留时间,因此我将kafka视为某种数据存储。因此,我认为我们更应该将消息复制到另一个服务/使用者的主题中。
我们对这是耦合还是解耦有不同的看法,我想听听你们对我错在哪里的看法,因为我觉得我错了。谢谢你的支持!
我有一个问题,围绕着可能是正常设置的微服务和Kafka,我们目前正在设置我的思想。
我们在Kafka有一个主题,多个消费者通过不同的消费群体阅读这个主题。但不知何故,我认为这可能会导致微服务方面的耦合,因为我们有两个消费者从同一主题中读取确切的数据。此外,我们没有任何消息的保留时间,因此我将kafka视为某种数据存储。因此,我认为我们更应该将消息复制到另一个服务/使用者的主题中。
我们对这是耦合还是解耦有不同的看法,我想听听你们对我错在哪里的看法,因为我觉得我错了。谢谢你的支持!
1条答案
按热度按时间dgiusagp1#
在我看来,使用一个Kafka主题的多个服务或应用程序消费是正确的方法,只要你的服务不依赖它重复。这意味着服务应该读取队列一次,将数据转换为它所需要的任何内容,并在需要时自行存储。这样,主题就不会成为一个永久性的数据存储,而是一种解耦的输入数据的方式(就好像您要用它直接调用服务一样)
raw
数据,但以一种更解耦的方式,允许服务在任何时候以任何需要的频率读取主题。这增加了整个系统的弹性。还有一个耦合,就是
raw
数据。但从我的Angular 来看,多个服务完全可以理解(主题的)相同的数据格式——只要其格式基本上是稳定的。这里的假设是raw
每个服务必须转换为对自身有用的形式的数据。你只要确保raw
每当需要更改时,数据格式都会得到正确的版本控制。为了让服务继续工作,您必须同时交付多个版本,直到所有服务都支持最新版本。许多大型系统和工程都使用这种类型的体系结构样式,只要您没有需要raw
数据格式经常更改,使其与您的服务设计不兼容(如果是这样的话,您可能需要下面的另一层稳定的元模型来描述动态的原始数据。)