如果微服务架构需要每个微服务单独的数据库，那么它的成本太高且难以管理。为什么我们甚至需要它？

我读到有关微服务的信息，对于每个服务创建一个单独的DB来实现隔离似乎不合逻辑。我可以仅使用Web服务和单个数据库来实现相同的目的。为什么我们甚至需要它？分开数据库的东西是无聊的。还是我明明是错？你能指导我吗？

为什么我们甚至需要它？

你不知道

为每个服务创建一个单独的数据库有助于加强域边界，但这只是一种方法。没有什么可以阻止您让所有服务共享同一数据库。

只要您的服务行为正常且不对其他服务拥有的数据做意外的事情，就可以了。

我不知道您读了什么，但是您应该知道，关于微服务架构有很多不同的见解。这是有关该主题的一篇不错的博客文章。

我已经看到人们在某种程度上简单地提到了这个想法，因为“每个微服务都应该拥有并控制自己的数据库，而没有两个服务应该共享一个数据库。” 这个想法很合理：不要跨服务共享单个数据库，因为那样会遇到诸如竞争的读/写模式，数据模型冲突，协调挑战等冲突。

但是，一个数据库确实为我们提供了许多安全性和便利性：ACID事务，一个单一的外观，一个易于理解的（有点？），一个管理的地方等。

通往微服务的旅程就是这样：一段旅程。每个公司都会有所不同。没有硬性规定，只有权衡取舍。

微服务最难的部分：您的数据

正如丹·威尔逊（Dan Wilson）回答的那样，您实际上并不需要它。微服务是新的热点，就像所有新的热点一样，人们在很多地方都使用它们，即使它们提供的价值不高。

微服务使您可以在“微”级别上独立部署和扩展事物。这种粒度提供了很多技术优势，甚至还提供了非技术优势，因为它使您可以更好地分离开发团队，按需发布而不是一个大版本，孤立地尝试新技术或流程，等等。很多是因为对数据库的依赖。如果您不担心其他服务的数据就无法部署服务，那您就迷路了。

分开数据库的东西是无聊的。还是我明明是错？

就是说，你也是错误的。

当您在云中工作时，数据库很便宜。通常免费！当然，服务器要花钱，但我们并不是在谈论每个微服务的单个服务器（至少不是一开始）。只要您努力避免跨数据库查询（这会引入有害于“可独立部署和扩展”的依赖项），那么具有一堆（逻辑）数据库的单个服务器就可以了。在某些云数据库服务（如Azure SQL）中，无法进行跨数据库查询。您甚至不需要在那里勤奋工作...

我什至看到微服务可以共享数据库，但是每个服务都有自己的架构。同样，您需要勤奋地避免跨越数据边界的查询。

很多地方都不那么勤奋。他们有入门级开发人员，或者不重视微服务方法的人，或者团队领导不力，或者时间表压力很大，导致人们选择捷径。

拥有独立的数据库是实施允许服务独立的解耦的最干净方法，但这并不是唯一的方法。而且它并不那么昂贵-特别是当您将其与试图在共享数据库中强制执行数据边界所花费的时间/薪水进行比较时。

为什么我们甚至需要它？

微服务（更广泛地说是SOA）的巨大好处是内部的高度抽象—不仅是实现，而且还包括所使用的技术。例如，如果一个系统由五个团队以五个微服务的形式开发，那么一个团队可以决定迁移到完全不同的技术堆栈（例如从Microsoft堆栈到LAMP），而无需征询其他团队的意见。

查看Amazon AWS或Twilio。您知道他们的服务是用Java还是Ruby实现的吗？他们使用Oracle还是PostgreSQL或Cassandra或MongoDB？他们使用多少台机器？你甚至在乎吗？换句话说，这些技术选择是否会影响您使用这些服务的方式？...更重要的是，如果将它们转移到其他数据库，您是否需要相应地更改客户端应用程序？

