假设我有几个微服务，每个微服务都公开一组 REST 端点。假设微服务 A 正在与微服务 B 通信并且它们交换 JSON 数据。
这个 JSON 数据需要在微服务 A 和 B 上进行序列化和反序列化。这个序列化逻辑和模型在微服务代码库上是相同的。
我可以通过将模型类移动到一个小的依赖项中并在两个微服务上使用它来减少这种重复。不是问题！这可能与“不共享”的微服务架构的目标背道而驰。但我觉得更潜在的问题是代码重复。大家觉得呢？
【问题讨论】：
标签： scala playframework-2.2 microservices
在这种情况下，我看不到“不分享任何东西”的意义。只要您将 De/Serializer 作为工件保存在某个关系中，您就不会“共享”任何东西，而是使用（不知何故）外部库。 如果你使用例如记录，您的两个项目都将使用例如slf4s，但他们不共享它，因为每个人都单独使用它。
【讨论】：
在将功能分离为通信微服务时需要牢记以下几点：
如果您的服务器需要特定版本的 scala（例如，因为您使用的库仅适用于 2.10 版本），这不会影响您在客户端中选择 scala 版本。这指向了让类代表您的通信路径的想法，因为它位于一个可以单独交叉编译的单独项目中。
共享库对客户端代码的要求越少越好。即使强制选择特定的 Play 服务器也会在客户端和服务器之间强制执行一定程度的刚性和耦合，这是最好避免的。
最好的选择是这个库导致对零个其他库的依赖。
拥有独立服务的优点之一是它们可以在不同的时间点进行升级和改进。无论何时更改，您都应始终尝试让服务器支持以前版本的通信协议。这使您可以轻松回滚更新，并在不同的时间点更新客户端。
不允许向后兼容意味着您需要同步更新这两个服务。这不仅减少了使用微服务的许多优势，而且如果有必要，处理回滚也会变得非常痛苦。
这里的通用故事是通过在服务器上做出的选择，尽可能少地强制客户端上的选择方式（scala 版本、库版本、必须发生协议更改的时间段）。
如果您可以遵循这种方法，我认为使用代码来增强与服务对话的可访问性没有问题。
【讨论】：