云原生应用里的服务发现-Toy模板网

这篇具有很好参考价值的文章主要介绍了云原生应用里的服务发现。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

服务定义：

服务定义是声明给定服务如何被消费者/客户端使用的方式。在建立服务之间的同步通信通道之前，它会与消费者共享。

同步通信中的服务定义：

微服务可以将其服务定义发布到服务注册表（或由微服务所有者手动发布）。然后这些微服务的消费者可以连接到服务注册表并获取服务定义（通过程序或由开发人员手动进行）。这个步骤被称为服务发现。

您的每个微服务发布都符合带有不同版本的广告服务定义。

Image.png

消费者获得的服务定义可用于构建客户端应用程序或生成与服务器通信所需的客户端库。服务定义包含给定服务提供的接口，以及客户端和微服务之间交换的消息格式和数据类型的模式。

服务注册表通常是实现为元数据仓库，具有用于管理服务定义和其他元数据的 API。一些可以做到这一点的工具有Consul、etcd 和 Apache ZooKeeper。在大多数部署中，我们可以将服务注册表作为集中式组件运行。

异步通信中的服务定义

生产者和消费者之间交换的消息包含使用模式进行序列化或反序列化的结构化数据，该模式定义并验证各方之间交换的数据。由于通过消息代理或事件总线异步进行通信，执行生成和消费消息的微服务应使用公共模式。与同步消息传递场景中的服务定义类似，生产者和消费者微服务必须使用中央元数据注册表来存储模式。

当两个微服务使用异步消息驱动通信时，生产者可以在将消息发布到消息代理的队列或主题时，对消息进行模式（存储在模式注册表中）验证。

Image.png

模式定义技术：Apache Avro、Protocol Buffers 或 JSON schemas等。

根据您使用的代理类型，模式定义技术可能会有所不同。例如，Kafka注册表支持Avro、JSON 和 Protocol Buffers，Azure在其Event Hubs消息服务中使用Azure模式注册表。

新兴的异步服务定义技术，如AsyncAPI，可以用于指定整个服务合同，而不仅仅是消息的模式。

大多数异步消息传递是在不使用基于模式的序列化和反序列化的情况下实现的。这通常导致生产者和消费者之间的不一致和数据类型不匹配。此外，需要发送随消息一起传输的元数据会增加消息大小，从而降低异步通信的性能。因此，在异步通信中采用模式对于确保云原生应用程序的可靠性和安全性至关重要。

我们讨论了生产者和消费者端的模式验证。这本质上引入了性能开销，因为每个消息都需要经过验证过程。同时，从注册表中获取模式可能需要缓存机制，以避免性能瓶颈。文章来源地址https://www.toymoban.com/news/detail-629686.html

到了这里，关于云原生应用里的服务发现的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！