多租户架构中共享微服务的设计
Design of shared microservices in an Multi-Tenant architecture
在我们的组织中，我们有一个软件系统，由多个微服务提供支持，即：-
- 聚合器 MS.
- 客户女士
- 文档女士
上述每个微服务都有一个 master 分支，其中有最新的代码库。
现在，有多个垂直行业正在积极开发和贡献上述微服务。一些垂直行业（独立的开发人员组）例如：-
- 垂直-A
- 垂直-B
- 垂直-C
在上述微服务中，每个垂直领域都有预定义的策略（他们在其中进行开发）和一些通用代码。
此外，每个垂直领域都有基础架构级别的隔离，这意味着每个垂直领域有 3 个独立的集群设置。
Post 他们各自的部署，每个垂直将他们的代码合并到各自的 master 分支。现在，如果另一个垂直领域必须进行他们的开发，他们必须将他们的 feature/local 分支重新设置为 master 然后继续。
现在的问题是：-
每当 Say Vertical-A 在三个微服务中的任何一个中引入一些更改时，他们都需要从剩余的垂直领域（即 Vertical-B 和 Vertical-C）获得签核。从另一种意义上说，我们在一个垂直领域对其他垂直领域有着巨大的相互依赖性。
我将感谢这里的社区，如果你能在这里提出一些解耦代码的方法。
任何指点或参考都将受到高度赞赏和欢迎。
--
谢谢
阿迪亚
你有一个典型的依赖管理问题。为了正确管理它，您必须对每个 MS 进行版本控制并将它们视为外部依赖项，这意味着您可能必须尽早传达更改并同时提供旧版本和新版本，直到所有垂直行业都升级为止。
这就是微服务应该遵循组织结构的确切原因，或者在最好的情况下，组织结构会发生变化以反映服务的功能职责。
在您的情况下，听起来最好是说服您的管理层创建新的团队，每个团队负责一项核心服务（聚合器、文档等）。这样，责任和沟通路径就得到了明确的定义。垂直团队必须向核心服务团队提供功能请求，核心团队将汇总来自所有垂直部门的请求，并宣布和管理新版本的开发和推出等。这就是 google 和其他大型团队的方式公司内部工作顺便说一句。
有关更多背景信息，我建议阅读 articles by Martin Fowler。
在我们的组织中，我们有一个软件系统，由多个微服务提供支持，即：-
- 聚合器 MS.
- 客户女士
- 文档女士
上述每个微服务都有一个 master 分支，其中有最新的代码库。
现在，有多个垂直行业正在积极开发和贡献上述微服务。一些垂直行业（独立的开发人员组）例如：-
- 垂直-A
- 垂直-B
- 垂直-C
在上述微服务中，每个垂直领域都有预定义的策略（他们在其中进行开发）和一些通用代码。
此外，每个垂直领域都有基础架构级别的隔离，这意味着每个垂直领域有 3 个独立的集群设置。
Post 他们各自的部署，每个垂直将他们的代码合并到各自的 master 分支。现在，如果另一个垂直领域必须进行他们的开发，他们必须将他们的 feature/local 分支重新设置为 master 然后继续。
现在的问题是：-
每当 Say Vertical-A 在三个微服务中的任何一个中引入一些更改时，他们都需要从剩余的垂直领域（即 Vertical-B 和 Vertical-C）获得签核。从另一种意义上说，我们在一个垂直领域对其他垂直领域有着巨大的相互依赖性。
我将感谢这里的社区，如果你能在这里提出一些解耦代码的方法。
任何指点或参考都将受到高度赞赏和欢迎。
-- 谢谢 阿迪亚
你有一个典型的依赖管理问题。为了正确管理它，您必须对每个 MS 进行版本控制并将它们视为外部依赖项，这意味着您可能必须尽早传达更改并同时提供旧版本和新版本，直到所有垂直行业都升级为止。
这就是微服务应该遵循组织结构的确切原因，或者在最好的情况下，组织结构会发生变化以反映服务的功能职责。
在您的情况下，听起来最好是说服您的管理层创建新的团队，每个团队负责一项核心服务（聚合器、文档等）。这样，责任和沟通路径就得到了明确的定义。垂直团队必须向核心服务团队提供功能请求，核心团队将汇总来自所有垂直部门的请求，并宣布和管理新版本的开发和推出等。这就是 google 和其他大型团队的方式公司内部工作顺便说一句。
有关更多背景信息，我建议阅读 articles by Martin Fowler。