Shulou(Shulou.com)06/01 Report--

Many novices are not very clear about what the JHipster micro-service architecture is like. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Micro-service architecture vs integrated architecture

When using JHipster to generate applications, the first problem is to let you choose the generated application you want (currently there are 4 options), but you are actually choosing between two architectural styles:

Integrated architecture, used to create a separate application, including front-end AngularJS code and back-end spring boot related code, all the code in the project is in one application.

The micro-service architecture, which separates the front and back end, has the advantage that it allows you to easily control the size of a single application and deal with some simple and minor problems in these applications.

Relatively speaking, the integrated architecture is relatively easy to use. This is recommended by default on the official website. If you are new to JHipstert, it is recommended to start with this. If you are familiar with the project, if there are requirements, then select the micro-service architecture application.

The following section mainly explains the micro-service architecture using JHipster.

Overview

The JHipster microservices architecture works as follows:

JHipster gateway, a complete application that can be generated directly by the generator (select microservice gateway in the first question), includes both the server side and the front end to process web requests. A microservice architecture can have several gateways at the same time, and if you follow the Backends for Frontends pattern model, of course this is not mandatory.

The registry of JHipster Registry JHipster is available on github, and all microservice applications and gateways get configuration from the registry, so it must be run first.

Micro-service application examples of JHipster, which can be generated directly through the generator (select microservice application in the first question), are concrete implementations of providing services. They are stateless. Several of the same instances can be run in parallel at the same time to process a large number of requests.

The console of JHipster Console,JHipster, which provides service monitoring and alarm functions, is based on ELK technology stack.

In the following figure, the green components represent your specific application, and the blue components represent the underlying infrastructure:

API Gateway for JHipster

JHipster can generate API gateway. This is an ordinary JHipster application, you can choose to generate the first question when using yo jhipster, and you can develop it like developing a normal application. It acts as a portal in the micro-service architecture, providing http routing, load balancing, api documents, quality of service and security functions.

Use gateways for HTTP routing

Before starting the gateway and service applications of JHipster, you need to start the JHipster register project as a registry. When configuring the registry address, the application only needs to modify the value corresponding to eureka.client.serviceUrl.defaultZone key (in the src/main/resources/config/application.yml file).

The gateway will automatically proxy all requested services and follow the name of the application, for example, when the microservice application APP1 is registered with the registry, it can be accessed through the / APP1 URL.

For another example, if your gateway runs on localhost:8080, you can get foos resources provided through micro-service APP1 services through http://localhost:8080/app1/rest/foos.

In addition, REST interface resources in JHipster are protected, so when accessing these interfaces through a browser, you need to bring the correct JWT (on the header of the request header, which will be mentioned in the security section below), or comment out the relevant code in the MicroserviceSecurityConfiguration class.

If there are multiple instances of the same service running at the same time, the gateway can obtain these instances from the registry of JHipster and:

Use Netflix Ribbon for load balancing.

Using the circuit breaker mechanism provided by Netflix Hystrix, the suspended running instances can be removed quickly and safely.

Each gateway application provides the functions of http routing and service instance monitoring, which can be seen in the background "Administrator > Gateway" menu.

Secure JWT (JSON Web Token)

JWT (JSON Network token) is now an industry standard, easy to use, and can provide security for micro-service applications.

JHispter uses the JJWT library library, provided by Stormpath, to implement a specific jwt.

All toekn are generated by the gateway and transmitted to the underlying micro-service applications. Because they share a common key, the microservice application can authenticate the token and use the token to authenticate the user.

These tokens are self-sufficient: they have authentication and authorization information, so microservice applications do not need to query databases or external systems. This point ensures the scalability of micro-services, so it is important.

To ensure the secure operation of the service, an token must be shared among all applications:

For each application, the default token is unique, generated through JHipster and stored in the .yo-rc.json file

The value of the token can be configured by modifying the value of jhipster.security.authentication.jwt.secret in the src / mian/resources/config/application.yml file

