微服务与单体架构

技术的演进改变了我们构建应用程序架构的方式。Docker、云服务和容器编排服务使我们能够开发分布式、更具可扩展性和可靠性的解决方案。在本文中，我们将比较微服务和单体架构，讨论哪些团队和项目应该使用哪种架构，并探讨它们的优缺点。

乍一看，这些类型之间的区别可以这样说明

严格来说，单体应用程序并不总是简单的，但微服务通常要大 10 倍，而且几乎总是需要更多的资源。

让我们逐一讨论一下每种方法的优缺点。

部署

单体应用允许你一次性设置部署，然后根据持续的变化进行简单的调整。然而，部署过程中也存在单点故障，如果一切都出错，可能会毁掉整个项目。

微服务需要做更多工作；你需要独立部署每个微服务，考虑编排工具，并尝试统一 CI/CD 流水线的格式，以减少为每个新微服务执行这些操作所需的时间。然而，这也有好的一面：如果出现问题，你只会破坏一个小的微服务，这比破坏整个项目要好得多。而且，回滚一个小的微服务也比回滚整个单体应用要容易得多。

维护

如果您计划使用微服务架构，请为您的团队制定 DevOps 计划并做好准备。并非所有开发人员都熟悉 Docker 或编排工具，例如 Kubernetes、Docker Swarm、Mesosphere 或任何类似的工具，这些工具可以帮助您管理包含大量移动部件的基础设施。必须有人监控并维护每个微服务和整个基础设施的 CI 配置的运行状态。

可靠性

微服务架构显然是这方面的赢家。一个微服务崩溃只会影响其中一部分，并给使用它的客户端带来问题，而不会影响其他部分。例如，如果你正在构建一个银行应用程序，而负责取款的微服务宕机了，这绝对比整个应用程序被迫停止要严重得多。

可扩展性

就可扩展性而言，微服务再次显得更合适。单体应用难以扩展，因为即使运行更多工作线程，每个工作线程都会占用整个项目，这是一种低效的资源利用方式。更糟糕的是，你可能会以无法水平扩展的方式编写代码，最终导致单体应用只能进行垂直扩展。而使用微服务，这一切就变得容易得多。你可以更谨慎地使用资源，并只扩展需要更多资源的部分。

成本

成本计算起来很棘手，因为单体架构在某些情况下更便宜，但在其他情况下则不然。例如，微服务拥有更好的可扩展性，你可以设置自动扩展，只在用户量真正需要更多资源时才付费。同时，为了维护该基础设施的正常运行，你需要付费的 DevOps 团队。对于小型单体应用，你可以在 5 到 20 美元的主机上运行并启用快照功能。对于大型单体应用，你可能需要托管一个非常昂贵的实例，因为你无法在多个小型廉价主机上共享它。

发展

在我们的一个项目中，我们有 16 个微服务，根据我的经验，处理起来非常棘手。处理微服务的最佳方法是从一开始就构建 docker-compose 文件，并通过 Docker 进行开发。这有助于减少新人入职的时间；只需从头开始运行系统，并根据需要启动所有微服务即可。打开 10 多个终端窗口并执行命令来启动每个服务非常麻烦。

另一方面，当你开发一个微服务时，可能根本不需要运行应用程序的其他部分。由于更好的任务分解流程以及跨微服务隔离开发人员的能力，这可以减少 Git 冲突的问题。

使用微服务进行代码审查和 QA 更加简单；您甚至可以使用不同的语言编写微服务。

释放

规模较小且采用合理微服务通信架构的微服务，可以减少 QA 时间、构建时间和测试执行时间，从而加快新功能的发布速度。单体式应用具有大量无法拆分的内部依赖关系。此外，您已承诺的某些功能可能依赖于团队成员未完成的更改，这存在更高的风险，从而可能导致发布延迟。

什么建筑对你来说更好？

如果您符合以下情况，请使用整体架构：

• 有一个小团队。
• 构建新产品的 MVP 版本。
• 没有获得数百万的投资来聘请 DevOps 或在复杂的架构上花费额外的时间。
• 具有在Ruby on Rails、Laravel等稳定框架上开发的经验。
• 没有看到某些关键功能的性能瓶颈。
• 认为微服务很酷而且是一种趋势。

请记住，如果您发现项目中需要微服务，那么由于这些小型微服务，整体架构总是存在崩溃的风险。

如果您符合以下情况，请使用微服务架构：

• 没有紧迫的期限；微服务需要您进行研究和架构规划以确保其有效。
• 拥有一支精通不同语言的团队。
• 非常担心产品的可扩展性和可靠性。
• 可能有几个开发部门（甚至可能在不同的国家/时区）。
• 拥有一个现有的整体应用程序，并发现应用程序的各个部分存在问题，这些问题可以拆分到多个微服务中。