读 microservices apis

微服务也带来了一些挑战。它们需要较大规模的基础设施开销，并且监控、操作和追踪起来更加困难。在使用微服务时，首要挑战是正确设计它们

微服务是一种架构风格，在该风格下系统组件被设计为可独立部署的服务。微服务围绕着明确定义的业务子域进行设计，并使用轻量级协议（例如HTTP）相互交流。

微服务是作为独立进程部署的，通常在独立环境中运行，并通过明确定义的接口公开其功能

越大的单体应用，测试所需时间就越长。每个单体应用的部分都必须进行测试，并且随着我们为其添加新功能，测试套件也会变得更大

cURL是libcurl库的命令行接口。libcurl实现了与URL交互的功能，而cURL通过命令行界面公开了这些能力

problems:

• 有效的服务拆分
• 微服务集成测试
• 处理服务不可用性
• 追踪分布式事务
• 增加了操作复杂性和基础设施开销

如果你发现在更改一个服务时不得不同时更改另一个服务，那么说明你的服务之间存在过度耦合。在这种情况下，要么服务之间的契约不够弹性，要么两个组件之间存在足够多的依赖关系以证明它们应该合并。未能将系统拆分为独立的微服务可能导致克里斯·理查森（《Microservices Patterns》作者）所称的“分布式单体”，即将单块架构和微服务架构的所有问题结合起来，却无法享受其中任何一种架构带来的好处

涉及多个微服务协作的单个事务情况下，微服务集成测试可能会变得非常困难。当整个应用程序在同一个进程中运行时，很容易测试不同组件之间的集成，并且大部分只需要编写良好的单元测试即可。在微服务环境中，为了测试多个服务之间的集成，您需要能够以与生产环境类似的设置来运行所有这些服务。

我们必须确保我们的应用程序在服务不可用、连接和请求超时、错误请求等情况下具有弹性

复杂的请求链中，如果其中一个涉及的服务未能按预期响应，就会触发一个级联错误，导致订单无法处理或处于不一致状态。因此，设计微服务时要确保它们能够可靠地处理失败的端点。我们的端到端测试应该考虑这些情况，并测试我们的服务在这些情况下的行为。

协作服务有时必须处理分布式事务。分布式事务是需要两个或多个服务共同合作完成的事务。所有这些操作都是相关的，它们必须协调一致，要么全部成功，要么全部失败；但是对于微服务来说，我们必须管理各种过程的结果。使用微服务时面临的挑战是确保服务之间具有强大的通信过程，以便在出现错误时准确了解错误类型，并采取适当措施进行响应。

当您有十几个微服务时，每个服务都必须进行配置、部署和管理。这不仅包括为部署服务而提供服务器，还包括日志聚合流、监控系统、警报、自动恢复机制等等。正如您将在第三章中了解到的那样，每个服务都拥有自己独立的数据库，这意味着它们还需要多个数据库设置以满足大规模运营所需的所有功能。而且很常见的情况是新部署会更改微服务的终端点，无论是IP地址、基本URL还是通用URL内特定路径，这意味着必须通知其消费者进行相应变更。

当亚马逊首次开始向微服务架构迈进时，他们发现开发团队约70% 的时间花在管理基础设施上（https://vimeo.com/29719577 at 07:53）。如果您不从一开始就采用最佳实践来进行基础设施自动化，则面临非常真实的风险。即使您采用了最佳实践，也很可能需要花费大量时间开发定制工具来有效、高效地管理您的服务。

以文档为驱动的开发是一种构建API的方法，分为三个阶段：

• 第一阶段：设计和编写API文档。
• 第二阶段：根据文档构建API客户端和服务器。
• 第三阶段：对比文档测试API客户端和服务器。

API文档是对遵循标准接口描述语言（IDL）的API进行描述，例如REST API使用OpenAPI，GraphQL API使用模式定义语言（SDL）。标准IDL具有工具和框架生态系统，使得构建、测试和可视化我们的API更加容易，因此值得投入时间学习它们