1. Is the Gateway a required component? What happens if we don't use it (only let microservices discover each other)? #

First off, the Gateway isn't strictly mandatory—you can technically run a JHipster microservice setup without it, but it's highly recommended for most production scenarios. Here's what you'll face beyond the tight coupling you already noted:

• No unified entry point: Your frontend or external clients would need to know the direct URLs of every microservice. This gets messy fast as you add more services, and makes handling DNS updates or service scaling way harder.
• Redundant auth logic: Without a gateway, each microservice has to implement its own authentication/authorization (like JWT validation). That's repetitive work, raises the risk of inconsistencies, and makes updating auth rules a nightmare across multiple services.
• Scattered cross-cutting features: Capabilities like load balancing, rate limiting, circuit breaking, and API versioning are handled centrally by the gateway. Skip it, and you'll have to build these into every single microservice—bloating code and increasing maintenance costs.
• Fragmented monitoring & logging: A gateway acts as a single hub to collect logs, track API metrics, and trace requests across services. Without it, you'll have to aggregate data from multiple endpoints, making debugging and performance tuning far more complex.

Tight coupling is indeed a critical issue too—services will directly depend on each other's network locations, making independent deployment, scaling, or replacement of services much riskier.

2. Why does JHipster Registry include Eureka Config? Are JHipster Registry and Eureka Server functionally identical? Is the only role of JHipster Registry to handle microservice registration on startup? #

Let's break this down clearly:

Why integrate Eureka Config (Spring Cloud Config) into JHipster Registry? #

JHipster Registry is built on top of Eureka Server but extends it with Spring Cloud Config Server capabilities. The goal here is to simplify your microservice stack: instead of running separate services for service discovery and configuration management, you get both in one component. This cuts down deployment complexity, lowers operational overhead, and ensures services can fetch their configuration the moment they register—creating a seamless startup workflow.

Are JHipster Registry and Eureka Server identical? #

Nope, they're not. Eureka Server only handles core service registration and discovery—tracking which services are running, their locations, and health status. JHipster Registry adds key extra features:

• Centralized configuration management: Serves config files (like application.yml) to microservices at startup or on refresh.
• Built-in monitoring dashboard: Integrates Hystrix Dashboard and Turbine to visualize circuit breaker status and aggregate metrics across services.
• Service health checks: Provides a UI to view the health of all registered services, making it easy to spot issues quickly.
• Direct log access: Lets you view logs from registered microservices straight through the registry UI, simplifying debugging.

Is registration the only role of JHipster Registry? #

Absolutely not. While service registration (and discovery) is a core function, it's just one piece of the puzzle. As noted above, it also acts as your configuration server, monitoring hub, and central point for service health management—it's designed to be a single control plane for your JHipster microservice ecosystem.

内容的提问来源于stack exchange，提问作者Pracede