- Technical Entry: Dive into governance details and architecture 👉 technical-entry.md
- Practical Entry: Quick start and canary deployment 👉 practical-entry.md
- Quick Trial: 👉 getting-started.md
- Core Stance: 👉 MANIFESTO.md
- Design Principles and Boundaries: 👉 WHY.md
You don't need to read everything at once.
LingFrame allows you to pause at any stage.
Real-time ling governance dashboard: monitor status, canary traffic, and audit logs.
LingFrame (LingFrame) is a JVM runtime governance framework for long-running systems.
It aims to keep legacy monolithic applications stable, controllable, and evolvable without rewriting the system or forcing microservices splits.
Many systems aren't poorly designed—
they've just lived too long and changed too hastily.
It wasn't born for elegance initially.
One day, people realized the system had grown too vast to comprehend, yet it couldn't stop.
Every change felt like groping in the dark,
every deployment came with a prayer.
So, someone asked a seemingly conservative question:
If the system can't be rewritten for now,
can it still be governed?
Not through more rules,
but through clearer boundaries.
Not making decisions for the system,
but putting things back in their rightful place while it's still understandable.
Thus, LingFrame was born.
In many real-world systems, the issue isn't a lack of features, but:
- The system is still running, but no one dares to change it
- Unit boundaries fade, couplings become untraceable
- After introducing Lings, isolation stays structural only
- Restarts aren't unacceptable, but unpredictable
LingFrame addresses one core problem:
How to prevent systems from losing control in long-term operation.
v0.2.0 · Metamorphosis
This is a stage of breaking shackles and redefining boundaries:
- Discarding the cognitive limits of "Plugin" to establish physical "Ling (Unit)" isolation
- Resilience governance is no longer superficial, but deeply embedded as kernel-level circuit breakers
- Confronting the deep waters of ClassLoader leaks, replacing compromise with absolute eviction
- Verifying another thing:
Can monolithic hot-swapping truly withstand industrial-grade high availability challenges?
This is a phase that sheds immaturity and confronts brutal production realities.
v0.1.0 · First Cry (Historic)
This is a stage where the direction is frozen and boundaries are forming:
- Not pursuing full features
- No backward compatibility promises
- Verifying one thing:
Does runtime governance hold in a single process?
- A JVM runtime governance framework
- A structural tool for legacy systems
- A system that allows Lings but doesn't tolerate their chaos
- A resilient hub equipped with Circuit Breakers, Rate Limiters, and Ecosystem SPI extensions
It's not a microservices replacement,
nor a modularization silver bullet.
LingFrame's purpose is to provide possibilities for "retraction" and "reorganization" when the system reaches a certain complexity.
- JVM: JDK 17 / JDK 8
- Spring Boot: 3.x / 2.x
- Single-process ling isolation and governance
- Resilience & Ecosystem: Native support for Canary releases, Circuit Breaking, Rate Limiting, and non-invasive external registry/config integration.
- Clear distinction: Interface stability ≠ Implementation stability
LingFrame doesn't hide complexity—
it just refuses to dump it all on the user at once.
LingFrame won't make decisions for the system.
She just helps put things back in place while the system is still willing to be understood.
If you just stop here,
that's perfectly fine.
This project is an AtomGit G-Star Incubated Project.
Thanks to AtomGit for supporting and promoting open source projects.