在微服务体系结构中，如何在处理相同特性的同时管理团队间的交流？

Question

我们是一个由大约60名软件工程师组成的团队，分为几乎6个团队。我们正在致力于一个电子商务项目，并遵循微服务架构。每个团队都对自己的服务负责。

随着团队规模的增长，我们正在向更大和更复杂的特性发展，团队间的依赖和沟通也在增加。假设一个团队正在查看卖方应用程序，而另一个团队负责买方应用程序。现在，这两个团队总是必须密切合作，因为无论卖家将列出什么将可见买方应用程序。现在的问题是，这两个队是紧密结合在一起的。如果一支球队错过了最后期限，那么第二支球队也会受到同样的打击。此外，如果我们在沟通，它也会影响我们的最后期限。

我们已经探索了spotify小队/基于部落的团队结构。这对我们来说很有意义。我只想问一问，这是否是一个好的解决方案，或者我们是否可以做一些其他的事情，以尽量减少团队间的依赖，以平滑交付管道，并建立松散耦合的团队。

Answer 1

团队之所以耦合在一起，是因为他们正在处理的应用程序/微服务是耦合在一起的。您可以使用几种技术来解耦服务，例如：

版本公共API的

在这种情况下，我使用"public“来表示向其他服务/团队公开的API (而不是整个internet )。如果您建立了服务的多个版本可用的原则，这将意味着一个团队可以发布一个新版本，而不必与其他团队同步。

您需要建立一个关闭旧版本的过程，具体来说，您需要对“较慢”的团队施加压力，以升级他们的代码，这样“更快”的团队就不会继续维护大量的服务版本。

服务之间的

通信是一个契约

对一个服务进行中断更改可能会导致另一个服务必须被更新以处理该更改。因此，无论何时进行更改，都应该在给定服务的作者和用户之间进行通信--理论上说，您只需要传递中断的更改，但是讨论API的所有更改是很好的实践。

这将使其他团队能够将这一变化纳入他们的时间表。此外，应该可以模拟出所有的公共API，这样客户端就可以与服务实现更改同时进行测试--客户端不必等到实现完成后才能开始工作。

特征标记/加那利流量

具有打开/关闭功能和/或切换远程服务版本的能力--特别是如果您可以对特定的一组用户或特定的测试进行切换，则可以在大多数通信量激活之前建立对新发布的服务的信心。

摘要

如果一个特性需要对3个服务进行更改才能实现它，那么在启动该特性之前，您仍将绑定到所有准备就绪的服务--但通过打破团队之间的依赖关系，您应该能够允许更快的团队继续/发布其他特性，而不是绑定到较慢的团队的发布周期。

支持同一服务的多个版本可能很乏味，而且可能会减慢团队的速度--您必须弄清楚，这样做对您的团队是否值得。

最后，如果您发现相同的团队总是相互依赖，那么可能值得看一看您的代码--也许可以以不同的方式合并和/或拆分代码库，这样一个团队负责类似的区域--即使它们被划分到多个部署单元。