现在，如果两个服务使用相同的数据库怎么办？以下是可能出现的问题的一小部分：

• 开发服务1的团队希望从SQL Server 2012迁移到SQL Server2016。但是，开发团队2依赖于SQL Server 2016中已删除的不赞成使用的功能。

• 服务1是巨大的成功。在两台机器（主服务器和故障转移）上托管数据库已不再是一种选择。但是将群集扩展到多台计算机需要分片之类的策略。同时，第2小组对目前的规模感到满意，并且没有理由搬到其他任何地方。

• 服务1应该移至UTF-8作为其默认编码。但是，服务2很高兴使用代码页1252 Windows Latin 1。

• 服务1决定添加具有特定名称的用户。但是，该用户已经存在，是几个月前由第二小组创建的。

• 服务1需要很多不同的功能。服务2是一个非常关键的组件，需要将数据库功能保持在最低限度，以降低遭受攻击的风险。

• 服务1需要15 TB磁盘空间；速度并不重要，因此普通硬盘就可以了。服务2最多需要50 GB，但需要尽可能快地访问它，这意味着数据应存储在SSD上。

• ...

每一个小小的选择都会影响到每个人。每个团队的人员都需要共同做出每个决定。必须做出妥协。将此与完全自由在SOA上下文中执行任何操作相比较。

它太难以管理了。

那你做错了。我想您是在手动部署。

这不是应该做的事情。您需要自动化运行数据库的虚拟机（或Docker容器）的部署。一旦使它们自动化，部署两个服务器或二十个服务器或两千个服务器就没有太大的不同。

隔离数据库的神奇之处在于它是非常易于管理的。您是否尝试过管理由数十个团队使用的庞大数据库？这是一场噩梦。每个团队都有特定的要求，一旦您触摸某些内容，它就会影响某人。将数据库与应用程序配对后，范围变得非常狭窄，这意味着要考虑的事情要少得多。

如果庞大的数据库需要专业的系统管理员，则基本上只有一个团队使用的数据库才能由该团队管理（DevOps 也是如此），从而节省了系统管理员的时间。

太贵了

定义成本。

许可费用取决于数据库。在云计算时代，我可以肯定的是，所有主要参与者都重新设计了许可，以适应这样的环境：在这里，除了一个庞大的数据库之外，还有许多小型数据库。如果没有，您可以考虑移至其他数据库。顺便说一下，有很多开源的。

如果您在谈论处理能力，那么虚拟机和容器都对CPU友好，并且我不能肯定一个大型数据库将比许多做相同工作的小型数据库消耗更少的CPU。

如果您的问题是内存，那么虚拟机不是您的最佳选择。容器是。您将知道它们不会消耗比所需更多的RAM，就可以跨任意多个节点。尽管与一个大型数据库相比，许多小型数据库的总内存消耗将更高，但我认为两者之间的差异不会太重要。YMMV。

取决于您认为“昂贵”的东西。

数据库不一定必须是昂贵的商业数据库服务器（例如Oracle），也不一定一定是资源匮乏的事务。根据您的要求，您可以使用SQLite数据库甚至文件系统作为持久数据存储。

所有这些服务还可以共享一个数据库实例/服务器，并且每个服务仅具有独立的架构。

这里的关键论点是服务需要拥有和控制其数据。如何实现这一点，取决于选择和技术细节。

服务拥有和控制其数据的最佳方式是拥有自己的“个人”数据库​​。这样就可以完全自由地选择技术和数据方案。任何其他服务都可以访问服务拥有的数据的唯一方法是从服务中索取数据。这样，如果需要更改内部数据表示形式，则可以轻松更改它，并且其他任何服务都不会中断。

因此，回顾一下。每个服务都有一个数据库不一定很昂贵，也没有必要。这只是在开发微服务时需要做出的一个决定。每个选择都有其含义和局限性。研究那些并做出自己的选择。