了解微服务和 GRPC答案

【问题标题】：Understanding Microservices and GRPC了解微服务和 GRPC
【发布时间】：2021-02-24 05:25:09
【问题描述】：

我有一个 Python 网站和一个将用 GO 编写的 GRPC 服务。

我希望将微服务引入网站。

-GRPC 聊天服务器将使用 GOLANG 编写。 GRPC 客户端将用 python 编写，因为我的网站是 python。将来我也想要一个快速的 GRPC 存根来与这个 go 服务器进行通信。

这是正确的架构吗？

我的网站当前 GRPC 客户端
聊天提交按钮-> python grpc client-> go grpc server-> DB -> gogrpc server-> pygrpc client->UpdateChat

来自任何语言的未来移动 GRPC 客户端的请求 UpdateChatRequest-> Any GRPC Client -> go GRPC server -> DB -> go GRPC Server -> Any GRPC Client->UpdateChat

【问题讨论】：

您的问题是关于架构的。很难回答，因为存在不同的权衡。相反，我建议在互联网上搜索这个主题。

标签： grpc

【解决方案1】：

如果你打算构建多个你可能称之为“gRPC 客户端”的东西，它们与 Go gRPC 服务器对话以执行聊天的 CRUD 操作，这看起来是一个不错的模型。我会说，如今，许多 gRPC 实现用于微服务间通信，而不是用于标准（客户端 -> 网关 -> 微服务集群）客户端-服务器通信。在我看来，这主要是由于 gRPC-web 无法完全在 HTTP/2 上运行。现在，老实说，我认为在胖客户端（如原生移动设备或桌面）上实现 gRPC 没有问题，因为 gRPC 在这些场景中可以得到完全支持，只是还没有在浏览器中。

如果您没有在前端使用 gRPC-web，那么可能值得研究一下。 gRPC-web 无论如何都需要代理，因此无论您是否使用 gRPC，您都在 HTTP/1.1 上运行，直到浏览器支持更直接地与 HTTP/2 耦合。

有点不清楚，但你的拱不一定是尖叫微服务。实际上，最好不要将“微服务”概念视为应该发生的一夜之间的过渡。你的拱门现在是一块巨石。使用 gRPC 之类的技术不会自动使您的架构成为微服务架构，但它确实让您为 gradual transition 做好准备，您应该将架构开发成更多的分布式、基于服务的模型。当然，“微服务”一词通常是一个流行词，具有许多不同的含义，重要的是要知道你在思考什么上下文。

【讨论】：