Polaris Service Discovery and Governance Platform

repository·main·Indexed 25 days ago

https://github.com/polarismesh/polaris

A comprehensive service discovery and governance platform for microservices providing service management, traffic control, fault tolerance, and configuration management. Polaris supports multiple integration modes, including multi-language SDKs (Java, Go, C/C++, PHP, Lua), framework integrations (Spring Cloud, Spring Boot, Dubbo, gRPC), and Kubernetes-native options via Polaris Controller and Sidecar.

Tokens
18.4K
Snippets
18
Records
141
Agent score
82%

What's inside Polaris

  1. Overview of Polaris Service Discovery and Governance

    main

    Polaris is a multi-language and multi-framework service discovery and governance platform designed for distributed and microservice architectures. It addresses service management, traffic management, fault tolerance, configuration management, and observability.

    Core Capabilities

    • Service Management: Service registration, service discovery, and health checks.
    • Traffic Control: Customizable traffic routing, load balancing, rate limiting, and access control.
    • Fault Tolerance: Service and interface circuit breaking/degradation, and instance circuit breaking/switching.
    • Configuration Management: Version management, grayscale release, and dynamic updates.

    Key Features

    • Provides a one-stop platform covering registry, service mesh, and configuration center capabilities.
    • Supports multiple data plane modes: SDKs, development frameworks, Java agents, and sidecars.
    • Compatible with major frameworks like Spring Cloud, Dubbo, and gRPC.
    • Supports K8s service registration and sidecar automatic injection for Proxy service meshes.
  2. What is the timewheel component?

    main

    The timewheel is a thread-safe, multi-layer time wheel implementation customized for heartbeat reporting. It is designed for high performance by simplifying functionality, utilizing linked lists and a ticker for implementation.

    Key Characteristics:

    • Thread-safe: Safe for concurrent use across multiple goroutines.
    • Simplified Model: It only supports insertion operations. Once a task is inserted, it must be executed (it does not support task cancellation or rescheduling in this simplified version).
    • High Performance: Optimized for low-latency task insertion, even under high concurrency.
  3. Generate cache mocks using mockgen

    main

    To generate mock implementations for the cache interfaces defined in api/types.go, use the mockgen tool. This is useful for unit testing components that depend on the Polaris cache layer.

    Run the following command to generate the cache_mock.go file in the mock/ directory under the mock package:

    mockgen -source=api/types.go -destination=mock/cache_mock.go -package=mock
  4. Choose a Polaris Data Plane mode for service development

    main

    Polaris offers several ways to integrate governance capabilities into your services depending on your technology stack and requirements:

    1. Multi-language SDKs

    Directly call Polaris client APIs using language-specific SDKs:

    • Java: polaris-java
    • Go: polaris-go
    • C/C++: polaris-cpp
    • PHP: polaris-php
    • Lua: polaris-lua

    2. Integrated Frameworks (Java)

    Use frameworks that have the Polaris Java SDK pre-integrated:

    • Spring Cloud: via spring-cloud-tencent
    • Spring Boot: via spring-boot-polaris
    • Dubbo-java: Supports registry/discovery, routing/load balancing, and circuit breaking/rate limiting.
    • gRPC-java: via grpc-java-polaris

    3. Integrated Frameworks (Go)

    Use frameworks that have the Polaris Go SDK pre-integrated:

    • Dubbo-go: Supports registry/discovery, routing, and circuit breaking/rate limiting.
    • gRPC-go: via grpc-go-polaris

    4. K8s and Sidecar Mode

    For service mesh architectures in Kubernetes:

    • Polaris Controller: For K8s service registration.
    • Polaris Sidecar: For automatic sidecar injection.
  5. Generate mock implementations for Auth APIs

    main

    To generate mock implementations for the Auth APIs, use the mockgen tool. This is useful for testing components that depend on the Auth service without requiring a live service instance.

    Run the following command to generate the mock file from the api.go source file:

    mockgen -source=api.go -destination=./mock/api_mock.go -package=mock
  6. Choose a data plane mode for service development

    main

    Polaris offers multiple ways to integrate governance capabilities into your services depending on your language and architecture requirements.

    1. Multi-language SDKs

    Call the Polaris Client API directly using language-specific SDKs:

    2. Framework Integrations (Java)

    Use frameworks that have already integrated the Polaris Java SDK:

    3. Framework Integrations (Go)

    Use frameworks that have already integrated the Polaris Go SDK:

    4. Kubernetes and Sidecar

    For proxy service mesh or K8s-native environments:

  7. Generate mock files for the Store API

    main

    To generate mock implementations of the Store API interfaces for testing purposes, use the mockgen tool. This must be executed from the ./store directory.

    Run the following commands to generate the mocks for the main API and the MySQL admin implementation:

    mockgen -source=api.go -aux_files github.com/polarismesh/polaris/store=config_file_api.go,github.com/polarismesh/polaris/store=discover_api.go,github.com/polarismesh/polaris/store=auth_api.go,github.com/polarismesh/polaris/store=admin_api.go -destination=mock/api_mock.go -package=mock
    
    mockgen -source=mysql/admin.go -destination=mock/admin_mock.go -package=mock
  8. How ClientCache manages updates and events

    main

    The ClientCache maintains an in-memory map of clients and synchronizes it with a store.Store.

    Update Lifecycle:

    1. Update() is called.
    2. realUpdate() fetches new/changed data from the storage using GetMoreClients.
    3. setClients() processes the fetched data:
      • New/Modified Clients: Added to the map and an eventhub.EventCreated or eventhub.EventUpdated is published to eventhub.CacheClientEventTopic.
      • Invalid/Deleted Clients: Removed from the map and an eventhub.EventDeleted is published to eventhub.CacheClientEventTopic.

    This mechanism ensures that the local cache is a consistent view of the storage while providing real-time notifications via the eventhub for changes.

  9. How batch registration and deregistration work

    main

    The ClientCtrl uses a producer-consumer model to optimize storage writes:

    1. Queueing: Individual requests are sent to a queue.
    2. Batch Triggering: A batch is triggered when either the MaxBatchCount is reached or the WaitTime (defined in CtrlConfig.WaitTime) expires.
    3. Worker Dispatch: The mainLoop selects an idle storeWorker from the idleStoreThread channel and dispatches the batch.
    4. Execution: The worker executes the clientHandler (either registerHandler or deregisterHandler), which performs the actual bulk operation on the store.Store (e.g., BatchAddClients or BatchDeleteClients).
    5. Response: Results are communicated back to the callers via ClientFuture objects using SendClientReply.
  10. Access API endpoints via different modes

    main

    The HTTPServer routes requests based on the openAPI configuration provided during Initialize. The primary modes are:

    • admin: Provides access to index and admin servers. Used for management tasks.
    • console: Provides access for management consoles. Includes discovery (v1/v2), config service, client server, auth server, and Prometheus discovery.
    • client: Provides access for service clients. Typically exposes discovery (v1) and config service endpoints under the /v1 path.

    Each mode is enabled or disabled via the Enable field in the apiserver.APIConfig object.