我目前正在构建一个使用平均堆栈开发的基于微服务的应用程序，并且遇到了我需要在有界上下文之间共享模型的几种情况。
作为一个例子，我有一个用户服务，处理注册过程以及登录（生成jwt），注销等。我还有一个文件服务，处理用户碰巧上传的个人资料照片和其他图像上传。此外，我有一个Friends服务，可以跟踪成员之间的关联。
目前，我正在将User用户使用的用户表中的用户guid以及第一个，中间名和姓名字段添加到File表和Friend表中。这样我可以在其他服务（朋友和文件）中随时查询这些字段，而无需每次查询时都进行任何休息调用以获取信息。
以下是警告：
缺点似乎是我必须使用rabbitmq选择seneca，每当用户从User表更新其信息时，都会通知File和Friend表。
1）我应该担心服务过于健谈吗？
2）这会导致任何性能问题，如果一小时内发生了很多更新，那么就说吧？
3）在试图隔离边界时，我只是没有看到另一种方法来解决这个问题。解决这个问题的推荐方法是什么，我是否走上正轨？
答案 0 :(得分：1)
这是一种权衡。我个人不会将用户详细信息与用户标识符一起存储在依赖服务中。但我也不会查询用户服务来获取此信息。您可能需要的是整个系统的某种读取模型，它可以按照您的特定需求（报告，在网页上一起显示等）的方式存储这些数据。
读取模型是在事件驱动的体系结构空间中流行的模式。有一篇非常好的文章讨论了这些问题（分为两部分）：
https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-2-richardson
关于微服务的许多常见问题似乎主要围绕域模型的分解，以及如何克服查询等要求抵制分解的情况。本文清楚地说明了各种选择。绝对值得花时间阅读。
在您的特定情况下，这意味着文件和朋友服务只需要为用户存储主键。但是，所有服务都应发布状态更改，然后可以将其聚合到读取模型中。
答案 1 :(得分：0)
如果您担心大量消息和高TPS（例如100,000 TPS）用于生成和消费事件，我建议不要使用RabbitMQ而是使用apache Kafka 或 NATS （转到版本，因为NATS也有Rubby版本），以便每秒支持大量的消息。
另外，关于数据库设计，您应该根据域驱动设计（DDD）设计每个微服务基础业务功能和有界上下文。所以，因为与SOA不同，建议每个微服务都应该有自己的数据库，然后你不应该担心规范化，因为你可能不得不为每个微服务重复许多结构，字段，表和特性，以便它们与每个微服务分离。其他并让他们独立工作以提高可用性并具有可扩展性。
您也可以使用事件采购+ CQRS 技术或交易记录拖尾来规避 2PC （2阶段承诺） - 在实施微服务时不建议 - 为了在微服务之间交换事件并根据 CAP 定理操纵状态以获得最终一致性。