...
When http server receives a request, it converts the request to corresponding gRPC request, and then reuse the gRPC handling procedure to finish serving the request.
As we can see from the milvus v2 architecture, all the gRPC requests first go into the Access Layer, which is the milvus-proxy service, where the requests are then propagated to other funtional services of milvus. So that's where we should put our web server.
Let's take a close look inside the milvus-proxy
Above is the dataflow of milvus-proxy while receiving requests, modules left of the green dotted line is inside milvus-proxy
- The gRPC call received by gRPC server is decoded into a req struct which is defined in protobuf
- The corresponding method handler is called with the req struct, where the req body is wrapped as a task.
- The task is then put into taskScheduler's taskQueues by its request type as DDL, DML or DQL (we don't have DCL for now). For example, the CreateCollection task goes into the DML queue.
- The task is then dequeued by taskScheduler. Some "pre-execution" process will be done, such as request validations, assign some default values and etc.
- The request is then propagated to other components of milvus.
So the best way to reuse code is as below:
We integrate these green colored modules to milvus-proxy, so that it can handle http calls.
After the http request parsed, it's translated into the same req struct as we mentioned above, and the rest things can be done by the gRPC handlers which were already implemented.
Test Plan(required)
- unit test with the go `httptest` package: example
...