我有一个 Python 网站和一个将用 GO 编写的 GRPC 服务。
我希望在网站上引入微服务。
-GRPC 聊天服务器将使用 GOLANG 编写。 GRPC 客户端将用 python 编写，因为我的网站是 python。将来我也想要一个快速的 GRPC 存根与这个 go 服务器进行通信。
这是正确的架构吗？
我的网站当前的 GRPC 客户端
聊天提交按钮-> python grpc 客户端-> 转到grpc 服务器-> 数据库-> gogrpc 服务器-> pygrpc 客户端->UpdateChat
来自任何语言的未来移动 GRPC 客户端的请求 UpdateChatRequest-> 任何 GRPC 客户端 -> 转到 GRPC 服务器 -> 数据库 -> 转到 GRPC 服务器 -> 任何 GRPC 客户端->UpdateChat
答案 0 :(得分：0)
如果您打算构建多个您可能称之为“gRPC 客户端”的东西，它们与 Go gRPC 服务器通信以执行聊天的 CRUD 操作，这看起来是一个不错的模型。我会说，如今，许多 gRPC 实现用于微服务间通信，而不是用于标准（客户端 -> 网关 -> 微服务集群）客户端 - 服务器通信。在我看来，这主要是由于 gRPC-web 无法完全通过 HTTP/2 运行。现在，老实说，我认为在胖客户端（如原生移动或桌面）上实现 gRPC 没有问题，因为在这些场景中可以完全支持 gRPC，只是在浏览器中还没有。
如果您没有在前端使用 gRPC-web，那么可能值得研究一下。 gRPC-web 无论如何都需要代理，因此无论您是否使用 gRPC，您都在 HTTP/1.1 上运行，直到浏览器支持更直接地与 HTTP/2 耦合。
有点不清楚，但你的架构不一定是尖叫的微服务。实际上，最好不要将“微服务”概念视为应该发生的一夜之间的过渡。你的拱门现在是一块巨石。使用 gRPC 之类的技术不会自动使您的架构成为微服务架构，但它确实可以让您更好地准备gradual transition，以便将架构开发为更多的分布式、基于服务的模型。当然，“微服务”这个词经常是一个流行词，有很多不同的含义，重要的是要知道你在什么上下文中思考。