The ngx_grpc module doesn’t support the http/2 connection multiplex, and it’s not interactive unless we use the subrequest.
Yong Qian <nic...@apache.org>于2022年7月7日 周四17:44写道： > Hi, > > What is the difference between this new ngx-grpc-client-module and the > current ngx_http_grpc_module? Can't I use the current > ngx_http_grpc_module with some minor changes to achieve a similar effect? > > On 2022/07/07 08:08:41 Zexuan Luo wrote: > > 1. Background > > > > 1.1 Problem to be solved > > > > More and more cloud-native applications are adopting gRPC as their API > > standard, such as etcd, Dapr, and Envoy. In some cases, only the gRPC > > API is available. Apache APISIX currently does not support access to > > the API exposed by the gRPC service, and can only go through the HTTP > > interface or develop a separate service to act as a proxy. > > > > 1.2 The benefits of solving this problem > > > > 1. Allow user to connect with their own gRPC services. > > 2. Embrace the ecosystem of Envoy and Dapr > > 3. Show our leadership of the popular technology and provide > > something the rival is missing. > > > > 2. How to solve the problem > > > > We will create a new Nginx module called ngx-grpc-client-module so > > that we can interact with Nginx's event system. We choose to use a > > mature gRPC implementation and write Lua/C binding for it. > > > > Hence we study multiple gRPC clients: > > > > Language: C++ > > Repo: https://github.com/grpc/grpc > > > > Pro: 1. High performance > > 2. Widely used > > > > Con: 1. Require nearly 2GB dependencies > > 2. Not easy to compile unless you are a C++ developer > > > > Language: Go > > Repo: https://github.com/grpc/grpc-go > > > > Pro: 1. Written in pure Go > > 2. Widely used > > 3. Familiar to me > > > > Con: 1. Low performance (We also study connect-go, but it has > > worse performance) > > > > Language: Rust > > Repo: https://github.com/hyperium/tonic > > > > Pro: 1. Written in pure Rust > > 2. High performance > > > > Con: 1. Not familiar to me so I can't make sure it is mature > enough > > > > > > If APISIX is a company-inside project, I will choose to use C++. > > However, APISIX is an open source project, and it is important to > > lower the threshold for participation. People used to complain it is > > hard to build APISIX from source, so we can't choose C++. > > > > We can use Go first and switch to Rust in the future if the > > performance is critical. > > Changing the underneath gRPC implementation won't break the Lua API > > provided by this module. > > > > The process of unary request can be done in the steps below: > > > > 1. Encode the proto message and start gRPC call > > 2. Create task ctx, call the Go code and suspend Lua thread > > 3. Execute gRPC code, put the task ctx and final result to the task done > queue > > 4. Wait on the task done queue > > 5. Remove the data from task done queue > > 6. Add the task ctx to Nginx's posted event queue and re-wait on the > > task done queue > > 7. Resume Lua thread > > 8. Finish the gRPC call and decode proto message > > > > Step 1/8 are done in the Lua. > > Step 2/4/6/7 are done in the C code. > > Step 3/5 are done in the Go (or other gRPC implementation) > > > > Client / Server stream requests can be considered as one initial call > > plus several unary read/write operations. > > > -- Best regards Chao Zhang https://github.com/tokers
