许多存储库过时的微服务答案

【问题标题】：Microservices with many repositories out of date许多存储库过时的微服务
【发布时间】：2016-02-22 04:43:36
【问题描述】：

在微服务架构中，让许多开发人员环境跨多个源代码存储库保持最新的最佳策略是什么？

假设有 10 个 10 名开发人员的团队在 git 中开发 200 个微服务。每个开发人员都需要定期从每个存储库中提取。这可以用脚本来完成，但有更好的方法吗？我们做错了吗，因为这似乎是一个沉重的开销。

【问题讨论】：

每个开发人员都在开发每个微服务吗？开发人员不会只关心他们正在开发的微服务和（也许）他们的直接依赖关系吗？
不，他们一次只能处理几个，但需要保持其他所有内容都是最新的。如果需要，任何团队都可能会更改任何 repro 中的代码。通常团队会在一个子集上工作。
这里团队和所有权的明确分离是什么？所有 10 个团队都拥有 200 个微服务吗？在那种情况下，这听起来更像是一个组织问题。如果没有所有权，任何开发人员都不会了解整个服务系统以及它们如何为更大的产品做出贡献。

标签： github teamcity microservices octopus-deploy devops

【解决方案1】：

我不建议让每个开发人员都构建每个微服务。我会提出某种持续集成环境。一个连接到所有 git 存储库的集中式构建服务器。

每次更新存储库时，构建服务器都应检测更改、构建代码、运行单元（和/或功能）测试，然后将服务推送到某种集成环境。然后，构建服务器还可以针对已部署的服务运行一些集成测试。

大多数开发人员应该能够在不需要访问其他微服务的情况下完成所有开发和测试。如果开发人员正在构建依赖于 Y 和 Z 并由 A 和 B 依赖的服务 X，那么开发人员在大多数情况下应该只有服务 X。对于单元测试服务 Y 和 Z 应该被模拟/模拟。

挑战在于防止开发人员通过更改服务 X 来破坏服务 A 和 B。这种集成测试往往比较棘手，因为从事服务 X 的开发人员通常不知道细节（甚至如何使用）上游服务（例如 A 和 B）。

我认为解决这个问题的方法是定期进行集成测试，要么由服务 X 的构建触发，要么定期运行。对于一个如此复杂的项目，强大而健壮的单元测试理念和集成测试框架将是必不可少的。

【讨论】：

【解决方案2】：

这归结为您的服务定位/检测技术很好。一项服务需要知道的就是将请求 X 发送到哪里，以便从特定服务获得响应 Y。如果这个执行得很好。您可以很好地让每个开发人员在本地运行他直接处理的任何服务子集，并让其余服务在公共环境中运行（我们称之为远程）

Remote 将配置为在您的平台上运行所有服务，并且将通过某种方式获取最新代码（基于节奏或基于定期间隔）。本地环境可以配置为所有在本地运行的服务都知道在本地运行的还有什么，并且知道在需要任何信息时如何访问远程服务。对于开发人员环境，添加约定，让每个开发人员运行生产性开发所需的最少服务数量。这意味着如果您没有将代码作为服务使用，请远程运行它，这样您就知道您正在运行最新的代码并且没有过时。

这种方法的几个陷阱

您可以在本地运行服务 A 并在远程运行服务 B。您在本地测试了所有内容，并且似乎可以正常工作，因此您决定推动。在您推送时，另一个开发人员也将更改推送到 B，现在您的更改不再兼容。
如果您在本地运行服务 A 和 C，而在远程运行 B，则将服务 B 的请求路由到远程环境应该非常简单。但是，您应该注意，如果 A 调用 B 并且 B 调用 C，那么对 C 的调用需要从远程环境路由到本地 C 服务，而不是远程 C 服务。
测试 - 通过使用两个独立的测试套件，您可以解决很多与在这样的复杂环境中进行测试相关的问题。 1. 单元测试 - 测试服务中的各个组件，并模拟对其他服务的所有调用。 2. 环境集成测试——这些测试验证不同服务之间的通信。 Suite 1 将检查您的服务的内部代码，Suite 2 将在您将更改推送到远程后运行，并将持续确保服务间通信按预期进行。

希望有帮助

【讨论】：