我们将采用微服务路线来尝试打破单体应用。 以前，我们只有一个数据库，它受到多个应用程序的影响。应用程序被授予他们需要访问的特定表。
通过微服务架构，我们计划在服务中包含特定域，并且该服务有自己的数据库。
我们使用自托管 Windows 服务来支持微服务。他们都使用 SQL Server 进行持久化。我们计划使用集成的服务安全性来对数据库进行身份验证。
这是问题开始的地方。为了对服务进行身份验证并确保数据库没有被任何其他服务使用，我们计划为每个应用程序设置一个服务帐户。现在，对于少数微服务，这些帐户的管理（基于策略的频繁密码更改）是可以的。一旦服务数量超过手动管理的规模，我们担心帐户管理（每个服务 1 个帐户）将开始变得痛苦。
整个行业目前如何做到这一点。有没有我们可以为此目的使用的工具？
【问题讨论】：
标签： sql-server microservices self-hosting
我将通过将正确的用户/凭据部署到数据库来解决此问题，作为从持续集成/持续部署服务器（CI/CD 服务器）自动部署服务的一部分。您可以将用户凭据作为secrets 存储在 CI/CD 服务器中。此外，集群基础架构系统（例如 kubernetes）也允许您使用 store secrets。
例如，如果您使用 Jenkins 进行部署，您将在部署任务中包含一个操作，以在部署/更新数据库和架构时创建/更新所需的用户/凭据。
还有一个重要的一般注意事项 - 如果您担心服务数量过多，这表明您可能正在计划过于精细的服务。服务范围的一般动机是允许专用的two pizza team 拥有单个服务及其完整的生命周期。您希望每个服务的开发人员比例至少为 1 : 1。如果您让每个开发人员负责许多小型服务，我认为您不会从微服务架构风格中受益匪浅。
这是来自Martin Fowler site 的引用（顺便说一句，非常推荐阅读）：
微服务有多大？
虽然“微服务”已经成为这个流行的名称 建筑风格，它的名字确实导致不幸地关注 服务的规模，以及关于什么是“微”的争论。在我们的 与微服务从业者的对话，我们看到了一系列规模 的服务。报告的最大尺寸遵循亚马逊的概念 两个披萨团队（即整个团队可以吃两个披萨），意思是 不超过十几个人。在我们看到的更小的规模上 六个人的团队将支持六个人的设置 服务。
这就引出了是否有足够大的问题 在这个规模范围内的差异，每打人的服务 并且每人服务的规模不应归为一 微服务标签。目前我们认为最好将它们分组 在一起，但我们肯定会改变主意，因为我们 进一步探索这种风格。
【讨论】：