微服务架构中的数据库位置

时间:2017-04-13 05:57:03

标签: azure docker microservices

我们有一个单一的应用程序,我们现在正在使用容器转换为微服务架构。

我们的微服务是有状态的(即他们需要从db插入/检索数据)。根据微服务架构,每个微服务应该有自己的数据(在我们的例子中是数据库)。

我的问题是 where 应该部署每个微服务的数据库,是否应该在部署微服务的同一主机中,在部署微服务的同一容器中或它应该在像azure db这样的单独服务器中吗?

什么是专业人士和专业人士每种方法的缺点以及根据微服务最佳实践的最佳方法是什么? *

3 个答案:

答案 0 :(得分:5)

你是对的,每个微服务都应该使用自己最适合其需求的数据存储。可能有一项服务需要将其数据存储在blob存储中,另一种服务可能将其数据存储在表存储或DocumentDb或SQL数据库中。

您可能希望使用 Database-as-a-Service ,因此托管您自己的数据库,因为您不必担心可用性,扩展,备份。 ..

答案 1 :(得分:5)

Martin的答案很好,但我想补充一点,因为您使用的是容器化的应用程序,您应该明确从服务容器中单独部署数据库。原因是您的服务可以(独立地)发展,无状态服务容器的最大好处之一是,如果您拥有它们的集群,您可以使用滚动更新来更新它们,而不会对您的应用程序可用性产生任何影响。状态数据库服务的更新更加困难,但预计也不会那么频繁(并且cockroachdb等新技术即将出现)。 Good read

答案 2 :(得分:1)

我并不重要 where ,除非它不能与您的应用程序位于同一个容器中,如本主题前面所述。

重要的是,只有一(1)微服务具有所有权的数据。如果不止一个微服务需要访问数据,他们必须通过拥有该数据的微服务提供的API访问它。

你可以这样构建它:

" Sql Microservice" - 处理进出SQL Server的所有流量。所有需要来自Sql数据的微服务都与这些人交谈。您将拥有与TableStorage类似的微服务。

如果"微服务A"使用Sql / TableStorage中的数据存储区,并且该数据存储区是微服务A的本地数据库,我将创建2个微服务。

微服务A1将是您的代码运行的地方 微服务A2具有将数据库操作公开给A1的API。 当A1需要数据时,他会谈到A2。

此外,此模式允许您独立于应用程序节点扩展数据层,还可确保数据拥有一(1)个微服务那就是关键。