Service Development Guide
This document describes some matters to be aware of when developing TCBR services.
Programming Language Support
You can use any language and any framework to write applications, or even directly use public container images.
The Quick Start Guide provides samples in multiple mainstream languages, but languages not currently covered in the samples are also supported.
Code Requirements
Listening for HTTP Requests
The service must listen for HTTP requests. You can configure the port to which requests are sent and correctly specify the listening port when deploying the service. Inside TCBR container instances, the PORT environment variable always reflects the port to which requests are sent. Your code should check for the presence of this PORT environment variable and, if present, listen on the port it specifies to maximize portability.
Stateless Services
The service should be stateless and cannot depend on a permanent local state. This enables automatic scale-out and scale-in.
A stateless service refers to processing a single request, independent of other requests. All information required to process one request should be included in this request or obtained from external sources such as a database or file storage. The instance itself does not store any information.
A stateful service, on the other hand, saves some data in itself, and sequential requests are related.
Avoiding Background Activities
After the service has processed a request, the corresponding container instance can no longer access the CPU. Therefore, do not start background threads or processes outside the scope of the request handler in your code, and ensure all asynchronous operations are completed before sending the response. Forcibly running background threads may cause exceptions.
If you suspect there may be non-obvious background activities in your service, you can search the log for any content recorded after HTTP request entries.
Containerizing Code
To deploy a service based on containers, you need to provide a container image or provide code for TCBR to build the image online. A container image is an encapsulation format including your code, software packages, all required binary dependencies, the operating system to be used, and any other content needed to run the service. Once the image is built, all the above information is solidified. TCBR will not be aware of the specific content of the image, and the image content will not change while the instance is running.
If you need to modify any content, you need to rebuild the image.
Normally, you can use a file named Dockerfile to declare how to build the image. The examples provided in the quick start documentation also include Dockerfile references for multiple mainstream languages.
Dockerfile Background: Refer to the official Dockerfile documentation for syntax, and see tips in Best practices for writing Dockerfiles on how to put these syntax elements together.
A Dockerfile typically starts from a base image (for example, FROM golang:1.11). You can find base images maintained by operating system and language authors on Docker Hub.
Using Dependencies with Caution
If you use a dynamic language with dependency libraries, such as importing Node.js modules, loading these modules during cold startup will increase latency. You can reduce startup latency in the following ways:
- Minimize the number and size of dependencies to build a streamlined service.
- Lazy load infrequently used code (if your language supports this).
- Use code loading optimization techniques.
Control Image Size
Large images have the following impacts:
- Increase security vulnerabilities
- Reduce the image build speed, increase build duration, and even cause build timeouts.
- Reduce service deployment speed.
The image size does not affect request processing time, but an oversized image consumes more building time. A prolonged deployment time also consumes more CPU and memory resources, resulting in higher fees.
For how to optimize images, please refer to: Optimizing Container Images