Gaode's Serverless/FaaS Platform: Architecture, Implementation, and Business Impact

Overview Gaode has been building a Serverless (FaaS) platform for several years. The platform now handles peak traffic of over 100,000 QPS, making Gaode the largest Serverless consumer within Alibaba Group. This article shares the motivations, technical solutions, current progress, and future plans.

1. Why Gaode Adopted Serverless

Gaode launched a "client‑to‑cloud" project to improve iteration speed of client‑side features. Previously, all business logic lived on the device, requiring a full client release for any change. By moving mutable logic to the cloud, new product requirements can be developed and deployed without a client version update, greatly accelerating the development cycle.

The shift also required a unified development model where the same codebase can run both on the client and on the server. To achieve this, Gaode extended its existing xbus framework with an xbus‑cloud component, enabling a "one code, two runtimes" approach.

Gaode’s three client platforms (iOS, Android, and vehicle‑Linux) use C++ for core map functions and Node.js for higher‑level services. While Node.js FaaS could reuse Alibaba’s existing Taobao Node.js Runtime, there was no C++ FaaS solution, prompting the creation of a custom C++ FaaS runtime.

1.1 Key Practice: Interface Abstraction Between Client and FaaS

The success of moving logic to FaaS hinges on a well‑defined API contract between the client and the FaaS service. A stable API reduces maintenance overhead and enables product iterations that only modify the FaaS side.

1.2 BFF Layer Development

Gaode’s navigation features are largely read‑only (routing, traffic, ETA). The stable backend services are ideal for a Backend‑For‑Frontend (BFF) layer built on FaaS, which encapsulates data aggregation and business logic, allowing rapid front‑end changes.

1.3 Serverless as a High‑Level Language for the Cloud Era

Traditional distributed systems require developers to manage clustering, load balancing, and fault tolerance. Serverless abstracts these complexities, letting developers focus on business logic—essentially treating the cloud as a high‑level programming language.

1.4 Go‑FaaS Complementing the Go Ecosystem

Gaode also built a Go FaaS runtime to support high‑QPS Go services, completing the language coverage (C++, Go, Node.js) for backend and FaaS development.

2. Technical Solution – Building on Existing Alibaba Infrastructure

2.1 Overall Architecture

The solution consists of three layers: development, runtime, and operations. It integrates with Alibaba Cloud Function Compute (FC), the internal ASI scheduler (K8S + Sigma), and the Aone CI/CD platform.

2.1.1 Runtime Layer

Incoming traffic passes through the gateway to the FC API server, which forwards requests to the C++/Go FaaS runtimes. Each runtime runs inside a container together with side‑car containers for logging, monitoring, and Dapr for middleware access. Autoscaling manages instance scaling based on request concurrency or CPU usage, with pre‑warmed instances to avoid cold‑start latency.

2.1.2 Development Layer

To simplify C++ development, a scaffolding tool generates a sample project and installs required dependencies. A boot module enables local debugging of the runtime. The Aone platform provides one‑click example generation, custom build images, and seamless publishing of C++ and Go FaaS functions.

2.1.3 Operations Layer

Runtime containers embed logging agents that forward logs to Alibaba’s EagleEye and Sunfire monitoring systems. Metrics are exported for tracing, and alerts are integrated with the GOC alarm platform.

2.2 C++/Go FaaS Runtime Architecture

The runtime consists of a starter (server entry), a function configuration module, service layers implementing SDK‑defined middleware calls (RSocket and Dapr), and a metrics module for tracing.

2.2.1 Dapr Integration

Dapr is introduced to decentralize outgoing traffic. The runtime can call middleware via Dapr (gRPC) or fall back to RSocket if Dapr is unavailable, without any changes required from the function developer.

3. Business Integration

Functions are onboarded through Aone with standardized checklists ensuring monitoring, gray‑release, and rollback capabilities. The platform supports automatic degradation to local execution if a FaaS call fails.

4. Current Status

4.1 Platform Maturity

C++/Go FaaS runtimes are production‑ready (v1.0) and integrated with FC‑Ginkgo, CSE, and Aone.

Extensive stability, performance, and compiler optimizations have been applied.

Observability via EagleEye and Sunfire is complete.

Pool‑based runtime images enable second‑level scaling, reducing instance start time from minutes to seconds.

4.2 Business Adoption

Numerous Gaode services (e.g., long‑distance weather, route tips, travel footprints) are already powered by C++ or Go FaaS, handling daily peaks well above 100k QPS.

4.3 Benefits

Development efficiency: The unified client‑cloud component removes the need for client releases, accelerating iteration.

Operations efficiency: Automatic elastic scaling handles travel‑peak traffic without manual capacity planning.

Cost reduction: Night‑time auto‑scaling down lowers server costs.

5. Future Plans

Optimize FC in‑process function execution and open the runtimes to public cloud.

Fully roll out Dapr for middleware calls.

Implement chaos engineering for FaaS resilience.

Integrate edge computing to further reduce latency.

Gaode invites developers interested in Serverless, cloud‑native, or Go development to join the team (resume to [email protected]).

Free e‑book download: "Gaode Technology 2020 Collection" covering front‑end, algorithms, architecture, automotive engineering, and more.