它被认为是最好的方法,一个微服务数据库是私有的,而共享任何东西的方法是最好的。
最近我遇到了一个基于云的系统,它使用postgres、mongodb & elasticsearch。遵循每个服务DB,只要每个服务运行自己的存储引擎集群,该集群只承载一个数据库。
例如,服务A和服务B使用弹性搜索(ES),各有3个索引。它们有自己的ES集群,其中托管了3个索引。使用mongodb或postgres的其他服务也是如此,其中1-2集合托管在单个mongo集群上,或7-8表由一个postgres集群管理。
我对他们遵循设计的方式感到困惑。据我理解,单独的数据库并不意味着单独的数据库引擎实例。任何现代数据库引擎都可以很容易地托管多个数据库。服务拥有数据库,但不拥有DB引擎实例。这不仅造成了维护的噩梦,而且每个数据库引擎的利用率都严重不足。我的理解是正确的还是我有错误的理解?
发布于 2022-07-20 11:50:45
它总是取决于你想要实现什么。
例如,如果由于某种原因,需要重新启动db才能重新配置/部署新版本的服务,则会影响其他团队的服务。如果您不想这样做,您可能需要一个完全不同的集群。
如果您希望对一个服务的DB进行与其他服务完全不同的扩展,您也可能希望拥有您的DB集群。
如果您对这些都不感兴趣,那么共享DB集群可能会更简单。同样,只有在共享不与您想要的其他内容冲突的情况下,这才有效。
发布于 2022-07-20 19:02:00
微服务体系结构旨在确保可扩展的、松散耦合的、独立部署的服务。每个服务模式的数据库为实现这一目标做出了贡献,它将数据私有于服务,并避免了由于数据库模式中的相互依赖而导致的隐藏耦合。
您可以在同一个存储引擎上对私有数据库进行策略分组,只要所使用的技术保持每个数据库的独立性。这可以确保您可以在需要时将一个基移动到一个单独的引擎,例如,一个微服务需要一个不同版本的引擎,或者是为了可伸缩性目的。
但是,如果您使用任何与分布式数据库相关的机制,如数据库碎片或mongoDB团簇,而不将数据库分开,则每个服务的数据隐私将不再得到保证:从技术上讲,是同一数据库被分布(碎片)或复制(集群)。您可能迟早会受到数据库每个服务模式所要避免的那种隐藏依赖(例如,一个服务意外地直接访问另一个服务的数据或数据库方案共享一些公共元素)。
发布于 2022-07-22 07:54:55
我认为,从不需要严格的数据隔离的情况开始,您可以采取一种策略,在同一个数据库中托管服务表,然后在系统增长时调用。
https://softwareengineering.stackexchange.com/questions/439919
复制相似问题