A good practice is to adopt different token in production and development environments.

OAuth3

This feature is currently in the BETA phase, so its documentation is not yet complete.

JHipster provides a service to generate a Srping security-based "UAA (user account and authentication information)". This service uses Oauth3 token mechanism to ensure the security of the service gateway.

On this basis, the service gateway uses Spring Security's support for jwt to pass token to other underlying micro-service applications.

Automatically generate documents

JHipster's gateway integrates swagger API, so we can easily use Swagger UI and swagger-codegen. In the "admin > API" menu in the administrative background, you can see the API of the gateway, as well as all the API registered for the microservice.

Through the drop-down list, you can view the API documents generated by Swagger, and these API can be tested online. During the test, token will be automatically added to the interface of Swagger UI, so all requests are made outside sandboxie.

Request rate limit

This is an advanced feature that requires the establishment of a Cassandra cluster (which can be easily built through Docker Compose configuration).

The gateway provides speed limit, so the number of REST requests can be limited:

Via IP address (anonymous user)

User login (logged in user)

JHipster will use the request data stored in the Cassandra cluster and will send HTTP 429 (too many requests) errors for requests that exceed the limit. The default speed limit for each user is 100000 API calls per hour.

This is an important feature to protect micro-services from being dragged down by special user requests.

As a level for managing REST interface resources, JHipster register has absolute control over users' security information, so it can be easily extended to provide specific rate limits based on user roles.

To enable rate limiting, you need to configure it in application-dev.yml or application-prod.yml

Jhipster: gateway: rate-limiting: enabled: true

Of course, Cassandra clusters also need to be set up and configured. If you use the configuration of JHipster's Docker Compose (in src/main/docker), it will work properly. If you want to set up the cluster manually, here are some steps to pay attention to:

The first step is to have an available Cassandra cluster.

Need to configure JHipster-specific speedometer, related create_keyspace.cql and create_tables.cql scripts, in the src/main/resources/config/cql directory.

The cluster must be configured in the application-*.yml file with the corresponding key spring.data.cassandra (default configuration has been generated)

If you want to add more rules, or modify existing rules, you need to modify the RateLimitingFilter class. For example, if you want to impose restrictions on the following situations:

Reduce the limit of HTTP calls

Add a per minute or daily limit

Removed all restrictions for the Administrator user

Access control policy

By default, all registered microservices are accessible through gateways. If you want to exclude a specific API from the gateway, you can use the gateway's access control filter to control the specific access. Configure jhipster.gateway.authorized-microservices-endpoints in the application-*.yml file. The default configuration is:

Jhipster: gateway: authorized-microservices-endpoints: # Access Control Policy, if left empty for a route, all endpoints will be accessible app1: / api,/v2/api-docs # recommended dev configuration

If you only want the / api/foo interface of the microservice bar to be accessible, you only need to configure it as follows:

Jhipster: gateway: authorized-microservices-endpoints: bar: / api/fooJHipster registry JHipster registry overview

JHipster Registry is a runnable application developed by the JHipster team. Like JHipster generator, it is open source, follows Apache 2-licensed, and is also placed on github. Click here to see.

You can clone or download the source code of Registry on github. If JHipster generator is used, it is recommended to use Registry with the same tag as it. It runs in the same way as other applications:

Under the development environment, run. / mvnw directly, which defaults to the configuration file under the development environment, and Eureka Registry will be accessible through http://127.0.0.1:8761/.

In the production environment, use. / mvnw-Pprod to package to generate executable WAR files.

If you want to run through the docker image, it is also available in JHipster Registry,Docker Hub, in JHipster Registry, of course, this image is pre-configured.

Run docker-compose-f src/main/docker/jhipster-registry.yml up to start JHipster Registry. Then Eureka Registry will listen on your port 8761 so that it can be accessed through http://127.0.0.1:8761/

For more questions about docker and JHipster Registry, see [docker Compose documentation] ({{site.url}} / docker-compose/)

Security of JHipster Registration Center

