Designing a Scalable Open Platform: Architecture, Gateways, and Security

Preface

The first article in the open‑platform design series covered functional design; this second part merges architecture and technology because detailed company‑specific architecture cannot be disclosed. The overview is therefore simplified, and the technical section will later explain implementation of each functional module.

1. Overall Architecture Overview

The diagram below (privacy‑sensitive information removed) shows the generic open‑platform architecture, which consists of the following parts:

Internet‑facing web server: usually Nginx for load balancing and reverse proxy, deployed in a DMZ for network isolation.

OpenAPI gateway: a linear cluster inside the intranet handling request throttling, circuit breaking, billing, etc.

OpenAPI portal: provides developer‑facing pages, service applications, and app management; also cluster‑deployed.

OpenAPI management: internal admin console for service and app review, basic maintenance; cluster‑deployed.

Service registration and discovery center: core of the service‑oriented architecture, handling routing, registration, and discovery; cluster‑deployed.

Security services: registered to the service center for use by all services.

OAuth service: also registered to the service center as a foundational component.

Open platform service composition (BIM): combines atomic services before publishing to the service center; often deployed as a linear cluster.

OpenAPI server (internal service management): manages service metadata, interface configuration, and application metadata.

2. Service Access Gateway

The gateway implementation is straightforward, with key points as follows:

External service access: typically implemented with Spring MVC or Spring Boot controllers; for many services, a Zuul‑style pass‑through gateway or a custom controller that routes based on URI can reduce the number of controllers.

Rate limiting and circuit breaking: Hystrix is a mature solution; alternatives include custom thread‑pool or token‑bucket mechanisms for concurrency control and Redis for distributed counting.

Service billing: based on request counts, usually tracked in memory or Redis; Redis clusters are recommended for high availability.

Distributed scaling: requires stateless short‑lived connections and token‑based authentication to ensure scalability.

3. Service Composition

Service composition is a common module, typically falling into sequential, parallel, or custom‑logic categories.

Sequential composition: calls services in a defined order, passing selected fields from one response to the next.

Parallel composition: frequently used in mobile scenarios; multiple services are invoked concurrently, results are aggregated, and the combined response is returned to the client. Java's fork/join framework can be used, with careful exception handling.

Custom‑logic composition: either fully coded or implemented via a defined interface, similar to serverless approaches.

4. OAuth

OAuth is essential for the platform. Standard implementations can use Spring Security and Apache Shiro, but many companies add custom requirements. Building a lightweight in‑house solution (token issuance, validation, expiration, rotation) offers full control despite fewer features.

5. Service Registration Management

Implemented with traditional Java web technologies, this module centrally manages metadata for applications, services, and interfaces.

6. Service Registry and Discovery Center

Beyond simple routing, it handles service health, monitoring, etc. Recommended solutions include Zookeeper or Eureka; the author prefers Eureka with Spring Cloud for its rapid evolution.

7. Security

Key security considerations include:

Message encryption/decryption: asymmetric keys for key exchange, symmetric encryption for payloads, optional white‑box encryption.

Transaction signing: asymmetric encryption plus hashing.

Application key management: reuse existing CA systems or build a custom key store.

Interface permission control: 1‑to‑N mapping of developer permissions.

OAuth token mechanism: as described earlier.

Black/white lists: stored in memory or Redis for performance.

Field masking and restoration: mask sensitive fields for front‑end, restore them internally before persistence.

Transaction anti‑fraud: often a post‑processing blacklist generated by real‑time big‑data pipelines (e.g., Storm) that feed into dynamic security policies.

8. Sandbox

The sandbox provides service simulation with the following features:

Message simulation: tools like MockServer or custom implementations.

Test data initialization: reset data for clean testing.

Test account management: allow developers to create test accounts.

Docker support: containerize environments for rapid setup and teardown.

9. Portal and Management Console

Both are standard Java web portals; front‑end can use richer H5 technologies for a more attractive UI. Monitoring can be added via third‑party components that aggregate service call metrics.

Conclusion

The article provides a concise overview of core open‑platform implementation topics; each section could be expanded into a full article, reflecting the breadth of technologies involved.