我在 Golang 中有 2 个 REST 服务：一个用于身份验证，另一个用于用户钱包信息。鉴于不允许 gRPC，使服务相互通信的最简单方法是什么？
另外，不确定这是否相关，但两个服务共享一个公共数据库服务器，但具有不同的数据库。
【问题讨论】：
标签： api rest go microservices
这在很大程度上取决于您的服务间通信的要求。
RPC（远程过程调用）是一种通用的通信模式。 RPC 非常适合同步（等待响应）操作。它实际上是在另一个程序中调用一个函数/过程，它最适合命令诸如“sendAnEmail”、“lauchNukes”或“suspendAccount”之类的操作。
gRPC 不是唯一的 RPC 变体，JSON-RPC for 是一个非常简单的实现，基本上可以在任何传输连接 (TCP/TLS/HTTP) 上使用。甚至 go 标准库也有一个内置的 rpc over http package。
REST(REpresentational State Transfer) 非常适合服务间通信。它最适合同步（等待响应）数据相关的任务，例如数据的插入、更新、删除和查询。
因为 REST 是带有一些约定的 HTTP，所以您拥有很多功能。所以制作一个 REST API 很容易，但做好却很难。
message bus or message queue 是与其他服务进行异步通信（发送消息，不等待回复）的好方法。它们允许您传达事件和请求，而无需明确知道谁将接收它，这使得添加或删除组件变得非常容易，例如系统级别的组合。根据您的设置，您可以将相同的消息广播到多个接收器或负载平衡消息，这样您就可以通过添加额外的副本来扩展服务，而无需在客户端执行任何操作。这些系统的示例包括：Apache Kafka、RabbitMQ 或 Amazone SQS（如果您使用云服务）。
使用数据库进行服务间或进程间通信通常被视为anti-pattern，尽管我已经多次看到它这样做了。这种模式是异步的，通常需要长时间轮询数据库以获取最近的更改，这本质上不如专用系统好。在尝试平衡涉及数据库事务等的消费者之间的消息时，它也会遇到困难。 TL；DR：db 不是为 IPC 设计的。
当然，您可以通过无数种方式让 2 个服务进行通信。我想我介绍了最流行的那些，主要的收获是你应该始终从需求开始，然后选择适合你需要的东西。
【讨论】：