Microservices Engine:Microservices Namespace Management

What is a microservices namespace?

Users typically maintain separate production, staging, and development environments, each with isolated resources. In MSE microservices governance, governance configurations for applications in different microservices namespaces are independent and strictly isolated. Configurations do not apply across namespaces. Therefore, the same microservice application deployed in different environments can have its own independent governance configuration. In such cases, use microservices namespaces to isolate applications across environments.

A microservices namespace is conceptually independent from a Kubernetes namespace. When onboarding an application, specify the MSE namespace by setting the label mseNamespace: ${namespace name} on the pod or its corresponding Kubernetes namespace.

What is an application in MSE microservices governance?

A microservice application typically refers to a Java process that provides a group of microservices. It independently handles cohesive microservice business logic and has dedicated O&M and developer personnel.

In deployment terms, one MSE microservices governance application corresponds to a group of deployments.

When onboarding an application, if you add the labels mseNamespace: prod and msePilotCreateAppName: ${application name} to the pod, the application joins the corresponding application under the prod microservices namespace. The application name can be up to 63 characters long.

Scenarios

• Environment management: Isolate environments and their resources by distinguishing production (Prod), staging (Test), and development (Dev) environments.

• Resource isolation: Governance configurations for applications in different microservices namespaces are strictly isolated and do not take effect across namespaces.

• Example 1:

  In practice, onboard all staging environment applications into the microservices namespace test (for example, test/example-app) and all production environment applications into the microservices namespace prod (for example, prod/example-app). When using MSE microservices governance features, configure and validate them on the test/example-app application first. After validation succeeds, apply the same configuration to the prod/example-app application.

  Note

  In different microservices namespaces, use separate databases, message queue clusters, Kubernetes clusters, and Nacos registry and configuration center instances. This prevents changes in the staging environment from affecting the production environment and ensures stability.

• Example 2:

  You have three environments—development, staging, and production—in the same VPC. Create a microservices namespace for each environment (such as Dev, Test, and Prod). Deploy applications in separate clusters within these namespaces. Applications in different microservices namespaces remain isolated from each other.

Microservices namespace versioning

Microservices governance comes in Professional Edition and Enterprise Edition, which differ in features and pricing. For Enterprise Edition users, not all applications require runtime protection capabilities (for example, in Dev environments). You can downgrade specific namespaces to Professional Edition as needed, while keeping others at the default Enterprise Edition (for example, Prod environments). This approach meets the diverse requirements for onboarding different environments into MSE.

• For billing details of microservices governance, see Microservices governance billing overview.

Using microservices namespaces

What to do next

• Onboard ACK and ACS microservice applications to MSE Governance Center (Java)

• Quickly experience service governance capabilities in 15 minutes (Java)