一个存储库中的多个微服务 [英] Multiple microservices in one repository
问题描述
我对微服务和存储库有疑问.我们是一个小团队(5 人)，我们在微服务中创建新项目.我们项目中预期的微服务应用在 10-15 个之间.
I have question about microservices and repositories. We are a small team (5 people) and we creating new project in microservices. Expected microservice applications in our project is between 10-15.
我们正在考虑为所有微服务建立一个存储库，其结构如下:
We are thinking about one repository for all microservices in structure like that:
-/
--/app1
--/app2
--/app3
-./script.sh
-./script.bat
你觉得这个设计怎么样?你能推荐一些更好的吗?我们认为，如果每个应用程序都有存储库，对于一个团队中的小项目来说，这将是过度的.作为我们的应用程序，您可以想象有角度的 spring boot 或 spa 应用程序.谢谢你的建议.
What do you think about this design? Can you recommend something better? We think if we will have repository per app it will be overkill for that small project in one team. As our applications you can imagine spring boot or spa applications in angular. Thank you in advice.
推荐答案
一般来说，您可以将所有微服务放在一个存储库中，但我认为随着每个微服务的代码不断增长，管理起来可能很困难.
In general you can have all your micro-services in one repository but I think while the code grows for each of them it can be difficult to manage that.
在决定将所有微服务放在一个存储库中之前，您可能需要考虑以下一些事项:
Here are some things that you might want to consider before deciding to put all your micro-services in one repository:
开发者纪律:小心代码的耦合.由于所有微服务的代码都在一个存储库中，因此它们之间没有真正的物理边界，因此开发人员可以只使用其他微服务中的一些代码，例如添加引用或类似内容.将所有微服务放在一个存储库中需要一些纪律和规则，以便开发人员不要跨越边界和滥用它们.
Developer discipline: Be careful with coupling of code. Since the code for all your micro-services is in one repository you don't have a real physical boundary between them, so developers can just use some code from other micro-services like adding a reference or similar. Having all micro-services in one repository will require some discipline and rules for developers not to cross boundaries and misuse them.
受到创建和滥用共享代码的诱惑.如果您以适当且结构化的方式进行操作，这并不是一件坏事.同样，这为以错误的方式进行操作留下了很大的空间.如果人们只是开始使用相同的共享 jar 或类似的东西，那可能会导致很多问题.为了共享一些东西，它应该被隔离和打包，理想情况下应该有一些支持向后兼容性的版本控制.这样，当此库更新时，每个微服务仍将具有与先前版本相同的工作代码.它仍然可以在同一个存储库中使用，但与上面的 1. 点一样，它需要规划和管理.
Come into temptation to create and misuse shared code. This is not a bad thing if you do it in a proper and structured way. Again this leaves a lot of space for doing it the wrong way. If people just start using the same shared jar or similar that could lead to a lot of problems. In order to have something shared it should be isolated and packaged and ideally should have some versioning with support for backwards compatibility. This way each micro-service when this library is updated would still have a working code with the previous version. Still it is doable in the same repository but as with the 1. point above it requires planing and managing.
Git 注意事项:在一个存储库中管理大量拉取请求和分支可能具有挑战性，并可能导致以下情况:我被其他人阻止了".此外，由于可能会有更多人参与该项目并提交到您的源分支，您将不得不更频繁地执行 rebase 和/或合并源分支到您的开发或功能分支(即使您不需要从其他服务).为存储库配置的电子邮件通知可能非常烦人，因为您将收到有关不在您的微服务代码中的内容的电子邮件.在这种情况下，您需要在您的电子邮件客户端中创建一些过滤器/规则，以避免您不感兴趣的电子邮件.
Git considerations: Managing a lot of pull requests and branches in one repository can be challenging and can lead to the situation: "I am blocked by someone else". Also as possibly more people are going to work on the project and will commit to your source branch you will have to do rebase and/or merge source branch to your development or feature branch much more often(even if you do not need the changes from other services). Email notifications configured for the repository can be very annoying as you will receive Emails for things which are not in your micro-service code. In this case you need to create some Filters/Rules in your Email clients to avoid the Emails that you are not interested in.
微服务的数量比最初的 10-15 个增长得更多.这个数字还能增长吗?如果不是一切都很好，但如果在某个时候确实如此，您可能会考虑将每个微服务拆分到一个专用存储库中.在您处于项目后期阶段时执行此操作可能具有挑战性，并且可能需要一些工作，在最坏的情况下，您会发现人们随着时间的推移产生了一些耦合，您必须在此阶段解决这些耦合.
Number of micro-services grow even further then your initial 10-15. The number can grow? If not all fine but if it does at some point you could maybe consider to split each micro-service in a dedicated repository. Doing this at the point where you are in later stage of project can be challenging and could required some work and in worst case you will find out that there are some couplings that people made over time which you will have to resolve at this stage.
CI 管道注意事项:如果您使用 Jenkins 之类的东西来构建、测试和/或部署您的代码你可能会遇到一些小的配置困难，比如 Jenkins 和 Github 之间的集成.如果有人针对该微服务创建合并/拉取请求，您将需要配置一个管道，该管道只会构建/测试代码的特定部分(或一个微服务).我从来没有尝试过做这样的事情，但我想你必须弄清楚如何去做(脚本和自动化).我想这是可行的，但需要一些工作才能实现.
CI pipelines considerations: If you use something like Jenkins to build, test and/or deploy your code you could encounter some small configuration difficulties like the integration between Jenkins and Github. You would need to configure a pipeline which would only build/test a specific part of the code(or one micro-service) if someone creates a merge/pull request against that micro-service. I never tried to do such a thing but I guess you will have to figure out how to do it(script and automate this). It is doable I guess but will required some work to achieve it.
结论
仍然可以通过一些额外的管理和配置来解决所有或大部分问题，但仍然值得了解您可能会遇到的额外工作.我想还有一些其他要点需要考虑，但我的一般建议是如果可以的话，为每个微服务使用单独的存储库(私有存储库定价和类似原因).这是一个项目一个项目做出的决定.希望这篇笔记对你有帮助:)
Still all or most of this points can be resolved with some extra management and configuration but it is still worth knowing what additional effort you could encounter. I guess there are some other points to be taken into considerations as well but my general advice would be to use separate repositories for each micro-service if you can(Private Repository pricing and similar reasons). This is decision which is made project by project. Hope this notes help you :)
这篇关于一个存储库中的多个微服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
