How Standardized Service Governance Tackles Multi‑Stack and Heterogeneous Infrastructure Challenges

Background

At QCon Global Software Development Conference, the need for separating infrastructure from business logic in heterogeneous technology stacks was discussed. The talk introduced a standardized service‑governance approach for heterogeneous stacks and infrastructures.

Enterprise Service Architecture

Modern enterprise applications often consist of a web front‑end and multiple back‑end services. Complex systems (e.g., AI platforms) require different languages and frameworks for modules such as web services, business logic, foundational services (storage, cache, logging) and AI‑specific services. Consequently, heterogeneous technology stacks are common.

Infrastructure may be container‑based for new workloads, while legacy or performance‑critical services (e.g., audio‑video) remain on virtual machines, resulting in a mixed environment of containers and VMs.

Challenges of Service Governance

Service‑discovery model mismatch : Different PaaS platforms expose distinct discovery mechanisms (Kubernetes uses etcd + coredns, custom PaaS defines its own model). Global DNS introduces cache latency; load‑balancer + global DNS prevents client‑side load balancing; external registries require conversion logic.

Governance rule model mismatch : Circuit‑breaking, rate‑limiting and other policies are implemented differently across frameworks (full cut‑off vs. elastic reduction), making unified rule enforcement difficult.

Standardized Service‑Governance Solution

A neutral, universal service‑governance standard is proposed, consisting of:

A set of standardized APIs and functional definitions covering service management, traffic management, fault tolerance, access control and observability.

A reference implementation that provides the data‑plane for those APIs, eliminating duplicate development.

Three‑Layer Architecture

Control Plane (Governance Layer) : Distributes governance rules, stores configuration data and provides global functions such as service registration, traffic routing, fault‑tolerance policies, access‑control policies and observability metrics.

Data Plane : Implements the standardized APIs via multi‑language SDKs, a Java Agent (no sidecar required), and sidecar proxies for environments that need an external data‑plane.

Service Framework Layer : Applications integrate the data‑plane components (SDK/Agent/Sidecar) or directly implement the standardized interfaces.

Default Implementation – PolarisMesh

PolarisMesh ( https://github.com/polarismesh) is an open‑source, production‑grade service‑governance component from Tencent. It provides a unified control plane and data plane that work across VMs, containers and bare‑metal environments. The data plane offers three integration modes:

SDK mode – language‑specific libraries (Go, Java, C++, etc.) that call the control plane directly.

Java Agent – bytecode instrumentation that injects governance logic without a sidecar.

Sidecar – a proxy process (compatible with Envoy) for scenarios that require an external data‑plane.

Comparison with XDS

While XDS (Envoy‑centric) splits governance into LDS, CDS, RDS, EDS and provides limited feature coverage, PolarisMesh adopts a service‑centric model that:

Delivers rules on demand (only when a feature is used).

Supports richer capabilities such as gray‑release routing, distributed rate limiting and fine‑grained circuit breaking.

Provides multi‑language SDKs and sidecar/Agent options.

Maintains compatibility with XDS via an adapter layer.

Ecosystem Integration

PolarisMesh has been integrated with several mainstream frameworks, allowing developers to adopt the standard with minimal code changes:

Spring Cloud – service discovery, configuration, circuit breaking, traffic management and observability ( https://github.com/Tencent/spring-cloud-tencent)

cloudwego/kitex – registration, discovery, circuit breaking, traffic management ( https://github.com/kitex-contrib/polaris)

go‑kratos – registration, configuration, traffic management (

https://github.com/go-kratos/kratos/tree/main/contrib/polaris

)

dubbo‑go – registration, discovery, routing, rate limiting (multiple repositories, e.g.,

https://github.com/apache/dubbo-go/tree/master/registry/polaris

)

Future Roadmap

Extend rule sets with observability extensions and atomic capabilities for scenarios such as gray releases.

Add language support for Node.js, .NET and other runtimes.

Deepen collaboration with framework communities to broaden ecosystem coverage.

Conclusion

The service‑governance standard (v1.0.0) is released. Users are encouraged to experiment with PolarisMesh and the integrated ecosystem components.

Specification repository: https://github.com/nextarch/SIG-Microservice PolarisMesh repository:

https://github.com/polarismesh