我想知道基于事件驱动架构的流管道中的微服务如何才能从数据模型的角度真正分离。我们已经使用事件驱动架构实现了数据处理管道，其中数据模型非常关键。尽管从业务的角度来看，所有微服务都是分离的，但由于所有服务之间都共享数据模型，因此它们并不是真正分离的。
在摄取管道中，我们从多个来源收集了具有不同数据模型的数据。因此，需要规范化微服务以将那些数据模型规范化为可由下游使用者使用的通用数据模型。挑战在于数据模型可以出于任何原因进行更改，我们应该能够在此处轻松管理更改。但是，这种级别的更改可能会破坏消费者的应用程序，并且很容易对所有微服务进行一系列修改。
在这种情况下，有没有可以真正解耦微服务的解决方案或技术？
答案 0 :(得分：0)
通过精心设计数据模型以确保向后和向前兼容，可以解决此问题。这样的设计对于服务的独立演进，滚动升级等非常重要。如果新客户端（使用新模型）可以读取/写入另一个客户端（使用旧模型）编写的数据，则数据模型被认为是向后兼容的。同样，前向兼容性意味着一个客户端（使用旧数据模型）可以读写另一个客户端（使用新数据模型）写入的数据。
假设Person对象中的服务以JSON编码格式在服务之间共享。现在，其中一项服务引入了一个新字段alternateContact。使用此数据并使用旧数据模型的服务可以简单地忽略此新字段并继续其操作。如果您使用的是Jackson库，请使用@JsonIgnoreProperties(ignoreUnknown = true)。因此，消费服务旨在实现前向兼容性。
当服务（使用旧数据模型）反序列化用新模型写入的Person数据，更新一个或多个字段值并将数据写回时，就会出现问题。由于未知属性将被忽略，因此写入将导致数据丢失。
幸运的是，二进制编码格式（例如Protocol Buffer 3.5和更高版本）会在使用旧模型进行反序列化期间保留未知字段。因此，当您序列化数据时，新字段将保持原样。
您可能还需要处理其他数据模型的演变，例如字段移除，字段重命名等。鼻翼的想法是，您需要在设计阶段的早期就意识到并计划这些可能性。常见的数据编码格式为JSON，Apache Thrift，协议缓冲区，Avro等。