Lynx Plugin Ecosystem

This page is a map, not a plugin config reference. Use it to decide which plugin page to read next and to understand where one plugin's responsibility ends and another system or dependency begins.

How To Read A Plugin Page

For any Lynx plugin, the four facts that matter most are still:

1. the Go module path
2. the configuration prefix
3. the runtime plugin name
4. the public API you use after startup

That set tells you how the plugin is loaded, how it is looked up at runtime, and whether it is a good match for your integration point. This ecosystem page itself has no standalone YAML because it is not a runtime plugin.

Navigation By Job To Be Done

Goal	Start here	What you are really choosing
Expose service traffic	HTTP, gRPC, TLS, Swagger	Server entrypoints, ports, middleware/interceptor surfaces
Use data stores and locks	Database Plugin, SQL SDK, MongoDB, Redis, Redis Lock, Etcd Lock	Shared clients, lock semantics, and storage-specific APIs
Consume config centers or governance control planes	Apollo, Nacos, Etcd, Polaris	External control planes, not business-facing APIs
Add transaction or identity infrastructure	Seata, DTM, Eon ID	External coordinators, ID layout, and operational ownership boundaries
Add traffic protection and observability hooks	Sentinel, Tracer	Resource naming, protection policy, and observability surfaces
Add asynchronous brokers	Kafka, RabbitMQ, RocketMQ, Pulsar	Broker clients, delivery semantics, and topic ownership
Understand templates and lifecycle	Layout, Plugin Usage Guide, Plugin Management	What the scaffold imports, what runtime owns, and how plugins are ordered

Dependency Boundaries That Matter Most

Page	What it depends on	What it does not own	Read together with
Seata	An external Seata coordinator plus the referenced Seata client YAML	Transaction boundary placement inside your business code	DTM
DTM	An external DTM server and, optionally, gRPC/TLS assets	Branch business endpoints and orchestration semantics	Seata
Sentinel	Stable resource names from HTTP, gRPC, or business wrappers	Dynamic config-center rule loading or automatic resource design	HTTP, gRPC
Eon ID	Optional shared Redis when worker auto-registration is enabled	Redis provisioning and uniqueness guarantees after you disable auto-registration	Redis
Redis Lock	A working Redis plugin and clear lock ownership rules	Redis deployment, connection bootstrap, or business retry policy	Redis
Apollo, Nacos, Etcd	External config / service-discovery control planes	Application-local validation of every consumed key	Bootstrap Configuration

One Repo Is Not Always One Page

• lynx-mysql, lynx-pgsql, and lynx-mssql are concrete SQL plugins that are easier to compare through Database Plugin plus SQL SDK.
• lynx-layout is a service template, not a runtime plugin, so it belongs with Layout.
• lynx-redis-lock is a capability layer on top of Redis and should be read together with Redis Lock and Redis.
• lynx-eon-id used to live mostly as a side mention in the ecosystem page, but it now deserves its own page because its Redis dependency, fail-closed behavior, and bit-allocation limits are specific enough to document separately.

Common Consumption Patterns

Across the codebase, plugin access usually looks like one of these patterns:

• runtime-owned server getter: http.GetHttpServer(), grpc.GetGrpcServer(nil)
• client getter: mongodb.GetMongoDB(), elasticsearch.GetElasticsearch()
• package-level runtime helper: eonid.GenerateID(), eonid.ParseID(id)
• plugin-manager lookup: lynx.Lynx().GetPluginManager().GetPlugin("dtm.server")
• plugin object API: apolloPlugin.GetConfigValue(...), etcdPlugin.GetClient()

When reading docs, prefer examples that match one of these real lookup patterns. That is usually the fastest way to distinguish a runtime-owned server plugin from a client wrapper or a pure capability layer.

Recommended Reading Order

1. Plugin Usage Guide
2. Bootstrap Configuration
3. Plugin Management
4. the specific plugin page you are integrating
5. Framework Architecture