使用微服务时要记住的最重要的一点是它们不是主要解决技术问题，而是组织问题。因此，当我们查看组织是否应该使用微服务以及如何部署这些服务时，我们需要查看组织是否存在微服务样式解决的问题。

那么，关于您的体系结构问题的答案将主要取决于技术团队的规模，组织结构，产品的年龄，您当前的部署实践以及在整个过程中这些变化的可能性。学期。

例如，如果您的组织是

• 少于25名技术人员，
• 分为1或2组，
• 每个都可以在产品的任何部分上使用，
• 还不到12个月的时间，
• 并定期（例如每天，每周，每月）一次全部部署
• 并且组织不会迅速发展，

那么您几乎肯定现在就想要忘记微服务。在这种情况下，团队仍然是学习领域的新手，因此可能不了解他们真正了解将系统拆分为分布式体系结构的一种好方法所需的全部知识。这意味着，如果他们现在将其拆分，他们可能稍后会希望更改边界，并且当您已经有分布式系统时，这变得非常昂贵，而在整体中则要简单得多。而且，只有一个可以共同工作（和支持）系统任何部分的小组，没有什么理由投资建立一个平台，单个团队可以部署和维护单个服务。在这个阶段，组织通常会更加关注寻找客户和快速迭代产品（甚至可能是产品），而不是使团队自治并建立大规模的弹性架构。整体架构在这一点上是有意义的，但设计得很好的整体架构具有由API强制执行的清晰的组件边界和封装的数据访问权限，因此很容易在以后将服务提取到单独的进程中。 >

让我们再进一步看一下，考虑一个组织...

• 超过50名技术人员，
• 分为7个团队，
• 其中每个仅适用于产品的特定区域，
• 已经3岁了，
• 并且有团队希望独立于其他团队在做什么而部署他们的工作。

这样的组织肯定应该在构建分布式体系结构。如果他们不这样做，而是让所有这些团队都在一个整体中工作，他们将遇到各种组织问题，团队需要协调他们的工作，发布会被延迟，而一个团队要完成对新功能补丁的质量检查部署给员工和客户带来了极大的麻烦。此外，对于成熟的产品，组织应该对领域有足够的了解，以便能够明智地将领域和团队（按此顺序；请参阅康韦定律）划分为明智的自治部门，这些部门可以在不断进步的同时最大程度地减少协调。

您似乎已经选择了微服务。根据您在上面的尺度上所处的位置，也许您想重新考虑该决定。

如果您想继续使用微服务进行开发，而是将它们全部部署在一个容器中，请知道这没什么问题，如果它适合您组织的当前工作方式。将来会给您的项目结构带来麻烦吗？好吧，如果您成功了并且您的组织不断壮大，那么很可能会出现这种不再包含单个容器的部署的情况，特别是当团队开始拥有服务并希望仅部署其服务而不部署整个应用程序时。但是，这种自治将以额外的工作和复杂性为代价，并且在此时此刻可能不会给您带来任何好处。仅仅因为它将来不是您系统的正确方法，并不意味着它不是今天的正确方法。诀窍在于留意并知道何时进行额外投资。

如果您对微服务使用单个容器，则没问题，但微服务的主要目标是分别维护每个服务，每个服务应松散耦合，并且每个服务应具有单独的数据库（如果要为每个服务体系结构实现数据库） 。 因此，请尝试实现此目标，并在单独的容器中运行服务，并使用docker swarm或Kubernetes协调这些服务。 我知道成本很重要，但是如果您以正确的方式进行操作，那么您将看到微服务架构的强大功能。