http://m.oschina.net/blog/717852

Summary

JHipsterr_cn Chinese translation group, about the technology stack of SpringBoot, AngularJS and Spring ecological integration -> JHipster recommendation, is the best practice of SpringBoot, the best practice of SpringCloud's technology stack for Netflix, and the best practice of J2EE-Cloud microservices, It is the best practice of Docker, Kubernetes and AngularJS1/2, and it is the ideal tool for full-stack development and agile development

Summary

Microservice Architecture vs Monolithic Architecture

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

Integrated architecture, used to create a single application, including front-end AngularJS code and back-end spring boot related code, all the code in the project is in one application.
The microservice architecture separates the front and back ends. The advantage is that it allows you to easily control the scale of a single application and handle some simple and small problems in these applications.

Relatively speaking, the integrated architecture is easier to get started with. The official website recommends this by default. If you are new to JHipstert, it is recommended to start with this. After you are familiar with it, if the project has requirements, then choose the microservice architecture application.

The following part mainly explains the use of JHipster for microservice architecture.

Overview

The JHipster microservice architecture works as follows:

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

JHipster Registry The registry of JHipster can be obtained All microservice applications and gateways are configured from the registry, so it must be run first.
JHipster's microservice application instances can be directly generated by the generator (select microservice application in the first question), which are the specific implementations of providing services. They are stateless. Several identical instances can be run in parallel at the same time to handle a large number of requests.
JHipster Console , JHipster's console, provides service monitoring and alerting functions, based on the ELK technology stack.

In the diagram below, the green components represent your specific application, and the blue components represent the underlying infrastructure: Doing Microservice

API Gateway for JHipster

JHipster can generate API gateway. This is a normal JHipster application. When using yo jhipster, the first question can be generated. You can develop it like a normal application. It plays the role of an entry point in the microservice architecture, providing http routing, load balancing, api documentation, and functions to ensure service quality and security.

HTTP routing using gateways

Before starting the gateway and service application of JHipster, you need to start the JHipster register project as the registration center. When the application configures the registry address, it only needs to modify eureka.client.serviceUrl.defaultZonethe value corresponding to the key ( 在 src/main/resources/config/application.ymlin the file).

The gateway will automatically proxy all requested services and use the name of the application. For example, when the microservice application APP1is registered in the registry, it can be accessed through the /APP1URL.

As another example, if your gateway is running at http://localhost:8080/app1/rest/fooslocalhost:8080 , you can get resources provided by the microservice APP1 service .foos

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

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

Load balancing with Netflix Ribbon .
Using the circuit breaker mechanism provided by Netflix Hystrix , the hanging running instance can be quickly and safely removed.

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

Safety

JWT (JSON Web Token)

JWT (JSON Web Token) is now an industry standard that is easy to use and can provide security for microservice applications.

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

All toekn are generated by the gateway and delivered to the underlying microservice application. Because they share a common key, the microservice application can verify 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 is the point that guarantees the scalability of microservices, so it is very important.

To keep the service running securely, a token must be shared among all applications:

For each application, its default token is unique and generated by JHipster, which is stored in the .yo - rc.jsonfile
The value of the token can be configured by modifying the value in src /mian/resources/config/application.ymlthe jhipster.security.authentication.jwt.secretfile
A good practice is to use different tokens in production and development

OAuth2

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

JHipster provides a service to generate a "UAA (User Account and Authentication Information)" based on Srping security. This service uses the Oauth2 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 tokens to other underlying microservice applications.

Automatically generate documentation

JHipster's gateway integrates the swagger API, so we can easily use Swagger UIand swagger-codegen. In the "admin> API" menu of the management background, you can see the API of the gateway and all the APIs registered with microservices.

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

request rate limit

This is an advanced feature that requires setting up a Cassandra cluster (which can be easily set up via Docker Compose configuration).

The gateway provides the function of rate limiting, so the number of REST requests can be limited:

By IP address (anonymous users)
User login (login user)

JHipster will use the request data stored by the Cassandra cluster and will send HTTP 429 (Too Many Requests) errors for over-limit requests. The default rate limit per user is 100,000 API calls per hour.

This is an important feature to protect microservices from being overwhelmed by some special user request.