JHipster Registry is protected by default and requires an account and password to log in. The default account password is "admin/admin".

Of course, microservice applications are registered on Registry in the role of admin, but they are certified by HTTP Basic. So if your microservice application cannot connect to the registry, you will receive a "401 authentication error" error message because you have misconfigured something.

To ensure the security of JHipster Registry:

You must change the password of admin. This password can be achieved by changing the corresponding value of security.user.password in the application-*.yml file of Spring boot, or you can create a new SECURITY_USER_PASSWORD environment variable. This variable is used in [Docker Compose sub-generator] ({{site.url}} / docker-compose/).

Because your application connects to Registry through HTTP, it is important to secure the connection channel, and one of the easier ways is to use HTTPS.

Register your application on JHipster

JHipster Registry uses Netflix Eureka server and Spring Config Server. When micro-service applications and or micro-service gateways are started, they first connect to JHipster Registry to get configuration information.

These configurations refer to the configuration of spring boot, that is, the application-*.yml file. But they are stored on a central server and are easy to manage.

When the entire service is started, the microservice application or gateway will obtain the configuration information of the service from the Registry and overwrite the configuration file that they originally stored locally.

The following two types of configuration information are available:

Local configuration files under the development environment (using dev profile), using the local file system.

Git configuration information, used in a production environment (using JHipster prod profile), is stored in the git service. Using git, you can set up tag, branch, or roll back configuration information, which is very useful in a production environment.

In order to centrally manage the configuration of microservices, you need to create a configuration file in application-*.yml format and put it in the config file of Registry. Require appname and profile your microservice application with the same name and profile.

For example, adding a gateway-prod.yml file will use the configuration file in the production environment for all applications named gateway. In addition, the configuration defined in application [- dev | prod] .yml will have an effect on all applications.

It is mentioned above that gateway routes are configured through Spring boot, but they can also be managed through Spring Config Server. For example, you can route the application app1-v1 on the v1 branch to the url of / appl, and on the v2 branch, route the app1-v2 to the url of / app1. This is a good way to seamlessly upgrade micro-services so that they can be upgraded without stopping the service.

Create micro-service applications

Micro-service application instances can be generated through JHipster. There is no front-end (the generated micro-service gateway will have a front-end, which uses angularJS). It can only work properly with JHipster Registry.

Generate entity objects for micro-service applications

When using [entity sub-generator] ({{site.url}} / creating-an-entity/) to generate entity for micro-service applications, it is a little different from generating entity in integrated architecture applications, because micro-services achieve the separation of front and rear ends, and the backend of micro-service applications only need to provide interfaces and do not need front-end code, so it does not need to generate front-end code.

First of all, entities can be generated in micro-service applications by generating entity objects in integrated applications, or by using [JHipster UML] ({{site.url}} / jhipster-uml/) or [JDL Studio] ({{site.url}} / jdl-studio/) to generate more complex entities and relationships. Of course, this does not generate AngularJS code.

Then, in the micro service gateway application, running [entity sub-generator] ({{site.url}} / creating-an-entity/) again will cause one more problem at the beginning, which is specifically for the gateway application:

There are two options: either generate a new entity normally, as it does in an integrated architecture application (the Micro Services Gateway application itself is a complete JHipster application, which is a bit like an integrated application), or it can be generated using existing JHipster configuration information.

If you choose the latter, you need to enter the path to the microservice application, and JHipster will generate the front-end code on the gateway (equivalent to managing the microservice application entity through pages in the gateway application).

Using HazelCast for distributed caching

If your application uses SQL's database, JHipster offers different solutions for microservices that support two-tier caching:

JHipster's default microservice caching solution is to use Hazelcast

You can also use Ehcache (the default supported solution for all-in-one applications), or not caching at all.

The default Hazelcast solution supports micro-services, which can well support your expansion of services:

With local caching, you are a single service without a cache that can be synchronized, which may lead to data inconsistencies.

