Control-plane assembly

The real pole-control-plane runtime structure across bootstrap, API plugins, domain servers, caches, and storage.

pole-control-plane is not a single HTTP CRUD service. Startup enters bootstrap.Start from cmd/start.go, then bootstrap/server.go assembles storage, cache, authorization, namespaces, discovery, governance, configuration, operations, and API servers in dependency order.

Protocol adapters can grow horizontally, but business capabilities reuse shared service.DiscoverServer, goverrule.GoverRuleServer, config.ConfigCenterServer, admin.AdminOperateServer, and cache.CacheManager.

Startup order

bootstrap.StartComponents matters:

Obtain the store from storeapi.GetStore().
cache.Initialize creates CacheManager and registers service, instance, governance, config, user, policy, MCP server, and A2A agent caches.
auth.Initialize prepares user and strategy services required by auth interceptors.
namespace.Initialize builds the namespace service.
StartDiscoverComponents initializes discovery, batch controllers, health checks, and service.Initialize.
StartGoverRuleComponents initializes governance servers.
StartConfigCenterComponents initializes the configuration center.
admin.Initialize assembles operations modules.
cache.Run starts warm-up and periodic refresh.

Business servers and cache objects are fully assembled before refresh loops start, so API servers serve already-initialized shared objects.

control plane startup

API servers are plugin slots

Slots under apis/apiserver register HTTP, discovery gRPC, xDS v3, Nacos, Apollo, and Eureka entry points. bootstrap.StartServers walks apiserver.Config, initializes each slot, and runs listeners in goroutines.

HTTP Run pulls already-initialized domain servers (admin, namespace, service, goverrule, auth, healthcheck). HTTP is transport and routing—not an independent business state owner.

api shared servers

Domain interceptors

Discovery and governance share the same pattern:

RegisterServerProxy registers proxy factories.
GetChainOrder() returns ["auth", "paramcheck"].
InitServer wraps the concrete server in that order.

Authorization and parameter checks stay out of every protocol handler and remain consistent across HTTP, gRPC, and xDS.

interceptor chain

Module boundaries

Layer	Main entry	Responsibility
Bootstrap	`bootstrap/server.go`	Dependency-ordered assembly and lifecycle.
Protocols	`plugin/apiserver/*`	HTTP, gRPC, xDS, Nacos, Apollo, Eureka, MCP/A2A adapters.
Discovery	`pkg/service`	Services, instances, contracts, reporting, discovery responses.
Governance	`pkg/goverrule`	Nine governance families and releases.
Configuration	`pkg/config`	Groups, files, publishing, protocol adapters.
Authorization	`apis/access_control/auth`, `plugin/access_control/auth`	Users, policies, resource checks.
Cache	`pkg/cache`	Incremental views, active releases, AI registries.
Storage	`plugin/store/mysql`	CRUD, releases, incremental queries, transactions.

Design implications

Do not draw the control plane as “one HTTP API in front of a database”.
API servers adapt protocols; domain servers own semantics; interceptors enforce cross-cutting rules; CacheManager serves low-latency reads; Store is the source of truth.
AI Native registries join the same cache and HTTP assembly path—they are not a side UI.

See also deployment and ports and Control Plane.