服务定义：
服务定义是声明给定服务如何被消费者/客户端使用的方式。在建立服务之间的同步通信通道之前，它会与消费者共享。
同步通信中的服务定义：
微服务可以将其服务定义发布到服务注册表（或由微服务所有者手动发布）。然后这些微服务的消费者可以连接到服务注册表并获取服务定义（通过程序或由开发人员手动进行）。这个步骤被称为服务发现。
您的每个微服务发布都符合带有不同版本的广告服务定义。
消费者获得的服务定义可用于构建客户端应用程序或生成与服务器通信所需的客户端库。服务定义包含给定服务提供的接口，以及客户端和微服务之间交换的消息格式和数据类型的模式。
服务注册表通常是实现为元数据仓库，具有用于管理服务定义和其他元数据的 API。一些可以做到这一点的工具有Consul、etcd 和 Apache ZooKeeper。在大多数部署中，我们可以将服务注册表作为集中式组件运行。
异步通信中的服务定义
生产者和消费者之间交换的消息包含使用模式进行序列化或反序列化的结构化数据，该模式定义并验证各方之间交换的数据。由于通过消息代理或事件总线异步进行通信，执行生成和消费消息的微服务应使用公共模式。与同步消息传递场景中的服务定义类似，生产者和消费者微服务必须使用中央元数据注册表来存储模式。
当两个微服务使用异步消息驱动通信时，生产者可以在将消息发布到消息代理的队列或主题时，对消息进行模式（存储在模式注册表中）验证。
模式定义技术：Apache Avro、Protocol Buffers 或 JSON schemas等。
根据您使用的代理类型，模式定义技术可能会有所不同。例如，Kafka注册表支持Avro、JSON 和 Protocol Buffers，Azure在其Event Hubs消息服务中使用Azure模式注册表。
新兴的异步服务定义技术，如AsyncAPI，可以用于指定整个服务合同，而不仅仅是消息的模式。
复杂性的注意事项：
大多数异步消息传递是在不使用基于模式的序列化和反序列化的情况下实现的。这通常导致生产者和消费者之间的不一致和数据类型不匹配。此外，需要发送随消息一起传输的元数据会增加消息大小，从而降低异步通信的性能。因此，在异步通信中采用模式对于确保云原生应用程序的可靠性和安全性至关重要。
我们讨论了生产者和消费者端的模式验证。这本质上引入了性能开销，因为每个消息都需要经过验证过程。同时，从注册表中获取模式可能需要缓存机制，以避免性能瓶颈。
