Cloud Computing 14 min read

Hybrid Cloud Architecture and Migration Strategies for Tencent Cloud Low‑Code Platform

Anson from Tencent Cloud describes how the 微搭 low‑code platform uses a hybrid‑cloud architecture that separates public‑cloud design from private‑cloud deployment, employing a split‑able micro‑service design that can be merged into a single pod, cutting resource usage by up to 90 % and eliminating version‑related O&M issues.

Tencent Cloud Developer
Tencent Cloud Developer
Tencent Cloud Developer
Hybrid Cloud Architecture and Migration Strategies for Tencent Cloud Low‑Code Platform

In this article, Anson from Tencent Cloud shares the architecture design experience of the 微搭 low‑code platform, focusing on how to achieve a hybrid‑cloud solution that combines public‑cloud development with private‑cloud deployment.

Traditional on‑premises private deployments require customers to allocate IDC resources, which can be costly. By separating the design stage (public cloud) from the runtime stage (private cloud), the platform reduces resource consumption by up to 90% and eliminates version‑related O&M work.

The key concepts introduced are:

微搭低代码 : a visual low‑code platform for building WeChat mini‑programs and enterprise management systems.

混合云 : a hybrid environment that uses both public and private clouds.

微搭混合云 : development on public cloud, deployment on customer IDC.

Architecture overview (1.0 version) includes:

Basic services for API gateway and DNS/LB routing.

Gateway services handling front‑end and back‑end traffic.

Service control covering over 20 micro‑service components (permissions, data models, workflow, messaging, etc.).

Supporting components such as MySQL, MongoDB, Redis, Kafka, and object storage.

Two main challenges were identified:

How to support both micro‑service and monolithic deployments when customer machines are limited.

Version mismatch between public‑cloud design artifacts and the older private‑cloud runtime base.

Solution 1 – “可分可合” (split‑able and merge‑able) architecture:

Each micro‑service can be compiled as an independent process (split) or merged into a single Spring Boot application (merge). The merge is achieved by creating an “AllInOneApplication” that imports all service JARs via @EnableFeignClients and excludes individual @SpringBootApplication classes.

@EnableFeignClients
@ComponentScan(basePackages = {"com.xxx"},
    excludeFilters = {@ComponentScan.Filter(
        type = FilterType.ASSIGNABLE_TYPE,
        classes = {
            com.xxx.AApplication.class,
            com.xxx.BApplication.class,
            com.xxx.CApplication.class,
            // ... other services
        })
})
@SpringBootApplication
public class AllInOneApplication {
    public static void main(String[] args) {
        SpringApplication.run(AllInOneApplication.class, args);
    }
}

Solution 2 – Unified configuration and database:

All service databases are merged into a single database initialized by a dedicated datainit service.

All YAML configuration files are consolidated; new keys receive a service‑specific prefix to avoid collisions.

Solution 3 – Maven profile for private deployment:

<profile>
    <id>private</id>
    <build>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
                <excludes>
                    <exclude>application.properties</exclude>
                    <exclude>bootstrap.yaml</exclude>
                    <exclude>application.yml</exclude>
                    <exclude>application-*.yaml</exclude>
                </excludes>
            </resource>
        </resources>
    </build>
</profile>

Deployment workflow uses Maven commands such as mvn clean install -DskipTests -DSPRING_PROFILE=private -s ../settings.xml to build the monolithic package.

To keep the private‑cloud base in sync with public‑cloud updates, a hybrid‑cloud agent establishes a long‑lived WebSocket connection, enabling:

Management flow: reporting cluster info, deployment, upgrade, and rollback.

Data flow: runtime services that correspond to public‑cloud micro‑services.

The architecture transformation reduced the number of runtime services from 21 micro‑services to a single pod, cutting CPU and memory usage from 84 C/168 G to 8 C/16 G, and eliminated version‑related O&M incidents.

Overall, the hybrid‑cloud design demonstrates how a low‑code platform can achieve “split‑able” public‑cloud development and “merge‑able” private‑cloud deployment, delivering lightweight delivery and significant resource savings.

ArchitectureMicroservicesDevOpsSpring Boothybrid-cloudlow-code platform
Tencent Cloud Developer
Written by

Tencent Cloud Developer

Official Tencent Cloud community account that brings together developers, shares practical tech insights, and fosters an influential tech exchange community.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.