作者：Janet Wagner
近年来，微服务作为一种构建可靠可扩展应用程序的方法越来越受欢迎。亚马逊、微软和 Netflix 等主要公司已经谈论微服务有一段时间了。这篇文章着眼于微服务策略，特别是从单体应用开始，稍后迁移到微服务，以及直接从一开始就使用微服务。
什么是单体应用？
当开发人员谈论单体应用程序时，他们通常指的是一个被视为单个单元、紧密耦合并且通常需要一次性部署到单个服务器的应用程序。单体应用程序也作为一个整体进行扩展，可能共享一个数据库（通常是关系型的），并且通常为整个应用程序使用一个庞大的代码库。所有内容都在代码库中定义，例如前端和服务器端逻辑等，并且通常只使用少量语言来构建应用程序。在某些情况下，单体应用程序可以部署到多个服务器，但该应用程序仍将被视为一个单元。
什么是微服务？
微服务在应用程序开发人员中引起了很多关注，但对于微服务的定义，行业内没有达成一致。微服务更像是一种开发分布式应用程序的概念。但是，许多行业领导者对于微服务的特性达成共识。这些特性包括服务是松散耦合的但受上下文限制，可以彼此独立地部署和扩展，并且与轻量级机制（例如 HTTP、REST API、WebSockets）进行通信。Sam Newman 在书籍《构建微服务》中提供了一个简短的定义：“微服务是协同工作的小型、自主服务。”
构建您的应用程序——首先选择单体还是微服务？
当涉及到微服务和 API 的策略时，这很大程度上取决于您是决定首先使用单体应用程序，然后再迁移到微服务，还是从一开始就使用微服务。
行业领导者对于首先使用单体还是微服务有不同的看法。Martin Fowler，一位知名的作家、软件工程师和 ThoughtWorks 的首席科学家，主张首先使用单体方法。他建议最好从单体开始，然后在需要时再迁移到微服务。innoQ 的联合创始人兼首席顾问 Stefan Tilkov 主张首先使用微服务方法，理由是单体应用的组件最终会彼此紧密耦合。这使得以后很难将单体应用拆分为单独的服务。
应该注意的是，应用程序开发有很多种方法，这不仅仅是二元选择——首先使用单体还是微服务。例如，Gamut 平台高级工程主管 Darby Frey 在 Medium 上的一篇文章中解释说，他的团队决定不首先采用单体或微服务。该团队构建了两个应用程序——不是真正的微服务，也不是单体。该团队构建的架构包括一个 API 网关层，这使他们可以拥有任意数量的后端服务。
在为您的应用程序选择架构之前，需要考虑很多因素。如果您的开发团队没有任何构建微服务的经验，那么单体应用可能是一个更好的选择。如果您希望您的应用程序的功能是最新的，那么您需要为每个功能使用最佳的语言、框架和库。在这种情况下，微服务将是更好的选择。这并不是说您不能使用最新的功能构建单体应用。但是单体应用往往仅限于几种语言，这意味着您最终可能会使用不适合您的应用程序所有功能的语言来构建功能。
从单体应用开始
您为什么要从单体应用开始？与微服务相比，通常更容易部署单体应用，因为它通常是在一个服务器上进行一次部署。而且由于该应用程序被视为一个单元，因此更容易监控和执行端到端测试。与单体应用程序相比，监控和测试分布式应用程序更加困难，因为这些服务通常具有不同的运行时环境。此外，当需要测试某项服务时，还需要启动该服务所依赖的所有其他服务。
那么，为什么您不想从单体应用开始呢？您可能不想从单体应用开始的最大原因之一是单体应用最终会包含许多紧密耦合的组件。这使得扩展和维护代码非常困难。另一个原因是，由于所有紧密耦合的组件，代码库通常会变得难以理解，这使得新开发人员很难上手。
从微服务开始
您为什么要从微服务开始？由于微服务是自主的，因此可以独立快速地开发、部署、测试和扩展服务。还可以使用任何语言开发服务，这意味着开发人员可以试验新技术并添加新功能，而不会干扰应用程序的其他部分。如果一项服务出现问题，其他服务很可能会保持运行。由于一项甚至多项服务出现问题而导致应用程序崩溃的风险将大大降低。
API 传道者 Kin Lane 对设计微服务有一个有趣的看法，即OpenAPI 规范可用于在编写任何代码之前敲定微服务的所有组件。可以使用 OpenAPI 和OpenAPI 相关工具生成文档、服务的模拟表示、发现机制和许多其他微服务组件。
那么，为什么您不想从微服务开始呢？您可能不想从微服务开始的原因之一是跨领域的问题，因为它们往往会在构建微服务时出现。当涉及到微服务时，安全性和跨领域的问题（例如日志记录、缓存和授权）很难解决，并且通常需要大量开发工作。一些公司将使用 API 网关，以便在集中位置实施跨领域的问题和安全性。
从微服务开始可能不是最佳选择的另一个原因是，如果您的团队没有足够的构建微服务的经验。微服务架构本质上是复杂的，因此，如果您的团队没有这方面的经验，那么构建微服务是存在风险的。
微服务之间的通信
微服务是自主服务，采用这种架构的应用程序通常有数十个，有时甚至数百个服务。这些服务需要能够彼此之间以及与客户端进行通信。微服务通常使用容器部署，这些容器使用进程间通信 (IPC) 机制进行交互。IPC 机制最常见的通信方法是 RESTful，尤其是当它涉及请求-响应周期时。这通常意味着使用 HTTP/JSON API。
规划通信策略至关重要，因为服务必须能够高效可靠地进行通信。服务之间的通信面临许多挑战，例如延迟、故障和路由。Red Hat 云应用开发首席架构师 Christian Posta 最近发表了一篇文章，讨论了调用服务以及让服务相互通信是开发微服务中最困难的部分之一。
选择最适合您应用的方法
微服务是应用程序开发的一种流行方法，因为它允许开发人员构建快速、可靠且高度可扩展的应用程序。但是，分布式应用程序往往非常复杂。仅当该方法最适合您的应用程序时才选择微服务。
感谢阅读！正在寻找更多 API 资源？订阅 Swagger 新闻简报。每月都会收到一封电子邮件，其中包含我们最好的 API 文章、培训、教程等。订阅