微服务：在有界的上下文之间共享模型

Question

我目前正在构建一个基于微服务的应用程序，这个应用程序是用平均堆栈开发的，我遇到了几种需要在有界上下文之间共享模型的情况。

作为一个例子，我有一个用户服务来处理注册过程以及登录（生成jwt），注销等。我还有一个文件服务，用于处理用户发生的配置文件图片和其他图像的上传上传。另外，我有一个跟踪会员之间关系的朋友服务。

目前，我将用户的guid从用户服务使用的用户表以及第一个，中间和最后一个名称字段添加到File表和Friend表中。通过这种方式，无论何时在其他服务（朋友和文件）中需要这些字段时，都可以查询这些字段，而无需在每次查询时都进行任何休息调用以获取信息。

这里是警告：

缺点似乎是，我必须这样做，我选择了与塞涅卡RabbitMQ的，通知文件和朋友表只要用户更新从用户表的信息。

1）我应该担心服务变得过于健谈吗？

2）这是否会导致任何性能问题，如果很多更新发生一个多小时，假设？ 3）在试图隔离边界时，我只是没有看到另一种解决方法。什么是解决这个问题的建议方法，我在正确的轨道上？

Answer 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

许多常见的问题似乎在很大程度上是围绕一个领域模型的分解，以及如何克服了诸如查询之类的要求抵制分解的情况。这篇文章清楚地说明了选项。绝对值得花时间阅读。

在您的具体情况下，这意味着文件和朋友服务只需要存储用户的主键。但是，所有服务都应该发布状态更改，然后可以将其集中到一个读取模型中。

Answer 2

如果你对一个高容量的邮件和高TPS例如100000 TPS生产和消费活动的担心，我建议除了使用RabbitMQ的使用Apache 卡夫卡或NATS的（去的版本，因为NATS有几度夕阳红版本也是），以支持每秒大量的消息。

另外关于数据库设计，您应该根据领域驱动设计（DDD）设计每个微服务基础的业务能力和有界上下文。因为不同于SOA，建议每个微服务都应该有自己的数据库，那么你不应该担心规范化，因为你可能必须重复每个微服务的许多结构，字段，表和功能，以使它们与每个微服务分离其他并让他们独立工作以提高可用性并具有可扩展性。

您也可以使用事件采购+ CQRS技术或事务日志尾矿规避2PC（2阶段提交） - 为了您的微服务之间的交流活动 - 实现微服务时，不建议并根据CAP定理操纵状态以具有最终一致性。