假设我想创建一个允许管理用户帐户的博客平台，因此我想出了2个微服务：
博客-管理帖子、标签等用户-管理用户、他们的角色等我很清楚，Post包含作者的ID（User），User包含他写的Posts的ID。
问题是，当客户端请求Post时，我还想返回作者的姓名，并以DTO（视图模型）的形式将其一起发送给客户端。我看到了两种可能的解决方案：
博客服务的域中引入User（只有ID和名称）的概念。每次客户端请求Post时，所有相关数据都只从该微服务中获取。每次在用户微服务中修改用户名时，该服务都会收到通知并更新作者的姓名。Post时，都会调用Blogs微服务获取Post，然后调用用户微服务根据ID获取作者的姓名。到目前为止，我倾向于解决方案#1，因为当请求Post时，它只需要对1个微服务进行一次调用，但是假设函数（微服务）的数量开始增长，并且我不断从每个函数中添加小概念只是为了限制调用的数量，我担心我最终会变成意大利面条博客微服务…但是我也不认为微服务的数量会显著增长；）
你觉得哪种方法更好，为什么？这些方法是否违反了微服务架构原则，我的担忧是合理的？
这真的取决于您的程序将如何开发。
在这里，您为了性能而编辑模型。大多数时候，我不认为为了性能而更改模型本身是正确的方法。如果您认为博客上下文中的User的概念不正确，则不应该将其放在那里。另一个问题是，您必须处理有界上下文（BC）之间的最终一致性。如果您认为博客中的User的概念不是一个坏主意，那么它可能是正确的选择。
虽然这可能对性能不友好，但我认为这将是开始时最简单的方法。您不必处理最终一致性（处理BC之间的数据同步），也不必更改模型。但是如果您真的关心性能并保持模型干净，您可能会对读取模型感兴趣。
读取模型的概念是关于至少有两个独立的模型：一个用于读取数据，另一个用于写入/编辑数据。如果我们想为您的问题实现这个概念，我们将为博客创建一个读取模型BC其中帖子和用户可以合并在一起（类似于解决方案#1），然后查询。我们可以借助事件同步这些数据，因此当帖子或用户更改时，它将引发一个事件并将更改的数据保存到您的读取模型中。这样您就可以合并/更改任何您想要的数据以获得更好的性能。它可能与解决方案#1非常相似，但主要区别在于您不编辑主模型。您创建新模型只是为了读取。这可能是最难的解决方案，但如果您的项目很大且性能很重，这可能是一种方法。
我不会说任何解决方案对解决你的问题是最好的或最坏的。这总是取决于背景。
