Silky Microservice FrameworkSilky Microservice Framework
Home
Docs
Config
Source
github
gitee
  • 简体中文
  • English
Home
Docs
Config
Source
github
gitee
  • 简体中文
  • English
  • Startup

    • Silky Framework Source Code Analysis
    • Host Construction
    • Service Engine
    • Module System
    • Service & Service Entry Resolution
    • Service Registration
    • Dependency Injection Conventions
    • RPC Service Proxy
  • Runtime

    • Endpoints & Routing
    • Executor Dispatch System
    • Local Executor & Server-Side Filters
    • Remote Executor & RPC Call Chain
    • RPC Server Message Handling
    • Service Governance
    • Cache Interceptor
    • Distributed Transactions (TCC)
    • HTTP Gateway Pipeline
    • Filter Pipeline
    • Polly Resilience Pipeline
    • Endpoint Health Monitor

Overview

Service Governance is Silky's core mechanism for ensuring microservice reliability. The framework applies multi-layer Polly resilience policies on both the client (caller) side and server (provider) side:

  • Timeout control: Prevents slow services from blocking callers
  • Retry mechanism: Automatically retries on transient failures
  • Circuit breaker: Prevents cascading failures (avalanche effect)
  • Fallback (Degradation): Returns default results when circuit is open or all retries fail
  • Load balancing: Determines which instance receives each request
  • Concurrency guard: Limits max concurrent requests per instance

All governance parameters are managed through GovernanceOptions, supporting three-tier configuration: global defaults, interface-level overrides, and method-level overrides.


GovernanceOptions — Governance Parameters

ParameterTypeDefaultDescription
ShuntStrategyShuntStrategyPollingLoad balancing strategy
TimeoutMillSecondsint5000Call timeout in milliseconds
EnableCachingInterceptorbooltrueEnable cache interception
EnableCircuitBreakerbooltrueEnable circuit breaker
ExceptionsAllowedBeforeBreakingint3Consecutive failures before opening circuit
BreakerSecondsint60Duration the circuit stays open (seconds)
RetryTimesint3Max retry attempts
RetryIntervalMillSecondsint50Retry wait interval (ms)
MaxConcurrentHandlingCountint50Max concurrent requests on this instance (0 = unlimited)
AddressFuseSleepDurationSecondsint60Wait time after marking an endpoint unhealthy (seconds)
UnHealthAddressTimesAllowedBeforeRemovingint3Times unhealthy before removing endpoint from service list

Tips

ProhibitExtranet (disallow external HTTP access) cannot be set in appsettings.yml. It must be applied via [Governance] or [ProhibitExtranet] on the interface or method only.


Three-Tier Configuration Priority

Governance parameters apply in priority order (higher overrides lower):

Method-level [Governance] attribute
    > Interface-level [Governance] attribute (inherited by all methods)
        > Global defaults (appsettings.yml Governance section)

Global Defaults (Config File)

Governance:
  TimeoutMillSeconds: 10000
  RetryTimes: 0
  EnableCircuitBreaker: false

Interface / Method Level Override ([Governance] Attribute)

[ServiceRoute]
[Governance(TimeoutMillSeconds = 3000, EnableCircuitBreaker = false)]  // Interface level
public interface IOrderAppService
{
    // Method level: overrides interface level
    [Governance(TimeoutMillSeconds = 500, ShuntStrategy = ShuntStrategy.HashAlgorithm)]
    Task<OrderDto> GetByIdAsync(long id);

    // Uses interface-level settings (3000ms timeout)
    Task<OrderDto> CreateAsync(CreateOrderInput input);
}

The ReConfiguration() method applies attributes over global defaults during ServiceEntry construction.


Circuit Breaker State Machine

┌──────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   Consecutive failures < ExceptionsAllowedBeforeBreaking             │
│                    ┌─────────────────────┐                           │
│          ┌─────────│      CLOSED         │─────────┐                 │
│          │         │  (normal operation) │         │                 │
│          │         └─────────────────────┘         │                 │
│   Success│                                         │ N consecutive   │
│   (stays │                                         │ failures        │
│   closed)│                                         ▼                 │
│          │         ┌─────────────────────┐         │                 │
│          └─────────│       OPEN          │◀────────┘                 │
│                    │  (refuses requests) │                           │
│                    └──────────┬──────────┘                           │
│                               │ After BreakerSeconds                 │
│                               ▼                                      │
│                    ┌─────────────────────┐                           │
│                    │     HALF-OPEN       │                           │
│                    │ (allows 1 test call)│                           │
│                    └──────────┬──────────┘                           │
│                               │ Test call succeeds → CLOSED          │
│                               │ Test call fails → OPEN               │
└──────────────────────────────────────────────────────────────────────┘

Warning

Business exceptions (e.g., ValidationException, BusinessException) do not trigger the circuit breaker. Only non-business infrastructure exceptions (network timeout, connection refused, etc.) count toward the failure threshold.


Fallback Attribute

[Fallback] specifies a degradation implementation for a service entry:

[ServiceRoute]
public interface IOrderAppService
{
    [Fallback(typeof(OrderFallbackService))]
    Task<GetOrderOutput> GetByIdAsync(long id);
}

// Fallback class — must implement the same interface
public class OrderFallbackService : IOrderAppService
{
    public Task<GetOrderOutput> GetByIdAsync(long id)
        => Task.FromResult(new GetOrderOutput { Status = "Service Unavailable" });

    // Other methods return default/throw NotImplementedException
}

The fallback is invoked when Polly's circuit breaker is open or all retry attempts are exhausted.


Concurrency Guard (MaxConcurrentHandlingCount)

On the server side, Silky tracks active concurrent requests per instance using an atomic counter. When the count exceeds MaxConcurrentHandlingCount:

  1. Server throws OverflowMaxServerHandleException
  2. Client's overflow retry policy (OverflowServerHandleFailoverPolicyProvider) catches it and retries on a different endpoint
  3. If all endpoints are full, the exception propagates to the caller

Set MaxConcurrentHandlingCount = 0 to disable the limit.

Edit this page
Prev
RPC Server Message Handling
Next
Cache Interceptor