How a Hong Kong Virtual Bank Scaled Core Services with Polaris Service Mesh

Background

FuRong Bank, a Hong Kong‑based virtual bank serving global customers, relies on big‑data and cloud‑computing technologies to offer deposit, loan, transfer, wealth‑management, and marketing services. Its core system comprises both purchased third‑party components and two internally developed subsystems, the latter lacking second‑development capabilities and thus requiring vendor support.

Challenges

The rapid expansion of business introduced several technical obstacles:

Multiple communication protocols and divergent message formats caused dependency and version conflicts.

Security mechanisms on the cloud and hybrid‑cloud disaster‑recovery strategies added complexity.

Integrating heterogeneous vendor systems with in‑house services increased integration difficulty, especially regarding RPC protocols, service gateway calls, and data encryption.

Solution: Polaris Service‑Mesh Integration

To address these issues, the team introduced Tencent's Polaris, a cloud‑native service‑governance component. The integration involved:

Adopting Spring Cloud Tencent (Spring Boot 2.4.5, Spring Cloud Tencent 2020.5) for all Spring‑Boot services.

Using Polaris Java SDK for services not built on Spring Boot, with a custom plugin to enable service discovery, routing, and selective registration.

Standardizing configuration via a unified polaris.yml file to manage service discovery, nearby routing, degradation, and health‑check mechanisms.

Introducing a common pom dependency to control custom components and Polaris versioning.

System Integration Details

Enforced HTTPS for all transport to ensure cloud data security.

Leveraged OpenFeign for unified external calls, logging, data masking, and signing.

Integrated a gateway to consolidate traffic.

Encapsulated API engineering with DTO and FeignClient definitions to achieve type‑safe JSON handling.

Challenge Two: Disaster‑Recovery Mechanism

HKICL required automatic failover of MQ queues within five minutes during primary queue outages. The initial design could not achieve automatic switching.

Solution steps included:

Using reporting mechanisms to trigger circuit‑breakers for unavailable services.

Extending MQ probing plugins to detect and isolate faulty queues.

Applying routing weight rules to distribute traffic across multiple queues.

Providing an operational console for manual traffic switching without impacting customers.

Resulting Architecture

The new architecture routes 80% of traffic within the same data center and 20% across data centers, ensuring continuity when queues, dedicated lines, or forwarding services fail.

Additional Explorations

Polaris' rich traffic‑management capabilities enabled further enhancements:

Enhanced gateway using SpringCloudGateway + Polaris to secure public‑cloud financial services via encryption and digital signatures.

Implemented IP whitelist/blacklist controls tied to service registration for fine‑grained access management.

Integrated public‑network services via HTTP proxy, leveraging Apache HttpClient's DefaultRoutePlanner to rewrite proxy targets.

Utilized Polaris SDK's built‑in health‑check to automatically switch to healthy links during failures.

Conclusion

Polaris dramatically improved FuRong Bank's service‑governance maturity, allowing the bank to move away from proprietary RPC protocols toward a unified HTTPS/HTTP + JSON + Feign model, simplifying integration, enhancing disaster‑recovery drills, and ensuring high availability of core banking services.

The open‑source Polaris team provided responsive support, and continuous enhancements have made the platform increasingly robust for enterprise use.