The JHipster register acts as a gate for managing REST interface resources, it has absolute control over the user's security information, so it can be easily extended to provide specific rate limiting based on the user's role.

To enable rate limiting, it application-dev.ymlneeds application-prod.ymlto be configured in or

jhipster:
    gateway:
        rate-limiting:
            enabled: true

Of course, the Cassandra cluster also needs to be built and configured. If you use the configuration of JHipster's Docker Compose ( src/main/dockerin ), it can run normally. If you want to manually set up the cluster yourself, here are some steps to pay attention to:

The first thing to do is to have a working Cassandra cluster.
Need to configure the JHipster-specific speed limit table, related create_keyspace.cqland create_tables.cqlscripts, in the src/main/resources/config/cqldirectory .
The cluster must be configured in the application-*.ymlfile 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 limit the following situations:
Lower the limit for HTTP calls
Add a per-minute or daily limit
Removed all restrictions for "admin" user

access control policy

All registered microservices are accessible through the gateway by default. If you want to exclude specific APIs from passing through the gateway, you can use the gateway's access control filter to control specific access. Configure in the application-*.ymlfile jhipster.gateway.authorized-microservices-endpoints, 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/foointerface be accessible, then you only need to configure the following:

jhipster:
    gateway:
        authorized-microservices-endpoints:
            bar: /api/foo

JHipster's registry

Overview of the JHipster Registry

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

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

In the development environment, run directly ./mvnw, it uses the configuration file in the development environment by default, and Eureka Registry will be accessible through http://127.0.0.1:8761/ .
In a production environment, use ./mvnw -Pprod to package and generate an executable WAR file.

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

Run docker-compose -f src/main/docker/jhipster-registry.yml upto start JHipster Registry. Then Eureka Registry will listen to your port 8761, which can be accessed through http://127.0.0.1:8761/

For more questions about docker and the JHipster Registry, see the docker Compose documentation

Security of the JHipster Registry

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

Of course, the microservice application is also registered on the Registry with the role of admin, but it is authenticated by HTTP Basic. So if your microservice application can't connect to the registry, you'll get a "401 authentication error" error message because you configured something wrong.

To secure the JHipster Registry:

You must change the admin password. This password can be implemented by modifying the corresponding value in the Spring boot application-*.ymlfile security.user.password, or you can create a new SECURITY_USER_PASSWORDenvironment variable. In the Docker Compose sub-generator , this variable is used.
Because your application is connecting to the Registry via HTTP, it is important to secure the connection channel, and one of the simpler ways is to use HTTPS.

Register your app on JHipster

JHipster Registry uses Netflix Eureka server and Spring Config Server . When the microservice application and/or the microservice gateway are started, they will first connect to the JHipster Registry to obtain configuration information.

These configurations refer to the configuration of spring boot, that is, application-*.ymlfiles . 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 files they originally stored locally.

The following two kinds of configuration information are available:

The local configuration file in the development environment (using the dev profile), using the local file system.
git configuration information, used in a production environment (using the JHipster prod profile), is stored in the git service. Using git, you can create tags, branches, or roll back configuration information, which is very useful in production environments.

In order to centrally manage the configuration of microservices, you need to create a configuration file in application-*.ymlthe format of and put it under the config file of the Registry. It is required that appname and profile correspond to your microservice application with the same name and profile.

For example, adding a gateway-prod.ymlfile will use the production configuration file for all applications named gateway. Additionally, the definitions in the application[-dev|prod].ymlconfiguration will take effect for all applications.

The gateway routes mentioned above are configured through Spring boot, but they can also be managed through Spring Config Server. For example, you v1can routeapp1-v1 your app to the url on the fork, and route to the url on the fork. This is a great way to seamlessly upgrade your microservices so that you can upgrade without having to stop the service./applv2app1-v2/app1

Create a microservice application

The microservice application instance can be generated by JHipster without a front end (the generated microservice gateway will have a front end, which uses angularJS), and it can run normally only with the JHipster Registry.

Generate entity objects for microservice applications

When using entity sub-generator to generate an entity in a microservice application, it is a little different from the way of generating an entity in an integrated architecture application, because the microservice realizes the separation of front and back ends, and the backend of the microservice application only needs to provide an interface, no need front-end code, so it doesn't need to generate front-end code.

