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