TianShu is an API egress gateway designed for enterprise external system integration. Through logical API abstraction, dynamic routing, Groovy scripting, and circuit breaking with isolation, it provides a unified solution to fragmented third-party integrations, heterogeneous message formats, fault propagation, and slow rule changes. Keywords: egress gateway, microservices, financial payments.
The technical specification snapshot highlights TianShu’s core stack
| Parameter | Description |
|---|---|
| Project Name | TianShu |
| Core Languages | Java 17, Vue 3 |
| Architecture Style | Spring Boot 3.2 + Spring Cloud microservices |
| Supported Protocols | HTTP, OpenFeign, TCP, custom protocols |
| Core Capabilities | Dynamic routing, idempotency, anti-replay, message transformation, circuit breaking, Mock |
| Core Dependencies | Sentinel, Nacos, Redisson, Groovy, FreeMarker, OkHttp, MyBatis |
| Data Components | MySQL 8.x, Redis 5+ |
| Repository | GitHub / Gitee |
| Stars | Not provided in the source material |
TianShu serves as a unified outbound integration layer for enterprise systems
TianShu is not a traditional API gateway that only forwards traffic. It is a dedicated middleware layer built specifically for external system integration. It consolidates third-party payments, channel APIs, and external services behind a single entry point, then exposes stable logical APIs to internal business systems.
The value is clear: business systems no longer depend directly on external URLs, field definitions, or signature details. Even if a physical API changes, you only need to adjust configuration, scripts, or templates at the gateway layer instead of coordinating releases across every caller.
It solves high-frequency and high-cost integration problems
Common enterprise pain points include inconsistent third-party API standards, duplicated integrations across business lines, external failures impacting core transaction chains, high message transformation costs, and rule changes that require a full release process. TianShu shifts these concerns forward into a centrally governed gateway layer.
Internal System -> Logical API Code -> TianShu Router -> Dynamic Physical API Match -> Protocol Invocation -> Sanitized ResponseThe key value of this pipeline is straightforward: stable logic, decoupled physical endpoints, and hot-updatable policies.
TianShu uses an asynchronous filter chain to implement a pluggable processing flow
The core of the project is an Async Filter Chain. After a request enters the system, TianShu splits processing into three stages: pre-processing filters, outbound routing and invocation, and post-processing cleanup. Each node has a single responsibility, which makes the flow easier to extend, audit, and control during canary releases.
The pre-processing layer handles TraceId injection, logical route matching, idempotency validation, request parsing, pre-execution Groovy strategies, and request rendering. The middle layer handles Mock responses, Sentinel circuit breaking, and protocol execution. The post-processing layer handles response parsing, data masking and sanitization, and final template rendering.
Fourteen filter nodes form the full outbound invocation lifecycle
The most critical nodes include LogicalRouteMatchFilter, IdempotencyFilter, PreStrategyFilter, ProtocolRouteFilter, and ResponseRenderFilter. These components handle route decisions, anti-replay protection, dynamic orchestration, real outbound invocation, and response normalization.
// Look up configuration from the cache based on the logical API code
String apiCode = request.getHeader("X-Api-Code");
LogicalApiConfig config = localCache.get(apiCode); // O(1) lookup for the logical API
// Execute a script based on request parameters and dynamically select the physical channel
PhysicalApiConfig physical = groovyRouter.match(config, businessData); // Dynamic routing
// Invoke the downstream physical API
GatewayResponse response = protocolInvoker.invoke(physical, renderedRequest); // Unified protocol-based outbound callThis code demonstrates TianShu’s core execution model: abstract first, match second, invoke last.
TianShu balances dynamism and stability across the gateway layer
Its dynamism comes from the Groovy AST security sandbox, FreeMarker template rendering, and Nacos/Redis hot update mechanisms. Its stability comes from Sentinel circuit breaking, idempotency control, dual-layer Mock support, and an asynchronous logging and monitoring system.
At the routing layer, the logical API code X-Api-Code acts as the unified entry point. It allows business teams to focus only on what they want to do, rather than which channel, URL, or message format should be used underneath.
Idempotency and anti-replay protection are foundational for payment workloads
TianShu requires requests to include X-Request-Id and uses Redis SETNX to enforce uniqueness within a configurable time window. This is especially important for payment order creation, refund requests, and replayed external notifications.
curl -X POST http://127.0.0.1:8081/api/v1/pay/create \
-H "Content-Type: application/json" \
-H "X-B3-TraceId: demo-trace-id" \
-H "X-Request-Id: req-2026040401" \
-H "X-Api-Code: LOGICAL_PAY_CREATE" \
-d '{"pay_channel":"WXPAY","order_id":"TS2026040401","amount":998}'This request shows how a logical API is invoked. Business systems only need to call the Router module through a unified contract.
TianShu’s module boundaries reflect clear engineering separation
tianshu-admin handles configuration management, API orchestration, and the monitoring console. tianshu-router handles gateway forwarding and filter chain execution. tianshu-dao handles MyBatis-based data access. tianshu-common contains foundational models and utility components. tianshu-ui provides the Vue 3 management interface.
This split works well for medium and large teams. Operations or integration specialists can configure routes, scripts, and templates through the management console, while the Router module delivers high-performance forwarding in the runtime layer.
The startup path is relatively straightforward
The environment requires JDK 17, Maven 3.6+, Node.js 18+, MySQL 8, and Redis 5+. After the backend is built, Admin runs on port 8080 by default, Router runs on 8081, and the frontend runs on 3000.
spring:
datasource:
url: jdbc:mysql://localhost:3306/tianshu?useUnicode=true&characterEncoding=utf8&useSSL=false
username: root
password: your_password # Database password
data:
redis:
host: localhost
port: 6379
password: your_redis_password # Redis passwordThis configuration connects TianShu to its two most critical dependencies: persistence and caching.
TianShu makes practical engineering trade-offs for performance and observability
According to the source material, on an 8-core, 16 GB environment, benchmark results show roughly 35,000 QPS for route-only pass-through, around 15,000 QPS for transparent HTTP proxying, and approximately 8,000 QPS for high-complexity Groovy script scenarios. For an egress gateway that includes scripting, templating, and monitoring capabilities, these numbers are practically useful.
Its logging and metrics design is also pragmatic. Asynchronous logs are written to storage in batches through ArrayBlockingQueue, while real-time metrics are aggregated through LongAdder + Redis Pipeline, minimizing the chance that observability becomes a performance bottleneck.
The images in the source material are primarily decorative site assets
The original Markdown includes several decorative CSDN page assets, brand graphics, and navigation images, but it does not provide a project architecture diagram, console screenshots, or request flow diagrams.
This image is a platform branding asset, so the AI Visual Insight analysis is intentionally skipped as required.
TianShu is well suited for financial payments and integration-heavy microservice systems
If your systems regularly integrate with banks, payment channels, SMS providers, clearing and settlement services, government or enterprise APIs, or heterogeneous vendors, TianShu offers immediate value: a unified outbound layer, reduced coupling, shorter change cycles, and stronger fault isolation.
It is especially suitable for organizations that face many APIs, many rules, rapid changes, and strict stability requirements. It is not just a simple reverse proxy or a generic north-south traffic gateway replacement.
FAQ
1. How is TianShu different from a standard API gateway?
A standard gateway focuses more on traffic ingress, authentication, and basic routing. TianShu focuses on external system integration. It includes built-in logical API abstraction, Groovy-based dynamic strategies, message rendering, and circuit breaking at the physical API level, making it a better fit for financial payments and third-party integrations.
2. Why is TianShu a good fit for payment scenarios?
Payment workloads naturally require idempotency, anti-replay protection, message signing, dynamic routing, sensitive data masking, and isolation from third-party failures. TianShu has explicit design support for these capabilities and also supports hot updates.
3. What are the minimum dependencies required to deploy TianShu?
At minimum, you need JDK 17, Maven, MySQL, Redis, and Node.js for frontend builds. In runtime, the most critical dependencies are Redis for the Router module and correct database configuration for Admin.
AI Readability Summary
TianShu is an enterprise-grade API egress gateway for financial, payment, and microservice environments. It provides a unified outbound entry point, dynamic routing, idempotency control, message transformation, circuit breaking and degradation, and observability. It is designed to solve fragmented third-party integrations, protocol heterogeneity, fault propagation, and release-dependent rule changes.