Helm 图表之间的依赖关系是否应该反映微服务之间的依赖关系？

给定以下服务方案及其依赖项，我想设计一组 Helm 图表。

• API Gateway calls Service A and Service C
• Service A calls Service B
• Service B calls Database
• Service C calls Service B and Service D

目前我看到两种选择：

1. Each of the 6 components in a diagram below is a single chart and each arrow in a diagram is a single dependency.
   

2. There's an Umbrella chart that has a dependency on all other charts. The Database chart is a dependency of Service B chart.
   

头盔文档建议使用选项 2。不过，由于本地开发和 CI/CD 管道的便利性，我更热衷于选项 1。

示例场景：开发人员正在重构Service C他想运行他更改的代码并对其进行测试。

• 选项 1. 开发人员安装Service C仅图表。
• Option 2: Developer would have to either:
  • 安装一个Umbrella由于运行不需要的服务（例如Service A or API Gateway，它不能很好地适应系统的复杂性；
  • install Service C, then Service B进而Service D，这也不能很好地适应系统的复杂性，因为它需要执行许多手动操作，并且还要求开发人员熟悉系统的架构，以便知道需要安装哪些图表。

我想就采取哪种替代方案做出明智的决定。我更热衷于选项 1，但是 Helm 文档以及我在互联网上找到的几个示例（link）也选择了选项 2，所以我想我可能会遗漏一些东西。

我建议每个服务使用一个图表，并进一步简化“服务 B”图表依赖于其数据库的操作。我将使这些图表独立：没有任何服务依赖于任何其他服务。

Helm 依赖关系发挥良好作用的地方是您拥有嵌入/隐藏特定单个其他部分的服务。例如，B 背后的数据库是一个实现细节，B 外部不需要了解它。所以B可以依赖stable/postgres或类似的东西，这在 Helm 中效果很好。

有一个特定的机械问题会导致伞图方法出现问题。假设服务 D 也依赖于数据库，并且它是相同“类型”的数据库（假设都使用 PostgreSQL）。从操作上来说，您希望这两个数据库是分开的。 Helm 将看到两条路径umbrella > B > database and umbrella > D > database，并且只安装数据库图表的一份副本，因此您最终将获得共享数据库的两个服务。你可能不想要这样。

使用 Helm 依赖项时您会遇到的另一个机械问题是，大多数资源都被命名为以下形式的某种变体：{{ .Release.Name }}-{{ .Chart.Name }}。在选项 1 中，假设您只安装服务 C；你最终会得到像这样的部署service-C-C, service-C-B, service-C-database。如果您想将服务 A 与它一起部署，那么它将引入它自己的service-A-B and service-A-database，这又不是你想要的。

我不知道有什么伟大的高级开源解决方案可以解决这个问题。基于 Make 的解决方案虽然很笨拙，但可以工作：

# -*- gnu-make -*-
all: api-proxy.deployed

%.deployed:
        helm upgrade --install --name $* -f values.yaml ./charts/$*
        touch $@

api-proxy.deployed: a.deployed c.deployed
a.deployed: b.deployed
c.deployed: b.deployed d.deployed