The purpose of this design document is to outline the comprehensive design of the API Gateway, implemented using CloudWeGo Projects. This document aims to provide a detailed understanding of the architecture, components, and implementation plan for the API Gateway project.
The primary objectives of the API Gateway project include:
Accepting HTTP requests with JSON-encoded bodies: The API Gateway will be responsible for accepting incoming HTTP requests from clients. These requests will include JSON-encoded bodies containing the necessary data for processing.
Using the Generic-Call feature in Kitex: The API Gateway will leverage the Generic-Call feature provided by the Kitex framework. This feature allows translating JSON requests received by the API Gateway into the Thrift binary format. This translation enables efficient communication and interoperability with the backend RPC servers.
Integrating a load balancing mechanism: To ensure optimal resource utilization and high availability, a load balancing mechanism will be integrated into the API Gateway. This mechanism will distribute incoming requests among multiple backend RPC servers, effectively managing the workload and preventing any single server from becoming a bottleneck.
Integrating a service registry and discovery mechanism: The API Gateway and RPC servers will be integrated with a service registry and discovery mechanism. This integration will enable dynamic service registration and discovery, allowing the API Gateway to locate and communicate with the available RPC servers efficiently.
Develop backend RPC servers using Kitex: This will allow us to test API Gateway's ability to handle and process requests, validate the integration with the backend services, and assess the overall performance and responsiveness of the system. This testing phase will help identify any potential issues or bottlenecks early on and allow for necessary improvements and optimizations to be made.
The API Gateway accepts JSON-encoded HTTP requests, translates them into Thrift binary format using Kitex's Generic-Call feature, and forwards them to backend RPC servers, with the help of the service registry that enables service discovery. The load balancing mechanism ensures an even distribution of requests.
Hertz is a Golang HTTP framework. It serves as the entry of the API Gateway, that accepts JSON-encoded HTTP requests.
Kitex is a high-performance, scalable RPC framework that supports Thrift-based communication. The API Gateway will leverage:
Kitex's Generic-Call feature for JSON to Thrift translation. Kitex’s Round Robin Load Balancing feature to distribute requests amongst backend servers. Kitex’s Service Registry feature to seamlessly integrate new servers into the network using Nacos
The interaction flow within the system is as follows:
-
An HTTP request with a JSON-encoded body is received by the API Gateway.
-
The API Gateway uses the Generic-Call feature of Kitex to translate the JSON request into Thrift binary format.
-
The API Gateway consults the load balancer to determine the appropriate backend RPC server to forward the request.
-
The load balancer selects a backend server based on the configured load balancing strategy and forwards the request to that server.
-
The backend RPC server receives the request, processes it, and sends the response back to the API Gateway.
-
The API Gateway translates the response from Thrift binary format to JSON and sends it back as an HTTP response to the client.
- Install Golang https://go.dev/doc/install
- Install Hertz https://www.cloudwego.io/docs/hertz/getting-started/
- Install Kitex https://www.cloudwego.io/docs/kitex/getting-started/
- Install Nacos https://nacos.io/en-us/docs/quick-start.html
- Install hz run
go install github.com/cloudwego/hertz/cmd/[email protected]
- Open a terminal window and navigate to
hertz-server
directory go run .
to start the server onlocalhost:8080
- Open a terminal window in the directory where Nacos was installed
- Navigate to the
/nacos/bin
directory ./startup.cmd -m standalone
to start the server onlocalhost:8848
- Open a terminal window and navigate to the
kitex_service1
directory go run .
to start the server onlocalhost:8888
- Open a terminal window and navigate to the
kitex_service2
directory go run .
to start the server onlocalhost:8885
- Send a GET request with the following command
curl -X GET localhost:8080/echo/query --json <JSON HERE>
- JSON should have
"Message" : "<string>"
and"Flag" : <integer>
, following the structure in thehertz.thrift
idl - Ensure that your JSON request utilises
'{"<key>" : "<element>"}'
structure. Ex:'{"Message" : "Hallo"}'
- Alternatively you can run the following command in the project directory:
curl -X GET localhost:8080/echo/query --json "@message.json"
- Additionally, you can select which service you want to process the data by specifying a query
service=X
, whereX
is either1
or2
. You can also select which method you want to process the data by specifying a querymethod=Y
whereY
is1
or2
forService 1
butY
is1
forService 2
- Authentication is required for
Service 2
, a querytoken=token
must be passed in the URL. For example, you can run the following command in the project directory:curl -X GET localhost:8080/echo/query?service=2&method=1&token=token --json "@message.json"
- Set up all the servers as seen in Step 3
- Navigate to the
tests
directory go test -v -benchtime 20s -bench .
to run all tests in a verbose format NOTE: As there are nearly 200 individual tests and benchmarking, there will be some time delay for the tests to complete
The design document, which includes the projected timeline at the end, can be accessed here : https://docs.google.com/document/d/19cSJfAP8_TKRUjOMC_lAO5g-itLNmyKLcib8Qp2RyqQ/edit