微服务架构 - 管理参考数据和其他常见的东西

Question

我们正在基于现有的庞大单体应用程序设计新的微服务架构。

我们阅读了很多关于如何设计微服务以及它们如何通信的信息，但我找不到关于这个“问题”的任何信息：

假设我们有两个管理“建筑物”的微服务和另一个管理“人员”的微服务；

但是，现在我们还有另一个微服务也用于管理“参考数据”（如国家、州等）和另一个用于管理“用户偏好”的微服务。

我们如何管理一个人“包含”一个国家（对于国籍）和一个建筑物也包含一个国家（对于它的地址）？

当用户调用其中一个业务微服务（Person 或 Building）时，我们可以进行简单的同步 HTTP 调用来检索用户偏好吗？我们可以将其视为反模式吗？

我们可以在共享程序集 (.net) 上定义那些“共享的东西”（c# 类）吗？或者是否有任何其他需要考虑的最佳实践？

谢谢，

Answer 1

微服务的全部意义在于它们是独立的。您可以创建具有国家/地区的服务（例如，以便您可以显示可用国家/地区的列表），但我会避免将该服务绑定到您的其他服务。将国家信息复制到其他服务中。这允许这些服务独立发展。例如，如果一个人的国籍比建筑国家更精细（因为这样的微妙之处确实发生在现实世界中）。

服务可以调用其他服务，更粗的业务服务应该调用更细粒度的服务，但不要做网络，确保你强烈定义你的层次结构，让高层次的服务调用低层次的服务。我不认为“建筑”或“人员”服务是那些粗粒度的服务，您可能想要在它们之上的一层将这些与偏好集成在一起。 Building 和 Person 可能应该是独立的，但微服务设计并不是一门精确的科学，很大程度上取决于您的情况。如果 User Preferences 深度集成到 Person 的行为中，那么将 Person 设置为粗粒度服务可能是有意义的。只需确保这是一个明确的决定，并且不要做一些可怕的事情，比如让他们相互依赖。

最后，不要创建“Shared Stuff”程序集。它会在很短的时间内成为你的巨石，并将所有东西捆绑在一起，变成一团乱麻。您最终会遇到单体应用的所有缺点，以及微服务的所有开销。