假设您有一个像书店这样的应用程序，并且您在后端将其拆分为两个简单的微服务 ->
微服务 1：图书购买者（有账户） 微服务 2：书单。
假设您从前端发出请求，进入反向代理，然后请求进入微服务 1。
您如何准确地想象微服务 1 与微服务 2 的通信方式？
您是否将微服务容器化，并且在其中您有一个 grpc 客户端和服务器？
客户端是否与微服务 1 的服务器以及微服务 2 的服务器通信？
在这张图片中，您似乎将客户端和服务器分别容器化...？
【问题讨论】：
标签： grpc grpc-python grpc-go grpc-node
IIUC 你是问gRPC 服务器是如何实现protobuf 描述的功能的？
我想你指的是example
protobuf 编译器生成您必须实现的客户端和服务器存根。您可以在任何语言实现中实现这些。当您实现服务器时，您完全负责确保例如ListBooks()（对于书架）返回由CreateBook() 添加到书架的所有书籍。
实现独立于 gRPC。
rpc ListBooks(ListBooksRequest) returns (ListBooksResponse) {}
rpc CreateBook(CreateBookRequest) returns (Book) {}
gRPC 在概念上只是确保您的客户端认为他们正在调用本地方法：CreateBook() 实际上，他们正在调用本地存根，该存根通过网络将请求传输到接收的远程服务器CreateBook() 请求并对其进行处理。
所以，让我们专注于服务器，它可能会使用某种形式的持久性来记录书架和书籍。在实践中，这将是一些数据库：
type Server struct {
db db
}
func (s *Server) CreateBook(r *pb.CreateBookRequest) {
shelf := s.db.Get(r.get_shelf())
shelf.Add(r.get_book())
}
func (s *server) ListBooksRequest(r *pb.ListBooksRequest) {
shelf := s.db.Get(r.get_shelf())
for _, book := range shelf.Get() {
fmt.Println(book)
}
}
注意 在上面，gRPC 服务的服务器实现包括一个数据库连接，gRPC 方法用来与数据库交互。这也可能代表其他一些微服务......一路上都是海龟！
所以，为了回答您的问题，在您的微服务内部的某个地方，存在某种形式的共享状态（例如数据库或类似的），例如书籍被持久化（在书架上）。
客户端和|或服务器是否被容器化，虽然可能是好的做法，但与通信如何发生的问题无关。
【讨论】：