First, to generate entities in microservice applications, you can use the method of generating entity objects in integrated applications, or you can use JHipster UML or JDL Studio to generate more complex entities and relationships. Of course this doesn't generate AngularJS code.

Then, in the microservice gateway application, running the entity sub-generator again , there will be one more problem at the beginning, which is specifically for the gateway application:

There are two options: either generate a new entity as you normally would in a monolithic application (the microservice gateway application itself is a complete JHipster application, which is a bit like a monolith in this respect), or It is generated using the existing JHipster configuration information.
If you choose the latter, you need to enter the path of the microservice application, and then JHipster will generate the front-end code on the gateway (equivalent to managing the microservice application entity through the page in the gateway application).

Distributed caching with HazelCast

If your application uses an SQL database, JHipster provides different solutions for microservices that support L2 cache:

JHipster's default microservice caching solution is Hazelcast
You can also use Ehcache (the default solution supported by all-in-one applications), or not use caching at all.

The default Hazelcast solution supports microservices, which can well support you to extend services:

With a local cache, you are a single service without a cache that can be synchronized, which can lead to data inconsistencies.
Without using any cache, with the expansion of the service, the burden of the system is placed on the database, which is not a good solution.

Using Hazelcast for caching requires some special configuration:

At startup, the application will connect to the JHipster registry service and find the same service instance as him.
- If devprofile is used, JHipster will create a cluster of these instances 127.0.0.1on , using a different port for each instance. By default, the Hazelcast port is 你的应用程序的端口+ 5701(so if your application's port is 8081, Hazelcast will use the port 13782)
- If prodprofile is used, JHipster uses all other nodes it finds to build a cluster, using Hazelcast's default port ( 5701)

Microservice application without database

Only microservice applications can create database-less programs. This is because microservice applications can be small and can have no user-managed code.

A microservice application without a database is small enough to connect to a legacy backend system.

Using Docker Compose

Developing a system of microservices 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 we have a dedicated document to introduce the Docker Compose documentation , we strongly recommend reading this article to familiarize yourself with this knowledge before developing a system with a microservice architecture.

Use JHipster Console and ELK stack to monitor services

When you use the docker-Compose sub-generator, you will be asked if you need to add monitoring to your application. If yes, it will add JHipster-Console under your docker-compose.ymlfile . When you start the system, you can get the logs and various indicators of the system by visiting http://localhost:5601 . For more on monitoring, see the monitoring documentation

Compared to monolithic applications, gateways and microservice monitors provide some additional features that can help you effectively monitor microservice clusters. For example, looking at the log, it can be specific to the application name, host, port and Eureka ServiceId for the log, which allows you to track the specific service. Additionally, JHipster Console comes with a default dashboard that lets you view all services at the same time.

Production Environment

Deploy to Docker Swarm

Docker Swarm (Docker cluster management tool) uses the same underlying API as Docker Machine (Docker management tool), so using Docker Swarm to publish microservice applications is the same as publishing on your local machine. For more documentation on Docker and Docker Swarm see the Docker Compose documentation .

Deploy to CloudFoundry

The application principle of using the CloudFoundry sub-generator to build a microservice is the same as before, but you need to deploy more applications:

Make sub-generator publish your JHipster Registry
To get the url of the JHipster Registry, you need to configure this address in your other applications:
- In the bootstrap-prod.ymlfile , set the spring.cloud.config.urivalue tohttp://<your_jhipster_registry_url>/config/
- In the application-prod.ymlfile , set the eureka.client.serviceUrl.defaultZonevalue tohttp://<your_jhipster_registry_url>/eureka/
Publish your gateway application and microservice application
Extend your application

An important point is that the JHipster Registry is unprotected by default, and microservice applications should not be accessed directly through the external network. Users can only access your services through the gateway. There are two solutions to this problem:

Secure 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 the Heroku sub-generator is the same as before, except that you need to deploy more applications:

The JHipster Registry can be deployed on Heroku with one click via the button below:

To secure the registry, please refer to the Heroku sub-generator documentation

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

eureka:
    instance:
        hostname: <your_jhipster_registry_url>.herokuapp.com
        non-secure-port: 80
        prefer-ip-address: false

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

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

http://my.oschina.net/u/2501062/blog/717852