微服务：Mono仓库的优缺点

最近，关于Quora上的微服务存在一个有趣的问题–哪些公司使用Mono Repo但将其部署为微服务？

真正的问题隐藏在这些词的后面–使用Mono repos存储微服务代码可以吗？

乍看起来，微服务和Mono仓库似乎相互矛盾。 当微服务代码要彼此独立部署时，在单存储库中包含微服务代码是否有意义？

有没有公​​司采用这种运作方式？

是的，他们做到了！

1. 根据此帖子，Facebook具有单存储库-Facebook上的Scaling Mercurial 。
2. 有传言称Google拥有单声道回购协议（如许多帖子所述），但是我不确定，因为我没有在那儿工作过。
3. 他们博客上的可运输物品提到他们有一个单声道仓库。 实际上，它们已从多个存储库转移到一个单存储库。

使用微服务体系结构的最重要结果应该是每个服务都必须是完全自治的，即它们必须不具有任何设计时间依赖性。

所有其他注意事项因公司而异。 这些注意事项包括：

1. 应用程序的含义： Martin Fowler的声明完美地体现了微服务的本质- “简而言之，微服务架构风格是一种将单个应用程序开发为一组小型服务的方法”。 关键字来自“单一应用程序” 。 归根结底，所有微服务都在组成一个应用程序。 对于某些人来说，将所有源代码放在一个地方更有意义，因为单独的一项服务可能没有任何意义。
2. 代码样式：一些公司发现在所有代码中强制使用一致的编码格式很有用。 当您有单独的存储库时，这当然更难实现。 对于依赖手动验证代码而不是自动代码质量检查的公司，尤其如此。
3. 测试：将所有服务都放在一个存储库中时，创建集成测试会更容易，因为创建测试环境和部署变得更加容易。

请注意，只有一个存储库会带来许多缺点 。

1. CI和CD管道：理想情况下，您希望每个微服务的CI和CD管道彼此独立。 如果其中一项服务有错误，则您不希望整个构建失败。
2. 代码依赖性：难以避免编译时依赖性。 您将需要一个过程或一个人来确保没有人在构建彼此依赖的服务。 同时，请记住，mono repo并不意味着紧密耦合的代码。
3. 团队依赖关系：从上述观点出发，共享单个存储库的团队没有完全自由地进行代码更改，因为它们依赖于其他服务的代码。

因此，总而言之，确实存在某些组织因素，这些因素迫使在单一存储库中使用微服务代码。 只要存在适当的指导方针来管理不同团队所拥有的代码之间的依赖关系和所有权，这就是很好的选择。

翻译自: https://www.javacodegeeks.com/2016/07/microservices-pros-cons-mono-repos.html