我計劃提供兩項服務。用 Ruby 編寫的 HTTP REST 服務用 Go 編寫的 JSON RPC 服務Ruby 服務將打開一個到 Go JSON RPC 服務的 TCP 套接字連接。它將為收到的每個傳入 HTTP 請求執行此操作。它將通過套接字向 Go 服務發送一些數據，該服務隨后將相應的數據發送回套接字。去代碼Go 服務 go 看起來像這樣（簡化）：srv := new(service.App) // this would expose a Process methodrpc.Register(srv)listener, err := net.Listen("tcp", ":8080")if err != nil {    // handle error}for {    conn, err := listener.Accept()    if err != nil {        // handle error    }    go jsonrpc.ServeConn(conn)}請注意，我們使用 goroutine 為傳入連接提供服務，因此我們可以并發處理請求。紅寶石代碼下面是一段簡單的 Ruby 代碼片段，它演示了（理論上）我將數據發送到 Go 服務的方式：require "socket"require "json"socket = TCPSocket.new "localhost", "8080"b = {  :method => "App.Process",  :params => [{ :Config => JSON.generate({ :foo => :bar }) }],  :id     => "0"}socket.write(JSON.dump(b))response = JSON.load socket.readline我擔心的是：這會是一個安全的事件序列嗎？我不是在問這是否是“線程安全的”，因為我不擔心跨 go 例程操縱共享內存。我更關心我的 Ruby HTTP 服務是否會取回它期望的數據？如果我有兩個并行請求進入我的 HTTP 服務（或者 Ruby 應用程序托管在負載均衡器之后，因此HTTP 服務的不同實例正在處理多個請求），那么我可以讓實例 A 將消息 Foo 發送到 Go服務; 而實例 B 發送消息 Bar。Go 服務內部的業務邏輯將根據其輸入返回不同的響應，因此我想確保 Ruby 實例 A 為 Foo 返回正確的響應，而 B 為 Bar 返回正確的響應。我假設套接字連接更像是一個隊列，因為如果實例 A 先向 Go 服務發出請求，然后B 這樣做，但 B 無論出于何種原因響應更快，那么 Go 服務會將 B 的響應寫入套接字并且 Ruby 應用程序的實例 A 最終將讀取錯誤的套接字數據（這顯然只是一種可能的情況，因為我可能很幸運并且讓實例 B 在實例 A 之前讀取了套接字數據）。解決方案？我不確定這個問題是否有簡單的解決方案。除非我不使用 TCP 套接字或 RPC 而是依賴 Go 服務中的標準 HTTP。但我想要 TCP 的性能和更少的開銷。我擔心設計可能會變得更加復雜，因為可能必須實現一個外部隊列作為與 Ruby 服務同步響應的一種方式?？赡苁且驗槲业?Ruby 服務本質上是同步的（HTTP 響應/請求），所以我別無選擇，只能為 Go 服務切換到 HTTP。但是我想先與社區進行仔細檢查，以防萬一我遺漏了一些明顯的東西。