水平扩展微服务的实例是否应该共享数据库? [英] Should instances of a horizontally scaled microservice share DB?

问题描述

鉴于拥有关系数据库并且需要水平扩展的微服务，我看到了两种配置数据库服务器的方法:

Given a microservice that owns a relational database and needs to scale horizontally, I see two approaches to provisioning of the database server:

• 为服务的每个实例提供自己的数据库服务器实例，并具有耦合的流程生命周期

OR

• 让实例连接到共享的(由同一服务的相同实例)独立的数据库服务器或群集

使用事件驱动的体系结构和前一种方法，微服务的每个实例将需要处理每个事件并采取适当的措施来改变其自身的隔离状态.这似乎效率低下.

With an event driven architecture and the former approach, each instance of the microservice would need to process each event and take the appropriate action to mutate its own isolated state. This seems inefficient.

采用后一种方法，只需一个实例即可处理事件以达到相同的效果，但只是共享状态的突变.必须确保每个事件仅由给定微服务的一个实例处理(这是微不足道的吗?)，以避免冲突.

Taking the latter approach, only one instance has to process the event to achieve the same effect but as a mutation of the shared state. One must ensure each event is processed by only one instance of the given microservice (is this trivial?) to avoid conflict.

这里是否对首选方法达成共识?您的经验中学到了什么?

Is there consensus on preferred approach here? What lessons has your experience taught you on this?

推荐答案

我会采用第一种方法，即服务本地数据库.每个实例都有其自己的数据库实例.这样就可以在服务版本之间更改持久层. 否则，更改ER模型将导致冲突.您还可以通过这种方法轻松地转换为NoSQL解决方案.

I would go with the first approach, a service local DB. Each instance has its own DB instance. This enables to change the persistence layer between versions of the service. Changing the ER model otherwise would lead to conflicts. You would also be able to change to a NoSQL solution with this approach easily.

有了事件驱动的设计，我可以推荐这本书:

With the event driven design, I can recommend this book: Designing Event Driven Systems

如我所见，服务接收到导致事件的请求.该事件由服务的其他实例占用，因此不需要再次处理请求，但结果必须复制到实例状态.

As I see it, a service receives an request that leads to an Event. This Event is consumed by the other instances of the service, therefore the request doesn't need to be processed again, but the result has to be copied to the instances state.

这篇关于水平扩展微服务的实例是否应该共享数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！