Without using any cache, as the expansion of the service increases, the burden of the system will come to the database, which is not a good solution.

To use Hazelcast as cache, you need to make some special configurations:

At startup, the application connects to the JHipster registration service and finds the same service instance as it.

If dev profile,JHipster is used, clusters of these instances will be created on 127.0.0.1 on the local host, using a different port for each instance. By default, the Hazelcast port is your application's port + 5701 (so if your application's port is 8081) Hazelcast will use port 13782)

If you use prod profile,JHipster to build a cluster with all other nodes it finds, use the default port of Hazelcast (5701)

Micro-service application without database

Only micro-service applications can create programs without databases. This is because microservice applications can be small and without user-managed code.

A micro-service application without a database is small and can be used to connect to a legacy back-end system.

Use Docker Compose

Developing micro-service systems means that you may need to work on several different services and databases at the same time, and Docker Compose is an excellent tool for managing development, test, and production environments for this situation.

To this end, we have a special document to introduce [Docker Compose documentation] ({{site.url}} / docker-compose#microservices), and we strongly recommend reading this article to familiarize yourself with this knowledge before developing a system with a micro-service architecture.

Use JHipster Console and ELK technology stack to monitor services

When you use docker-Compose sub-generator, you will be asked if you need to add monitoring to your application. If you choose Yes, it will add JHipster-Console to your docker-compose.yml file. When you start the system, you can access the http://localhost:5601 to get the logs and indicators that the system should have. For more information on monitoring, see monitoring documentation

Compared to all-in-one applications, gateways and micro-service monitors provide some additional features to help you effectively monitor micro-service clusters. For example, look at the log, it can be specific to the log for the name of the application, host, port and Eureka ServiceId, which allows you to trace to the specific service. In addition, JHipster Console comes with a default dashboard that allows you to view all services at the same time.

Deployment of production environment to Docker Swarm

Docker Swarm (Docker cluster management tool) uses the same API and Docker Machine (Docker management tool) at the bottom, so using Docker Swarm to publish micro-service applications is the same as publishing them on your local machine. For more documentation on Docker and Docker Swarm, please refer to [Docker Compose documentation] ({{site.url}} / docker-compose/).

Deploy to CloudFoundry

The principle of using [CloudFoundry sub-generator] ({{site.url}} / cloudfoundry/) to build microservices is the same as before, except that you need to deploy more applications:

Get sub-generator to publish your JHipster Registry

To get the url of JHipster Registry, you need to configure this address in your other applications:

In the bootstrap-prod.yml file, set the spring.cloud.config.uri value to http:///config/

In the application-prod.yml file, set the eureka.client.serviceUrl.defaultZone value to http:///eureka/

Publish your gateway applications and micro-service applications

Expand your application

An important point is that JHipster Registry is unprotected by default, and micro-service applications should not be directly accessed through public network access, users can only access your service through the gateway. There are two solutions to this problem:

Protect your Cloud Foundry by using specific routes.

All applications use Https and protect your JHipster Registry by using Spring Security's basic authentication.

Deploy to Heroku

The principle of using [Heroku sub-generator] ({{site.url}} / cloudfoundry/) is the same as before, except that you need to deploy more applications:

You can deploy JHipster Registry on Heroku with one click through the following buttons:

To ensure the security of the registry, please refer to [Heroku sub-generator documentation] ({{site.url}} / heroku/)

After obtaining the address of the registry, all your applications should configure this address in application-prod.yml:

Eureka: instance: hostname: .herokuapp.com non-secure-port: 80 prefer-ip-address: false

Once configured, you can deploy your gateway applications and micro-service applications. Using Heroku sub-generator will ask you for the address of your JHipster Registry, which allows your application to go directly to Spring Cloud Config server to get their configuration.

Note that the above configuration is over the http protocol, but in a production environment, it is recommended to use HTTPS to connect to your JHipster Registry. Because the administrator's password is transmitted through HTTP, it is highly recommended that the communication channel be encrypted through HTTPS.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.