我们正在基于现有的巨大单调应用程序设计一种新的微服务架构。
我们阅读了很多有关如何设计微服务以及它们如何进行通信的信息，但是我找不到有关此“问题”的任何信息：
让我们说，我们有两个微服务正确地绑定了“建筑”管理，另一个微服务管理了“ Person”；
但是，现在我们还有另一个微服务也必须用于管理“ ReferenceData”（如国家/地区，州/省）和另一个微服务来管理“用户偏好”。
我们如何管理一个人“包含”一个国家（代表国籍）和一栋建筑物也包含一个国家（代表其地址）？
当用户调用业务微服务之一（人员或建筑物）时，我们可以执行简单的同步HTTP调用来检索用户首选项吗？我们可以将其视为反模式吗？
我们可以在共享程序集（.net）上放置这些“共享的东西”（c＃类）的定义吗？还是需要考虑其他最佳做法？
谢谢
答案 0 :(得分：0)
微服务的全部要点是它们是独立的。您可以创建具有国家/地区的服务（例如，以便可以显示可用国家/地区的列表），但是我会避免将该服务与您的其他国家/地区绑定。将国家/地区信息复制到其他服务中。这使这些服务可以独立发展。例如，如果某个人的国籍模式比建筑国家的国籍更好（因为这种微妙之处确实发生在现实世界中）。
服务可以调用其他服务，较粗的业务服务应调用更细粒度的服务，但不要建立网络，请确保强烈定义层次结构，并使高级服务称为低级服务。我认为“ Building”或“ Person”服务不是那些粗粒度的服务，您可能需要在它们之上的一层将那些具有首选项的服务集成在一起。 Building和Person 可能应该是自己的，但是微服务设计并不是一门精确的科学，很大程度上取决于您的情况。如果“用户首选项”已深入集成到Person的行为中，则可以使Person成为您的粗粒度服务。只需确保这是一个明确的决定，就不要做让他们相互依存的可怕事情。
最后，不要创建“共享的东西”程序集。它会在很短的时间内变成您的Monolith，并将所有内容捆绑在一起，成为一个难以控制的混乱。最后，您将面临整体式的所有弊端以及微服务的所有开销。