Gateway application

The gateway application is generated in a similar fashion to the monolithic application, except for configurations related to Zuul proxy, Eureka Client, and Hystrix:

@SpringBootApplication
@EnableConfigurationProperties({LiquibaseProperties.class, ApplicationProperties.class})
@EnableDiscoveryClient
@EnableZuulProxy
public class StoreApp implements InitializingBean {
...
}

We have selected the JHipster registry for our registry service. This will be a standalone registry server that other microservice applications and gateways will register:

  • @EnableDiscoveryClient is added to Spring Boot's main class, which will enable Netflix Discovery Client. The microservice applications and gateways need to register themselves to the registry service. It uses Spring Cloud's discovery client abstraction to interrogate its own host and port and then adds them to the registry server.
  • Zuul, on the other hand, is the gatekeeper. This helps route the authorized requests to the respective endpoints, limits the requests per route, and relays the necessary tokens to the microservice application. 
  • @EnableZuulProxy helps the microservice gateway application route the requests to the applicable microservice application based on the configurations provided in the application.yml file:
zuul: # those values must be configured depending on the application specific needs
sensitive-headers: Cookie,Set-Cookie
host:
max-total-connections: 1000
max-per-route-connections: 100
prefix: /services
semaphore:
max-semaphores: 500

In the gateway app, we have specified the aforementioned settings for the Zuul configuration. The maximum number of total connections that a proxy can hold open is kept at 1000. The maximum number of route connections that a proxy can hold open is kept at 100. The semaphore is kept to a maximum of 500. (Semaphore is like a counter that is used for synchronization between threads and processes.)

Zuul filters are defined under store/src/main/java/com/mycompany/store/gateway/ and include access control, rate limit, token relay, and a response rewriting filter.

Access to the backend microservice endpoint is controlled by AccessControlFilter.java, which will check whether the request is authorized and is allowed to request the endpoint:

public class AccessControlFilter extends ZuulFilter {
...
public boolean shouldFilter() {
...
for (Route route : routeLocator.getRoutes()) {
...
if (requestUri.startsWith(serviceUrl.substring(0,
serviceUrl.length() - 2))) {
return !isAuthorizedRequest(serviceUrl, serviceName,
requestUri);
}
}
return true;
}
...
}

A rate-limiting filter is added to the generated application, which is defined in RateLimitingFilter.java, and limits the number of HTTP calls that are made per client. This is enabled conditionally with the following:

public class RateLimitingFilter extends ZuulFilter {
...
}

SwaggerBasePathRewritingFilter.java is also used, which will help us rewrite the microservice Swagger URL base path:

public class SwaggerBasePathRewritingFilter extends SendResponseFilter {
...
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
...
if (context.getResponseGZipped()) {
try {
context.setResponseDataStream(new
ByteArrayInputStream(...);
} catch (IOException e) {
log.error("Swagger-docs filter error", e);
}
} else {
context.setResponseBody(rewrittenResponse);
}

}
...
}

TokenRelayFilter.java is added to remove the authorization from Zuul's ignored headers list. This will help us propagate the generated authorization token:

public class TokenRelayFilter extends ZuulFilter {
...
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
Set<String> headers = (Set<String>) ctx.get("ignoredHeaders");
// JWT tokens should be relayed to the resource servers
headers.remove("authorization");
return null;
}
...
}

Each application should have a Eureka client that helps load balance the requests among the services, as well as send health information to the Eureka Server or registries. The Eureka client is configured in application.yml as follows:

eureka:
client:
enabled: true
healthcheck:
enabled: true
fetch-registry: true
register-with-eureka: true
instance-info-replication-interval-seconds: 10
registry-fetch-interval-seconds: 10
instance:
appname: store
instanceId: store:${spring.application.instance-id:${random.value}}
lease-renewal-interval-in-seconds: 5
lease-expiration-duration-in-seconds: 10
status-page-url-path: ${management.endpoints.web.base-path}/info
health-check-url-path: ${management.endpoints.web.base-path}/health
metadata-map:
zone: primary # This is needed for the load balancer
profile: ${spring.profiles.active}
version: #project.version#
git-version: ${git.commit.id.describe:}
git-commit: ${git.commit.id.abbrev:}
git-branch: ${git.branch:}

We have chosen to enable health checks and have set the interval within which to register and replicate services to 10 seconds, as well as instances where we define the lease renewal interval and expiration duration. 

We will configure a timeout in Hystrix, beyond which the server is considered to be closed:

hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 10000

If the server does not respond within 10 seconds, then the server is considered dead and is unregistered from the registry service. 

With JHipster, you can also build microservice applications that serve REST endpoints without any GUI. 

This ensures no subsequent requests are sent to that server until the server is made active.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.218.184