如何将社交网络的消息部分(帖子、回复、私有)的微服务模块分离开来？

Question

我使用微服务设计了社交网络系统的不同部分，并达到了系统的信息部分。消息可以是私有消息(可能是单独的模块)，每个用户在墙上的帖子可以是图像、文本、视频(也可能是另一个模块)，回复消息也可以是不同的模块。

现在我的问题是，我是否应该为每种消息设计单独的模块(服务)。我是否应该考虑将消息加载作为分离模块的概念的一部分？

从一个角度来看，它们都是用户用来与系统中的其他用户交互的消息。

我应该如何为这个社交网络的消息部分设计微服务？

编辑-1:目前我的项目的微服务模块：

• 用户
• 鉴定人
• 通知(电子邮件、推送等)

现在，我的社交网络项目有三个部分用于消息：

• 用户的帖子
• 用户的私人消息
• 用户对其他消息的回复

这三个类别可以是一个模块，可以管理所有这些逻辑。或3个不同的模块user posts、user private messages、user replies。

问题是我该如何把它们分开？我担心的是，每个类别都会有更多的逻辑，这将导致模块臃肿。

我的最后一个问题是:仅仅是微服务的作用将一个模块和另一个模块分开，还是应该考虑到模块的复杂性？

注意:我所说的短信不是指微服务模块的内部通信，而是指生态系统中用户的消息.

Answer 1

在我看来，您可以设计微服务，就像应用程序中的类一样。也就是说，您正在寻找服务中的最大内聚力。换句话说，一个微服务中的所有东西都应该一起工作，以实现一个明确的职责，而任何其他的微服务都不应该有相同的责任的任何内容。

此外，您希望最小化耦合。也就是说，主要而言，每个微服务都应该有一个很好定义的接口，并且应该很容易在总体方案中被替换。这也意味着使用依赖注入之类的概念。

因此，只要你有这两个方面的控制-内聚力和耦合-你是好的。关注点的精确分离(更粗或更细粒度)并不那么重要，而且可能在不同的应用程序之间有所不同。

这里有一些明显的问题--例如，将“日志”和" GUI“放在同一个组件中是没有意义的(问自己这样的问题：”除了GUI之外，还有什么东西可以使用日志记录吗？“或者“GUI需要知道日志是如何实现的吗？”或者“GUI是否需要由进行日志记录的同一个团队实现？”等等)。另一个常见的例子是处理数据导入--这是否仅仅因为用户通常通过GUI上传他们的Excel文件就属于GUI服务？显然不是--您可能希望通过REST上传Excel，或者在批处理作业中从另一台服务器中提取Excel，等等。

因此，在您的示例中，您最好坐下来为每个组件定义责任。确保尽可能少的重叠。这通常会导致您认为不同的组件的合并；或者导致具有定义良好边界的组件的拆分。