有点主观的问题，但这是我们的设置。希望这能帮助你立案。我相信有人会有不同的意见，这也同样有效：
我们部署了大约70个微服务，每个微服务都有自己的数据库（“schema”）和自己的jdbc url（通过服务定义）。每个微服务都有自己的端点和凭证，我们不在微服务之间共享。因此，实际上，就模式而言，我们保持了整个微服务的设计完全独立。
然而，在部署方面，我们选择使用单个数据库示例来承载所有数据库（或“模式”）。虽然从技术上讲，我们可以将每个数据库部署在自己的数据库示例上，但我们选择不这样做的主要原因如下：
开销：为每个微服务运行单独的数据库示例会增加很多“固定”开销。如果您只是将数据库作为mysql docker容器启动（我们使用单独的数据库服务，如rds或googlecloudsql），那么这可能与您没有直接关系。但是，即使在mysql作为docker容器的情况下，如果您运行70个单独的容器，例如每个microservice运行一个容器，您也可能会有一个不小的开销。
管理开销：考虑到数据库通常非常复杂（磁盘空间、IIOP、备份/归档、清除、升级和其他管理活动），拥有单独的数据库示例（或docker容器示例）可能会给您的管理或操作团队带来重大损失，尤其是如果你有大量的微服务
安全性：当涉及到安全性时，数据库通常也是至关重要的，因为“真相”通常出现在数据库中。将加密、tls配置和凭据的优势放在一边（因为无论您的部署模式如何，它们都应该是最重要的），如果您的数据库示例太多，那么安全考虑、审查、审核和日志记录将带来重大挑战。
易开发性：在总体规划中相对不那么重要，但仍然很重要。除非您考虑提出一个不同的开发模型（从而打破“dev-prod奇偶校验”），否则您的开发人员可能很难找到用于调试的数据库端点，即使他们偶尔只需要这些信息。
因此，我的建议是使用单个数据库示例（docker或其他），但保持数据库/模式完全独立，并且除了“所有者”微服务之外，任何微服务都无法访问。
如果您将mysql部署为docker容器，请使用 StatefulSet 为了坚持。定义外部 pvc 因此，无论pod甚至集群发生什么情况，都可以始终保留数据。当然，如果您运行“active-active”，您将需要确保节点之间的集群，但是我们确实在“active-passive”模式下运行它，因此我们保留 replica 假设我们只在测试环境中使用mysql docker容器，以节省不需要的外部dbaas服务的成本。