You can implement backend web services by writing SCF functions and providing services through CLB, which will pass the request content as parameters to the function and return the result from the function back to the requester as the response.
Characteristics of CLB triggers:
Push model
After a CLB trigger receives a request from CLB, if CLB is configured to connect with a function on the backend, the function will be triggered for execution, and CLB will send the information of the request as event input parameters to the triggered function, including the specific method how the request is received as well as the path, header, and query of the request.
Sync invocation
A CLB trigger invokes functions synchronously. For more information on invocation types, please see Invocation Types. Note:
CLB accounts are divided into standard accounts and traditional accounts. Traditional accounts cannot be bound to SCF. We recommend you upgrade them to standard accounts.
CLB Trigger Configuration
CLB triggers can be configured in either the SCF or CLB console. When configuring routing rules in the CLB console, you can choose Cloud Function as the backend and select functions in the same region as the CLB instance. In the CLB console, you can also configure and manage advanced CLB capabilities, such as WAF protection, SNI multi-domain certificate, and ENI.
CLB Trigger Binding Limits
One CLB path rule can be bound to only one function, but one function can be bound to multiple CLB rules as the backend. Rules with the same path, listener, and host are regarded as the same rule and cannot be bound repeatedly.
Currently, CLB triggers can only be bound to functions in the same region; for example, a function created in the Guangzhou region can only be bound to and triggered by CLB rules created in the Guangzhou region.
Request and Response
Request method refers to the method to process request sent from CLB to SCF, and response method refers to the method to process the returned value sent from SCF to CLB. Both request and response methods are automatically processed by the CLB trigger. When it triggers the function, data structures must be returned in the request method.
Note:
X-Vip, X-Vport, X-Uri, X-Method, and X-Real-Port fields must be customized in the CLB console before they can be transferred. For custom configurations, see Layer-7 Custom Configuration.Event message structure of integration request for CLB trigger
When a CLB trigger receives a request, event data will be sent to the bound function in JSON format as shown below.
Note:
In the CLB trigger scenario, all requests and responses need to be transferred in JSON. For images, files, and other data, as directly passing in JSON content will cause invisible characters to be lost, Base64 encoding is required as detailed below:
If the Content-type is text/*, application/json, application/javascript, or application/xml, CLB will not transcode the body content.
For all other types, CLB will Base64-encode them first and then forward them.
{
"headers": {
"Content-type": "application/json",
"Host": "test.clb-scf.com",
"User-Agent": "Chrome",
"X-Stgw-Time": "1591692977.774",
"X-Client-Proto": "http",
"X-Forwarded-Proto": "http",
"X-Client-Proto-Ver": "HTTP/1.1",
"X-Real-IP": "9.43.175.219",
"X-Forwarded-For": "9.43.175.xx"
"X-Vip": "121.23.21.xx",
"X-Vport": "xx",
"X-Uri": "/scf_location",
"X-Method": "POST"
"X-Real-Port": "44347",
},
"payload": {
"key1": "123",
"key2": "abc"
},
}
The data structures are as detailed below:
|
| |
| scheme structure of the request
|
| |
| |
| |
| Records the Path parameters configured in CLB and their actual values (optional custom configuration of CLB) |
| CLB VIP address (optional custom configuration of CLB) |
| CLB Vport (optional custom configuration of CLB) |
| CLB request path (optional custom configuration of CLB) |
| CLB request method (optional custom configuration of CLB) |
Note:
The content may be increased significantly during CLB iteration. At present, it is guaranteed that the content of the data structure will only be increased but not reduced, so that the existing structure will not be compromised.
Parameters in real requests may appear in multiple locations and can be selected based on your business needs.
Integration response
Integration response means that CLB parses the returned content of the function and constructs an HTTP response based on the parsed content. With the aid of integration response, you can control the status code, headers, and body content of the response by using code and implement response to content in custom formats, such as XML, HTML, JSON, and even JS. When using integration response, data structures need to be returned in the returned data structures of integration response for CLB trigger before they can be successfully parsed; otherwise, the error message {"errno":403,"error":"Analyse scf response failed."} will appear. Returned data structures of integration response for CLB trigger
If integration response is set for CLB, data needs to be returned in the following structures:
{
"isBase64Encoded": false,
"statusCode": 200,
"headers": {"Content-Type":"text/html"},
"body": "<html><body><h1>Heading</h1><p>Paragraph.</p></body></html>"
}
The data structures are as detailed below:
|
| This indicates whether the content in the body is Base64-encoded binary. It should be true or false in JSON format. |
| HTTP return code, which should be an integer value. |
| HTTP return header, which should contain multiple key-value or key:[value,value] objects. Both key and value should be strings. |
| |
If you need to return multiple headers with the same key, you can use a string array to describe different values; for example:
{
"isBase64Encoded": false,
"statusCode": 200,
"headers": {"Content-Type":"text/html","Key":["value1","value2","value3"]},
"body": "<html><body><h1>Heading</h1><p>Paragraph.</p></body></html>"
}