Case Study of a Business Middle‑Platform Architecture Using SpringBoot, Kong API Gateway, MyCat, and K8s

The author, an external architect, shares a post‑implementation review of a business middle‑platform created for a well‑known consumer goods company. The platform manages customer assets (cards, coupons, virtual assets) and exposes standard RESTful APIs to internal apps, mini‑programs, and partner channels such as banks and Alibaba.

Business Architecture – The system handles roughly 7 million daily service calls, peaking over 10 million during events. It provides asset management services via RESTful endpoints and integrates with internal systems (e.g., member information sync) through a service gateway.

Technical Architecture – The solution adopts a SpringBoot‑based microservice architecture, containerized with Kubernetes and fronted by Kong API Gateway for unified API management. Kong offers open‑source enterprise features, sub‑millisecond latency, 25 K TPS per node, and built‑in authentication, rate‑limiting, logging, and analytics.

Application Architecture – Four services are deployed: Asset Service, Asset Consumer (MQ listener), Console Service (admin APIs), and Console Front‑end (Vue). All components run in containers behind an Ingress controller.

Custom MyBatis Configuration

@Bean
public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception {
    SqlSessionFactoryBean sfb = new SqlSessionFactoryBean();
    sfb.setDataSource(dataSource);
    sfb.setVfs(SpringBootVFS.class);
    Properties props = new Properties();
    props.setProperty("dialect", dataConfiguration.getDialect());
    props.setProperty("reasonable", String.valueOf(dataConfiguration.isPageReasonable()));
    PageHelper pagePlugin = new PageHelper();
    pagePlugin.setProperties(props);
    sfb.setPlugins(new Interceptor[]{pagePlugin});
    ResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
    sfb.setMapperLocations(resolver.getResources("classpath*:mappers/" + dataConfiguration.getDialect() + "/*.xml"));
    sfb.setTypeAliasesPackage("com.xxx.bl.core.data.model");
    SqlSessionFactory factory = sfb.getObject();
    factory.getConfiguration().setMapUnderscoreToCamelCase(true);
    factory.getConfiguration().setCallSettersOnNulls(dataConfiguration.isCallSettersOnNulls());
    return factory;
}

Logback Logging Configuration

<springProfile name="stg">
    <root level="error">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="SAVE-ERROR-TO-FILE-STG"/>
    </root>
    <logger name="org.xxx" level="error" additivity="false">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="ASYNC-SAVE-TO-FILE-STG"/>
    </logger>
</springProfile>
<springProfile name="prod">
    ...
</springProfile>

SSL Encryption – SSL is enabled by adding a JKS certificate to the classpath and configuring ssl.enabled: true , key-store , key-store-password , etc. Passwords are protected using Jasypt or external vaults (Azure Key Vault, CyberArk Conjur).

Sync vs. Async Service Handling – The platform uses a three‑node RabbitMQ cluster. Requests are classified as synchronous or asynchronous; asynchronous calls are routed to RabbitMQ and processed by consumer services, enabling traffic‑shaping during peak periods.

Dockerfiles

FROM openjdk:11-jre
ARG JAR_FILE=console-service/build/libs/*.jar
COPY ${JAR_FILE} app.jar
EXPOSE 9002 9003
ENTRYPOINT ["java","-jar","/app.jar"]

FROM cargo.xxx.net/library/nginx:stable-alpine
COPY /dist /usr/share/nginx/html/console
COPY nginx.conf /etc/nginx/nginx.conf
ARG KEY_FILE=stg.xxx.net.key
ARG PEM_FILE=stg.xxx.net.pem
COPY ${KEY_FILE} /etc/ssl/certs/cert.key
COPY ${PEM_FILE} /etc/ssl/certs/cert.pem
EXPOSE 80
CMD ["nginx","-c","/etc/nginx/nginx.conf","-g","daemon off;"]

Database Architecture – To handle billions of records, the system uses MyCat as a proxy for sharded MySQL clusters (1 master, 2 slaves, 1 backup). Master‑to‑slave replication is semi‑synchronous; automatic failover and switchover are managed by MyCat. Both vertical (by domain) and horizontal (by range) sharding are applied, with hot data cached in Redis and cold data archived.

DevOps & K8s Deployment – Jenkins drives CI/CD: code is fetched from GitHub, built with Gradle (backend) or npm (frontend), packaged into Docker images, and deployed to a Kubernetes cluster. ConfigMaps externalize application.yml . Resource requests (e.g., 2 CPU, 4 GiB) and pod replica counts are defined, with rolling updates and HPA based on CPU metrics to handle peak loads.

Monitoring & Observability – The stack includes ELK (Elasticsearch, Logstash, Kibana) for log aggregation and Dynatrace for APM, providing real‑time dashboards and automatic service discovery.

Reflections – The author notes challenges such as code intrusion from sharding, future migration to NewSQL (TiDB), JVM tuning (Long GC, possible JDK 13 with ZGC), multi‑level caching (Redis + Guava), low‑code benefits from a shared application framework, and the importance of unified development patterns.

The article concludes with an invitation to join a technical community for further knowledge sharing.