从单片到微服务

微服务永远不应该有公共数据库。我们应该避免同样的情况。

现在,第二种选择越来越接近微服务。但它有一个缺点,那就是共享用户数据库。理想情况下,用户数据库应由单独的服务(用户数据的主要真实来源)管理。

现在的问题是,其他服务将如何获取用户数据。有两种选择:- A.其他服务将调用用户服务以获取用户数据。 B.其他服务将保留用户数据的副本。每当用户服务中的用户数据发生任何变化时,它都会发布一个事件,所有其他服务都会更新并复制相同的事件。

现在的问题是,你们应该选择哪个选项。我更喜欢A选项(呼叫用户服务获取用户数据)。如果存在性能限制,并且使用缓存无法满足同样的要求,那么您应该选择选项B。

首先,你应该考虑你是否真的需要一个微服务架构,因为只有当微服务非常独立时,你才能从这种架构中获益,我的意思是,如果它们之间的连接很少。

这么说,第一种方法是完全不可取的,因为微服务架构的关键是微服务应该完全解耦,如果它们共享相同的数据库+模式+表,其中一个所需的更改将触发其余部分的更改,所以你将拥有一个分布式单体(两者都是最糟糕的)。

有两种可能的解决方案。 其中之一是每次需要用户信息时都会调用用户服务,但糟糕的是,每次需要这些信息时,你都必须拨打电话,因此你依赖于其他服务,延迟也会增加。

另一种解决方案是在需要此信息的其他服务上复制用户表(仅需要的部分),并使用消息异步更新它。例如,有一个kafka或其他消息队列,当用户表上有任何更新时,用户服务将在特定主题中发布一条消息,其他服务将订阅该消息,这样他们就可以相应地更新他们的用户信息。

这里的问题是最终的一致性,我的意思是,其他服务不会立即看到更新。

正如你所看到的,这两个选项都有一些缺点,都是因为服务之间的通信,所以它们之间的通信越少,对微服务架构来说就越好