Yudao Framework Enhancement Capabilities
Core Positioning
In a nutshell: On top of Yudao’s native capabilities, RuoYiPlus has made enterprise-level enhancements across 8 major dimensions to the framework infrastructure, giving the framework “out-of-the-box” production-grade capabilities.
What Problems It Solves
| Pain Point | Yudao Native | After RuoYiPlus Enhancement |
|---|---|---|
| Insufficient data permissions | Dept-level filtering only | User/Role/Post/Dept four layers + field-level |
| Sensitive information leak risk | No masking mechanism | Annotation-based auto masking |
| Incomplete operation logs | Basic logging | Intelligent change tracking + risk scoring + blockchain attestation |
| Lack of API protection | Basic routing | Request signing + rate limiting + circuit breaking |
| Weak distributed capabilities | None | Distributed transactions + locks + idempotency |
| Single caching strategy | Redis single layer | Caffeine + Redis multi-level cache |
| Difficult database scaling | Single database | Read/write separation + sharding + data archiving |
| Weak monitoring capabilities | None | SkyWalking full-chain tracing + custom metrics |
Suitable Users
mindmap
root((Suitable Users))
Software Vendors
Need authorization management
Need commercial infrastructure
Enterprise IT Teams
Need security compliance
Need multi-tenant isolation
System Integrators
Need rapid delivery
Need modular assembly
SaaS Operators
Need multi-tenant architecture
Need billing system
1. Data Permission Engine
1.1 Four-Layer Permission Model
graph LR
subgraph "Permission Sources"
F["User Permissions
Highest Priority"] G["Role Permissions"] H["Post Permissions"] I["Dept Permissions
Lowest Priority"] F ~~~ G ~~~ H ~~~ I end subgraph "Permission Decision Engine" A["User Request"] --> B["Permission Resolution"] B --> C["Permission Merge"] C --> D["Data Filtering"] D --> E["Level Filtering"] end subgraph "Permission Filtering" J["SQL Filtering"] --> K["Return Results"] end PS["Permission Sources"] --> PDE["Permission Decision Engine"] PDE["Permission Decision Engine"] --> PF["Permission Filtering"] style B fill:#FFA500,color:#fff,font-weight:bold
Highest Priority"] G["Role Permissions"] H["Post Permissions"] I["Dept Permissions
Lowest Priority"] F ~~~ G ~~~ H ~~~ I end subgraph "Permission Decision Engine" A["User Request"] --> B["Permission Resolution"] B --> C["Permission Merge"] C --> D["Data Filtering"] D --> E["Level Filtering"] end subgraph "Permission Filtering" J["SQL Filtering"] --> K["Return Results"] end PS["Permission Sources"] --> PDE["Permission Decision Engine"] PDE["Permission Decision Engine"] --> PF["Permission Filtering"] style B fill:#FFA500,color:#fff,font-weight:bold
1.2 Capability Comparison
| Capability | Native Support | After Enhancement |
|---|---|---|
| Dept-level data filtering | ✅ | ✅ |
| Role-level data filtering | ❌ | ✅ |
| Custom SQL filtering | ❌ | ✅ |
| Field-level permission control | ❌ | ✅ |
| Dynamic data permission rules | ❌ | ✅ |
| Customer level filtering | ❌ | ✅ |
1.3 Usage
// Role-based data permission: Sales manager sees team data, regional director sees region data
@DataPermission(roles = {"sales_manager", "region_director"})
public class CustomerServiceImpl { }
// Dept-based hierarchical permission
@DataPermission(deptIds = "#{currentUser.deptId}")
public class ReportService { }
// Custom data scope
@DataPermission(scope = "custom", sqlFilter = "region_id = #{currentUser.regionId}")
public class RegionService { }
// Field hiding
@DataPermission(fields = {"salary", "bankCard"}, operation = DataPermission.Operation.HIDE)
public class EmployeeService { }
// Field read-only
@DataPermission(fields = {"createTime", "creator"}, operation = DataPermission.Operation.READONLY)
public class OrderService { }
2. Sensitive Field Masking
2.1 Masking Architecture
graph LR
A["Data Query"] --> B["Masking Rule Match"]
B --> C["Field Type Identification"]
C --> D["Masking Algorithm Application"]
D --> E["Return Masked Result"]
2.2 Supported Masking Types
| Masking Type | Example | Description |
|---|---|---|
| Phone Number | 138****1234 | Middle 4 digits masked |
a***@163.com | Username masked | |
| ID Card | 310***********1234 | Birth date + last 4 digits masked |
| Bank Card | **** **** **** 1234 | Only last 4 digits retained |
| Name | Zhang* | All but surname masked |
| Address | Shanghai Xuhui District**** | Detailed address masked |
| Password | ****** | Fully masked |
2.3 Usage
// Annotation-based masking
public class Customer {
@SensitiveField(type = SensitiveType.PHONE)
private String phone;
@SensitiveField(type = SensitiveType.EMAIL)
private String email;
@SensitiveField(type = SensitiveType.ID_CARD)
private String idCard;
}
// Auto-masking on query
@SensitiveQuery(fields = {"phone", "email"})
public List<Customer> getCustomerList(CustomerQuery query) { }
3. Operation Log Center
3.1 Log System
graph TB
subgraph "Log Collection"
A["Operation Behavior"]
B["Login Events"]
C["API Calls"]
end
subgraph "Log Processing"
D["Log Parsing"]
E["Change Comparison"]
F["Risk Scoring"]
end
subgraph "Log Storage"
G["Hot Data Storage"]
H["Cold Data Archiving"]
I["Blockchain Attestation"]
end
A --> D
B --> D
C --> D
D --> E
E --> F
F --> G
F --> H
F --> I
3.2 Intelligent Change Tracking
// Auto-compare before/after changes, only record changed fields
@OperateLog(title = "Customer Management", businessType = BusinessType.UPDATE)
public void updateCustomer(Customer customer) { }
3.3 Sensitive Operation Alerts
aegis:
audit:
alert-rules:
- event: "Data Export"
threshold: 10 # More than 10 times in 10 minutes
action: "notify_admin"
- event: "Batch Delete"
action: "require_approval"
4. API Gateway Enhancement
4.1 Gateway Architecture
graph LR
A["Client Request"] --> B["API Gateway"]
B --> C["Request Signature Verification"]
C --> D["Traffic Control"]
D --> E["Circuit Breaking"]
E --> F["Request Caching"]
F --> G["Protocol Conversion"]
G --> H["Backend Service"]
4.2 Enhancement Features
| Capability | Description |
|---|---|
| Request Signing | API request signature verification, anti-tampering |
| Traffic Control | Multi-dimensional rate limiting strategies |
| Circuit Breaking | Service circuit breaker protection |
| Request Caching | API response caching |
| Protocol Conversion | SOAP → REST conversion |
5. Service Governance
5.1 Distributed Transactions
Seata-based distributed transaction solution:
graph TB
A["Business Request"] --> B["Transaction Initiator"]
B --> C["Seata TC"]
C --> D["Branch Transaction 1"]
C --> E["Branch Transaction 2"]
C --> F["Branch Transaction 3"]
D --> G["Global Commit/Rollback"]
E --> G
F --> G
5.2 Distributed Lock and Idempotency
// Redis + Redisson distributed lock
@DistributedLock(key = "order:lock:", waitTime = 30, leaseTime = 60)
public void processOrder(Order order) { }
// Idempotency control
@Idempotent(key = "order:create:{userId}:{productId}", expireTime = 60)
public Order createOrder(CreateOrderRequest request) { }
6. Cache Enhancement
6.1 Multi-Level Cache Architecture
graph LR
A["Application Request"] --> B["L1 Caffeine"]
B --> C["L2 Redis"]
C --> D["Database"]
D --> C
C --> B
B --> A
6.2 Annotation-Based Caching
@Cacheable(name = "user:list:", expire = 300)
public List<User> getUserList() { }
@CacheEvict(name = "user:list:")
public void updateUser(User user) { }
@CachePut(name = "user:{id}")
public User getUser(Long id) { }
7. Database Enhancement
graph LR
A["Write Request"] --> B["Primary DB"]
C["Read Request"] --> D["Replica DB"]
B --> E["Data Sync"]
E --> D
| Capability | Description |
|---|---|
| Read/Write Separation | Auto-route read/write requests, dynamic-datasource |
| Sharding | ShardingSphere sharding strategies |
| Data Archiving | Auto hot/cold data separation, scheduled archiving |
8. Monitoring Enhancement
graph TB
A["Client"] --> B["Gateway"]
B --> C["Service 1"]
C --> D["Service 2"]
D --> E["Service 3"]
E --> F["Database"]
G["SkyWalking"] -.-> B
G -.-> C
G -.-> D
G -.-> E
- Full-Chain Tracing: Integrated SkyWalking distributed tracing
- Custom Metrics:
@CustomMonitorannotation auto-records - Alert Rules: Supports multi-level threshold alerts
Technical Architecture Overview
graph TB
subgraph "RuoYiPlus Framework Enhancement Layer"
P1["Data Permission Engine
Four-Layer Permissions + Field-Level"] P2["Sensitive Field Masking
Annotation-Based Auto Masking"] P3["Operation Log Center
Change Tracking + Blockchain Attestation"] P4["API Gateway
Signing + Rate Limiting + Circuit Breaking"] P5["Service Governance
Distributed Transactions + Locks + Idempotency"] P6["Multi-Level Cache
Caffeine + Redis"] P7["Database Enhancement
Read/Write Separation + Sharding"] P8["Full-Chain Monitoring
SkyWalking + Custom Metrics"] end subgraph "Yudao Framework Core" CORE["Spring Boot 3 + MyBatis-Plus + Redis"] end P1 --> CORE P2 --> CORE P3 --> CORE P4 --> CORE P5 --> CORE P6 --> CORE P7 --> CORE P8 --> CORE
Four-Layer Permissions + Field-Level"] P2["Sensitive Field Masking
Annotation-Based Auto Masking"] P3["Operation Log Center
Change Tracking + Blockchain Attestation"] P4["API Gateway
Signing + Rate Limiting + Circuit Breaking"] P5["Service Governance
Distributed Transactions + Locks + Idempotency"] P6["Multi-Level Cache
Caffeine + Redis"] P7["Database Enhancement
Read/Write Separation + Sharding"] P8["Full-Chain Monitoring
SkyWalking + Custom Metrics"] end subgraph "Yudao Framework Core" CORE["Spring Boot 3 + MyBatis-Plus + Redis"] end P1 --> CORE P2 --> CORE P3 --> CORE P4 --> CORE P5 --> CORE P6 --> CORE P7 --> CORE P8 --> CORE