2

I am currently building a microservices-based application developed with the mean stack and am running into several situations where I need to share models between bounded contexts.

As an example, I have a User service that handles the registration process as well as login(generate jwt), logout, etc. I also have an File service which handles the uploading of profile pics and other images the user happens to upload. Additionally, I have an Friends service that keeps track of the associations between members.

Currently, I am adding the guid of the user from the user table used by the User service as well as the first, middle and last name fields to the File table and the Friend table. This way I can query for these fields whenever I need them in the other services(Friend and File) without needing to make any rest calls to get the information every time it is queried.

Here is the caveat:

The downside seems to be that I have to, I chose seneca with rabbitmq, notify the File and Friend tables whenever a user updates their information from the User table.

1) Should I be worried about the services getting too chatty?

2) Could this lead to any performance issues, if alot of updates take place over an hour, let's say?

3) in trying to isolate boundaries, I just am not seeing another way of pulling this off. What is the recommended approach to solving this issue and am I on the right track?

4

2 回答 2

2

这是一个权衡。我个人不会将用户详细信息与用户标识符一起存储在依赖服务中。但我也不会查询用户服务来获取这些信息。您可能需要的是某种用于整个系统的读取模型，它可以以针对您的特定需求（报告、在网页上一起显示等）进行优化的方式存储这些数据。

读取模型是一种在事件驱动架构领域流行的模式。有一篇非常好的文章讨论了这类问题（分为两部分）：

https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-1-richardson https://www.infoq.com/articles/microservices-aggregates-events-cqrs-part-2-richardson

许多关于微服务的常见问题似乎主要围绕领域模型的分解，以及如何克服诸如查询等需求抵抗这种分解的情况。这篇文章清楚地说明了这些选项。绝对值得花时间阅读。

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

于 2017-06-02T10:34:12.757 回答
0

如果您担心大量消息和高 TPS，例如 100,000 TPS 用于生产和消费事件，我建议不要使用 RabbitMQ 使用 apache Kafka或NATS（Go 版本，因为 NATS 也有 Ruby 版本）以支持高每秒的消息量。

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

您还可以使用事件溯源 + CQRS技术或事务日志拖尾来规避2PC（2 阶段承诺）——在实现微服务时不建议这样做——以便根据CAP定理在微服务之间交换事件并操纵状态以具有最终一致性。

于 2017-06-03T21:01:11.567 回答