# Gateway API Policies DCE 5.0 cloud native gateway supports several API policies, including load balancing, timeout, retries, and blacklisting/whitelisting. This article demonstrates how to configure these policies and their specific effects using a real microservice application. !!! note - For detailed configuration steps and parameter explanations for each policy, refer to [API Policy Configuration](../gateway/api/api-policy.md). - This article focuses on showcasing the effects of each policy and may omit some configuration steps. ## Prerequisites - Prepare a demo service, such as `my-otel-demo-adservice`. - Create a [gateway](../gateway/index.md), [domain](../gateway/domain/index.md), and [API](../gateway/api/index.md). - Connect the demo service to the gateway as explained in [Connecting Services to the Gateway](gateway01.md). ## Load Balancing 1. Scale the demo service to multiple replicas for load balancing demonstration. 2. Configure the load balancing policy following the instructions in [Load Balancing](../gateway/api/api-policy.md#_2). 3. Write a script to record the traffic received by each service replica. ??? note "Click to view the script content" ```python import requests def lb_pod_count(): pod1_ip = "10.244.1.135" # IP address of the service replica's node pod2_ip = "10.244.2.207" # IP address of the service replica's node pod3_ip = "10.244.3.193" # IP address of the service replica's node pod1_count = 0 pod2_count = 0 pod3_count =0 host = "http://10.6.222.24:30040/ip" # Service access address headers = {"Host": "ad.service.virtualhost"} for i in range(300): res_ip = requests.get(host, headers=headers).text[11:] if res_ip == pod1_ip: pod1_count += 1 elif res_ip == pod2_ip: pod2_count += 1 elif res_ip == pod3_ip: pod3_count += 1 print("Traffic directed to %s: %d" %(pod1_ip,pod1_count)) print("Traffic directed to %s: %d" %(pod2_ip,pod2_count)) print("Traffic directed to %s: %d" %(pod3_ip,pod3_count)) if __name__ == '__main__': lb_pod_count() ``` 4. The effect of random load balancing is as follows. Each replica receives traffic randomly, resulting in some replicas being under more load. 5. The effect of round-robin load balancing is as follows. Each replica receives traffic in a round-robin fashion, resulting in a similar total traffic load for each replica. ## Rewrite Path 1. In the initial state, accessing the root path of the service returns the content as shown in the image. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw09.png) 2. Configure the path rewriting policy to change the access from the root path to the `/test2` endpoint. 3. The effect is shown in the image. From the returned content, it can be seen that the accessed endpoint has changed, and the returned data has also changed. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw14.png) ## Configure Timeout 1. Enable the timeout configuration and set it to consider the request as failed if the response exceeds 3 seconds. 2. Use the dedicated test endpoint `/timeout` to make the request respond within 1 second. The expectation is that the request will succeed. The image below shows a successful access, and the interface returns the set request time. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw16.png) 3. Use the dedicated test endpoint `/timeout` to make the request respond within 4 seconds. The expectation is that the request will fail. The image below shows a failed access, and the interface returns an upstream request timeout message. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw17.png) ## Retry Mechanism 1. Enable the retry configuration with a maximum of 6 retries when the request fails, and consider it a retry failure if the retry response time exceeds 1 second. 2. Use the dedicated test endpoint `/set-retry-count` to make the `/retry` endpoint of the service require 3 requests to succeed. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw19.png) Access the `retry` endpoint. With 6 retries, it is expected to succeed. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw20.png) 3. Use the dedicated test endpoint `/set-retry-count` to make the `/retry` endpoint of the service require 7 requests to succeed. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw21.png) Access the `retry` endpoint. With 6 retries, it is expected to succeed as well. Because the initial successful request plus the 6 retries after failure adds up to the required 7 requests. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw22.png) 4. Use the dedicated test endpoint `/set-retry-count` to make the `/retry` endpoint of the service require 8 requests to succeed. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw23.png) Access the `retry` endpoint. With 6 retries, the first attempt is expected to fail. Because the initial successful request plus the 6 retries after failure can only reach a maximum of 7 requests, which is not enough for the required 8 requests. However, manually accessing the endpoint again will show a successful access. At this point, the accumulated number of accesses has reached 8. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw24.png) ## Rewrite Request Header 1. Enable the request header rewriting policy to remove the `user-agent` (case-insensitive) header and add `demo-req` when making requests to the service. 2. Use Postman tool to view the request headers present in the initial state. It can be seen that `user-agent` exists, but `demo-req` is not present. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw28.png) 3. Use the dedicated test endpoint `/request-header` to check if the request includes the `user-agent` header. The returned value of `user-agent` is null, indicating that the header has been removed and the rewriting policy is effective. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw26.png) 4. Use the dedicated test endpoint `/request-header` to check if the request includes the `user-agent` header. The expected value is returned, indicating that the header has been added and the rewriting policy is effective. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw27.png) ## Rewrite Response Header 1. Enable the response header rewriting policy to remove the `x-envoy-upstream-service-time` (case-insensitive) response header and add `demo-res`. 2. Use Postman tool to view the response headers in the initial state. It can be seen that `x-envoy-upstream-service-time` exists, but `demo-res` is not present. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw30.png) 3. Access the service directly. The response headers do not include `x-envoy-upstream-service-time`, but `demo-res` is present, indicating that the rewriting policy is effective. ![rewrite](https://docs.daocloud.io/daocloud-docs-images/docs/zh/docs/skoala/images/br-gw31.png) ## WebSocket 1. Write a script to test WebSocket connections. ??? note "Click to view the script" ```html