什么是 Service Registry 服务注册表？

服务注册表是一种数据库，用来存储应用级通信的数据结构。它相当于一个中央枢纽，供应用开发人员注册和查找用于特定应用的架构。

确保正确使用重要数据

现代软件设计离不开分布式、松散耦合的微服务，通过应用编程接口（API）交换数据。

在大型企业及更大的企业中，这种应用间的数据交换是关键任务。所有应用每分每秒都在来回发送数据，让业务正常运转。所以，确保这些数据的完整性就无比重要。如何确保所有不同的应用都能得到妥当设置，以便正确使用这些重要数据？关键解决方案之一就是服务注册表。

例如，Apache Kafka 等传输数据的消息传递系统不提供自带的数据验证。如果数据生产者发送了不可消费的数据，会发生什么？例如，如果生产者添加或移除了某一字段或改变了数据格式？如果数据消费者不清楚这一变化，就无法正确处理数据，最糟时可能会导致整个系统发生瘫痪。

确保消费者了解生产者使用的架构

在任何数据交换发生之前，数据消费者需要了解生产者所使用的数据结构（称为"架构"）。消费者还需要知道对架构进行任何更改的时间。数据在发展的同时，也必须保证不会导致消息传递系统出现中断。

生产者可以手动将架构发送给消费者，例如发送附加了相关文件的电子邮件。不过，与许多手动流程一样，这可能会比较复杂、容易出错并且难以审查，最终造成服务停止工作，而且不能轻松找出故障的起因。

另一方面，服务注册表可以通过一个便于访问的平台提供此信息。它相当于一个中央枢纽，供生产者应用的开发人员注册用于特定应用的架构。消费者应用的开发人员也使用服务注册表来查找架构，以便应用可以使用来自该生产者的数据。可以存储在服务注册表中的架构有 Apache Avro、JSON Schema 和 Google Protocol Buffer 等。

充当给定应用的数据结构的单一事实来源

除了架构外，服务注册表还可存储其他资源，也称为"工件"。例如，应用级同步通信的 API 规范也可存储在服务注册表中。随着服务变得更加繁多复杂，服务注册表的用处也更大。

服务注册表概念由来已久，但最近才又重新成为关注点，因为它非常适合微服务世界中的这一必要用途。服务注册表可充当给定应用的数据结构的单一事实来源，得到生产者应用和消费者应用开发人员的共同认可。它支持"契约优先"方法。服务注册表并非先编写应用，事后再提供契约让其他应用或企业能够与您的应用通信，而是提前规定这种契约，包括输入、输出、负载规范，乃至验证规则。一切都事先清楚交代，因此各方都能了解交互的方式。

我们以 Apache Kafka 作为用例来探讨服务注册表的工作方式。服务注册表是这一用例的理想选择，因为 Kafka 不自动向消费者提供数据结构，而且 Kafka 也不提供任何数据验证。由于 Kafka 不解析（甚至也不读取）您的数据，因此不会占用重要的资源，因而能够非常迅速地将数据直接分发给消费者。如果 Kafka 确实要花费时间来验证数据，那么性能就会大大降低。所以缺少数据监管对 Kafka 来说不是问题。相反，它可以实现 Kafka 的一大优势：高性能。

然而，您必须对数据结构实施其他监管，以便消费应用可以正确地消费这些数据。解决方案就是服务注册表，它不仅提供规则，也实施规则。

消费者和生产者通过 Kafka 交换数据，而使用服务注册表能让生产者和消费者从一开始就记录、共享和认可定义此通信的元数据，以避免之后发生数据相关的错误。元数据以架构的形式提供，存储在服务注册表中。

生产者应用的开发人员将架构注册到服务注册表中，后者确保生产者遵循其自身架构的规范。服务注册表甚至还可以更进一步，拒绝不遵循已注册架构的不良数据。

架构可以由特定生产者应用的开发人员注册（如上例中所示），也可由企业进行注册（以便在开发团队中共享使用）。在这第二种情形中，服务注册表会充当供生产者应用和消费者应用的开发人员使用的库。

同时，消费者应用的开发人员也以库的形式使用服务注册表，检索其中的架构，以便构建应用来消费来自生产者应用的数据。当架构发生变化时，服务注册表会向消费者提供最近更新的架构。

服务注册表为开发团队和企业提供以下优势：

将数据结构与应用分离

您可以使用服务注册表来使数据结构与应用分离，并利用 REST 接口在运行时共享和管理您的数据结构和 API 描述。

卓越的数据质量

服务注册表可以验证数据的架构并检测数据中的错误，以确保数据完整性。服务注册表可以包含规则，确保上传的内容在语法和语义上有效，并且向前和向后兼容其他版本。不过，服务注册表会阻止生产者发送与架构不相符的不良数据。

单一记录的事实来源

服务注册表提供单一事实来源，由涉及的各方共同验证和认可。

提高开发人员生产率

服务注册表可以一致地重复利用架构和 API 设计，从而节省开发人员在构建生产者或消费者应用时所花费的时间。

节省成本

在开发者生命周期中尽早（而不是在运行时）检测数据相关错误，可以节省在流程下游修正错误而花费的高代价开发时间。