Docker实现中的微服务

我们正在使用Amazon fargate使用Docker容器编写第一个微服务。我们对使用Spring Boot的实现水平有很多疑问

我们将在项目中拥有多个微服务，这是一种好的做法，我们将所有微服务都写在一个容器中，还是我必须为单独的微服务创建单独的Docker容器。我们以节省成本的方式使用单个容器，但是这将来会对我们的项目结构造成任何问题吗？

我们正计划在AWS fargate中部署该应用程序，并且我们的应用程序将具有很大的扩展空间，可以在将来扩展，并有望提供约100至150种不同的微服务。在这种情况下，如果我们也将所有这些微服务也上传到不同的容器中，是否具有成本效益？

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

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

例如，如果您的组织：

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

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

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

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

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

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

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

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