API架构风格 - 技术栈

1. RPC

调用另一个系统的函数，

远程过程调用是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在问题的，因为很难确保 XML 有效负载的数据类型。因此，后来 RPC API 开始使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。

RPC 的工作机制

客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。

RPC 的优势

简单直接的交互。 RPC 使用 GET 来获取信息，使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。

易于添加新函数。 如果 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并获取符合其需求的信息。

高性能 。轻量级的有效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得非常高效。

RPC 的不足

和底层系统紧密耦合。 API 的抽象级别有助于其可重用性。API 与基础系统的耦合越紧密，对其他系统的可重用性就越差。RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立抽象层。这很容易引起安全问题，因为关于基础系统的细节实现很容易会泄漏到 API 中。

RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么会担心调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，因为客户端不了解服务器如何命名其函数。

可发现性低。 在 RPC 中，无法对 API 进行检验总结，或者发送请求来开始理解根据需求应该调用哪个函数。

函数爆炸性增长 。创建新函数非常容易。因此，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能重叠的函数。

RPC 的用例

RPC 模式在八十年代开始使用，但这并不意味着它已经过时了。诸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司如今正在内部使用高性能的 RPC 版本，来执行极高性能、低开销的消息传递。它们庞大的微服务系统要求内部通信在使用短消息的情况下也保持清晰。

命令 API 。RPC 是用于将命令发送到远程系统的正确选择。例如，Slack API 是非常以命令为中心的：加入频道、离开频道、发送消息。因此，Slack API 的设计者以类似于 RPC 的样式对其进行了建模，使其小巧、紧凑并且易于使用。

用于内部微服务的客户特定的 API 。由于是在单个提供者和单个使用者之间建立直接的集成，我们不想像 REST API 那样，花太多时间通过网络传输大量的元数据。凭借高消息速率和消息性能，gRPC 和 Twirp 成为了用于微服务的可靠用例。通过在底层使用 HTTP 2，gRPC 能优化网络层，使其非常高效地在不同服务之间每天传送大量信息。然而，如果你并不是要着眼于提高网络性能，而是要在发布高度独立的微服务团队之间建立一个稳定的 API 联系。REST 就能做到。