Overview
The Gateway Microservice is the unified entry point for internal microservice calls within the IoT platform, distinct from API gateways or cloud platform gateways that face external devices or applications. In a microservice architecture, dozens of services such as device services, data services, alarm services, and authentication services call each other. Using point-to-point direct connections would face governance challenges like service discovery, load balancing, circuit breaking, rate limiting, and traceability. The Gateway Microservice, as an 'internal traffic governance center,' uniformly handles these cross-cutting concerns, ensuring stable, observable, and controllable communication between services.
Division of roles between the Gateway Microservice and API Gateway: The API Gateway handles external requests (device reports, application calls), responsible for protocol conversion, authentication and authorization, and routing to internal services; the Gateway Microservice handles internal service-to-service calls, responsible for service discovery, load balancing, circuit breaking, and traceability. In some architectures, the two can be combined, but in large-scale platforms, they are usually separated to ensure clear responsibilities and independent scaling.
Core Capabilities
Service Discovery
Dynamic service registration and discovery based on Nacos, Consul, Eureka, etc. Service instances automatically register at startup and are automatically removed when offline. Callers access services by service name rather than IP:Port, supporting instance scaling and fault migration. IoT platforms have many services and instances, making service discovery the foundation of microservice operation.
Load Balancing
Strategies include round-robin, random, weighted, and consistent hashing. Consistent hashing ensures requests from the same device/tenant reach the same instance, which is beneficial for caching and session persistence. Supports traffic allocation during canary and blue-green releases.
Circuit Breaking and Rate Limiting
Circuit Breaking: Fail fast when downstream services malfunction to prevent cascading failures. Rate Limiting: Protect downstream services from being overwhelmed by sudden traffic. Implemented with Sentinel, Hystrix, etc. In IoT scenarios, batch device online events or sudden rule engine triggers can cause traffic spikes, making circuit breaking and rate limiting indispensable.
Link Tracing
Distributed call chain tracing, recording each service a request passes through, time spent, and exceptions. Tools include Jaeger, Zipkin, SkyWalking, etc. Useful for identifying performance bottlenecks and troubleshooting cross-service issues. IoT request chains are long (access → rules → data → alerts), making link tracing highly valuable.
Typical IoT Call Chain
Device report → Access gateway → Rule engine (calls data service to query, calls alert service to push) → Data service (writes to time-series database). API request → API gateway → Device service (calls authentication service to verify) → Data service (query). The gateway microservice is responsible for routing, load balancing, circuit breaking, and tracing in these calls.
Technology Selection
Spring Cloud Gateway, Kong, APISIX, Traefik, etc. Spring Cloud Gateway integrates well with the Java ecosystem; Kong and APISIX have rich plugins and high performance. When choosing, consider compatibility with the existing tech stack and service mesh (e.g., Istio).