在微服务环境中，谁应该“拥有”不再积极开发的服务？

Question

在典型的开发环境中，大型团队通常与大型项目保持一致。新功能被硬塞到现有的单体中。团队拥有巨石。尽管单体应用程序的许多部分不再开发，但它们仍由相关团队发布和拥有。如果要进行修复，那么显然是执行修复的团队。

在微服务世界中，构建了许多较小的服务，通常由 1 和 2 的小团队构建，一旦构建可能不再需要更改。然后开发人员继续做其他事情。该服务可能是多个应用程序的依赖项。没有与服务关联的特定“团队”。

那么，当需要对服务进行更改时，如何分配所有权？

Answer 1

有句话说的我出自“养狗多的狗饿死”，意思是人人都管别人的事，就算人家同意分担责任，也没有人真正管。

有很多方法可以解决您的问题，但在所有这些方法中都应该有人负责。解决此问题的一些方法：

1. 应该由一个人负责该项目。如果此人调到新团队，他或她应任命新的项目经理。如果此人离开公司，其余员工应选择其他人。
2. 定期检查每个项目的负责人。如果没有人负责，那就实事求是，指派专人。
3. 每个刚被任命到项目中的人都必须检查他或她是否可以继续发展项目。例如，如果文档写得不好或没有，或者源代码太难阅读，那么新任命的人应该在项目移交时询问以前的负责人。

没有灵丹妙药，但您可以遵循一些原则，以避免将来出现一些麻烦。

Answer 2

就像@Akira 所说。如果每个人都对一项微服务负责，那么就没有人负责。

共同责任

负责给定 MS 的团队每两周就会更换一次。 所以根据日期，你将拥有所有者。

根据他们所服务的产品调整团队

每个团队都负责Product，这不是微服务。它是一组微服务，它们共同为业务带来价值。他们一起工作来完成给定领域的业务需求。您可能将Product 理解为一个系统，它由几个微服务协同工作构成。 这样的团队应该具备整个系统的领域知识，并且应该更有效地支持他们产品下的 MS。

创建新MS后创建和销毁的团队

那样的管理是有问题的。如果 MS 不仅仅是另一个 CMS，而是非常复杂的解决方案，它可能会变得更加成问题。写 MS 的人应该负责支持它。如果他们要让公司成为支持者的价值，请带其他人，但让他们与 MS 的创建者交流和提问。否则 MS 迟早会变得一团糟。

无论您选择什么，都要让您的 MS 文档保持最新状态。