什么是微服务？

本文最初发表于 Medium。您可以点击此处阅读。

微服务正在成为一种非常流行的应用程序架构设计。但每当有人试图向我解释什么是微服务时，我都会有同样的疑问：微服务究竟是什么？它与 API 有何不同（如果真有区别的话）？

上周我将API描述为允许软件应用程序相互通信的接口。另一方面，微服务是大型应用程序的小型组件。API 是用于公开组件（也称为微服务）中功能的接口。API 不是微服务，微服务也不是 API 的实现。它们之间有关联，但并不等同。

但是，微服务究竟有何必要？API 为何不够好？应用程序往往会随着时间的推移而增长，最终变成庞然大物。在这种情况下，应用程序的复杂性会不断增加，以至于单个开发人员无法完全理解整个代码库。因此，修复错误和实现新功能变得更加困难和耗时。更糟糕的是，由于应用程序的复杂性，这些新的更改甚至可能无法正确执行。

单体应用的另一个问题是难以持续部署，因为即使只是很小的变更，也需要部署整个应用。重新部署和启动应用所需的时间会浪费宝贵的时间，从而降低生产力。此外，这些庞大的应用缺乏弹性，因为一个 bug 就可能导致整个应用崩溃，因为它们都在一个进程中运行。

微服务通过以下理念解决了这些问题：将大型应用程序拆分成多个小型、解耦、独立的系统，这些系统再连接在一起，使应用程序正常运行。总体功能保持不变，但应用程序被拆分成易于管理的模块。每个模块都是一项服务，可以由专注于该服务的团队独立开发。这意味着团队真正理解代码库！因此，他们可以更快地编写、部署和测试，从而提高生产力。团队可以选择他们想要使用的语言或最新技术，而不会受到应用程序其他部分的限制。

微服务的另一个优势是每个服务都可以独立部署。这一特性非常有益，因为开发团队现在可以使用最符合每个服务资源需求的硬件，而不必在硬件上做出妥协。独立部署带来了可扩展性，因为每个组件都可以进行适当的扩展，从而能够根据需求变化高效利用资源。此外，微服务架构具有弹性，因为容器是独立部署的，即使一个组件发生故障也不会导致整个应用程序崩溃。

然而，微服务并非软件开发架构的灵丹妙药。与所有技术一样，微服务也有其缺点。由于分布式系统，微服务可能会变得非常复杂。当服务数量增加时，应用程序的集成、部署、测试和管理都会变得复杂。例如，由于服务之间的依赖关系，跨多个服务进行更改可能非常困难。在单体应用程序中，您可以一步完成模块更改、集成更改和部署。测试也更简单，因为您可以轻松启动端到端测试。

然而，在微服务架构中，你必须协调服务之间的变更，并规划部署以实施变更。为了测试你的变更，你必须确保所有依赖的服务（包括你进行变更的服务）都能正常工作。

此外，在微服务架构中，开发人员必须在服务之间实现某种类型的通信机制。这增加了应用程序的开销，从而增加了复杂性。

总而言之，微服务架构强制模块化，这使得单个服务可以更快地部署，并且更易于理解和维护。与所有技术一样，微服务也有如上所述的缺点。作为开发人员/架构师，了解哪种架构最适合您的项目至关重要，因为有时单体架构是正确的选择，而有时微服务才是最佳选择。

这是我的“什么是”科技博客系列的第三篇文章。我会每周在这里和我的博客上撰写更多文章！