我们正在走微服务路线尝试打破巨石。 以前我们有一个数据库被多个应用程序击中。这些应用程序获得了他们需要访问的特定表的授权。
使用微服务架构，我们计划在服务中包含特定域，并且该服务具有自己的数据库。
我们使用自托管Windows服务来支持微服务。他们都在SQL服务器上寻求持久性。我们计划使用集成的安全性来对服务进行数据库身份验证。
这是问题开始的时刻。为了验证服务并确保数据库未被任何其他服务使用，我们计划为每个应用程序提供一个服务帐户。现在，对于一些微服务，这些帐户的管理（频繁的基于策略的密码更改）是可以的。一旦服务数量超出人工可管理规模，我们担心帐户管理（每个服务1个帐户）将开始变得痛苦。
目前整个行业如何做到这一点。我们可以为此目的使用任何工具吗？
答案 0 :(得分：0)
作为从持续集成/持续部署服务器（CI / CD服务器）自动部署服务的一部分，我将通过将正确的用户/凭证部署到数据库来解决此问题。您可以将用户凭据存储为CI / CD服务器中的secrets。此外，群集基础结构系统（例如kubernetes）也允许您store secrets。
例如，如果使用Jenkins进行部署，则在部署任务中包含一个操作，以便在部署/更新数据库和架构时创建/更新所需的用户/凭据。
另外一个重要的一般性说明 - 如果您担心服务数量很多，这表明您可能正在计划过于细粒度的服务。服务范围的一般动机是允许专用two pizza max team能够拥有单个服务及其完整的生命周期。你想要一个开发人员服务至少1到1的比例。如果你让每个开发人员负责许多微小的服务，我不会认为你将从微服务架构风格中受益匪浅。
这里引用了Martin Fowler site（这是一个非常推荐的读取顺便说一句）：
微服务有多大？
虽然“微服务”已经成为一个流行的名称 建筑风格，它的名字确实导致了一个不幸的焦点 服务规模，以及关于什么构成“微观”的争论。在我们的 与微服务从业者的对话，我们看到了一系列的规模 服务。报道的最大尺寸遵循亚马逊的概念 两个比萨队（即整个队可以由两个比萨饼喂养），意思是 不超过十几个人。我们已经看到了规模较小的规模 设置一个半打的团队将支持半打 服务。
这导致了是否存在足够大的问题 这个尺寸范围内的差异是每人服务的范围 并且每人的服务规模不应该集中在一个 微服务标签。目前我们认为将它们分组比较好 在一起，但我们当然可能会像我们一样改变主意 进一步探索这种风格。