Minsheng Bank Data Middle Platform: Cloud‑Native Architecture, Tools, and Practices

Introduction – In the context of a "technology + data" driven transformation, Minsheng Bank launched a data middle platform in 2018, completing it in 2019. The platform’s technical requirements naturally align with cloud‑native principles, prompting the bank to explore and innovate its own implementation.

Overview of the Data Middle Platform – The data middle platform, first proposed by Alibaba in 2017, standardizes data collection, processing, and storage across the enterprise, providing a unified data service layer for business and decision‑making. Minsheng Bank was a pioneer in the financial sector, receiving the 2018 Financial Industry Technology Innovation Award. Its architecture follows a microservice + container model, comprising Store (storage), Service (data services), Open (routing), and Plus (management) subsystems, all built with domestically sourced, security‑compliant components. The platform now supports over ten business lines, 100+ specialized financial scenarios, and handles more than 10 million daily service calls.

Cloud‑Native Basics – Cloud‑native, coined around 2013 and formalized by CNCF in 2015, emphasizes designing applications for native cloud deployment rather than migrating VM‑based workloads. Key technologies include containers, service mesh, microservices, immutable infrastructure, and declarative APIs. For Minsheng Bank, cloud‑native equals microservices + DevOps + continuous delivery + containerization.

Pain Points Driving Cloud‑Native Architecture – The platform faces four main challenges: (1) massive storage waste due to file‑based data distribution, requiring heterogeneous cloud storage; (2) low data delivery efficiency, necessitating on‑demand microservice access; (3) high manpower costs for maintaining numerous front‑end data teams, calling for automated deployment and continuous delivery; and (4) weak governance of file‑based data, demanding robust cloud‑based collaboration and management capabilities.

Exploration and Innovation – The bank’s cloud‑native journey is divided into three exploration areas:

Tool‑level: a one‑stop data‑service cloud DevOps workbench.

Management‑level: a scenario‑based financial service management scheme.

Component‑level: a graded application plan for heterogeneous storage components.

Tool‑Level Innovations

Plug‑in Development Framework & Code Generator – A UI‑driven generator lets developers select required microservice features (service registration, logging, caching, etc.) and storage options (MySQL, Redis, Gauss, SDB, HBase). It produces ready‑to‑deploy code with best‑practice configurations.

One‑Click Cloud Compilation, Deployment & Release – Automates source compilation, image building, container deployment, and version tracking, providing transparent, traceable, and rollback‑capable releases.

Automated Source and Configuration Validation – Change‑list tools compare source code and configuration differences between versions, flagging missing or mismatched items with red/yellow alerts and halting pipelines on critical errors.

Full‑Chain Service Tracing – Integrates service registration, API‑Key identification, request IDs, interception, logging, and real‑time analysis to monitor microservice health, including data‑store access metrics.

Lifecycle Management for Heterogeneous Components – Supports coordinated data migration across storage types (e.g., retiring MySQL data into SequoiaDB) while maintaining service continuity.

Visual Cache Heat Management – Allows dynamic adjustment of cache TTL and toggles, with dashboards for cache key inspection and usage analytics.

Conclusion – The "tool" part of the series demonstrates that successful cloud‑native adoption requires both technical compliance and innovative management practices. The upcoming "management" part will further discuss microservice granularity control and data consistency across heterogeneous storage in the banking context.