JHipster微服务架构

摘要

1. 微服务架构 vs 一体化架构
2. 概览
3. JHipster 的API 网关

• 使用网关进行HTTP路由
• 安全
• 自动生成文档
• 请求速率限制
• 访问控制策略

4. JHipster 的注册中心

• JHipster 注册中心概览
• JHipster 注册中心的安全保障
• 在JHipster 上注册你的应用

5. 建立微服务应用

• 为微服务应用生成实体对象
• 使用HazelCast作分布式缓存
• 不带数据库的微服务应用

6. 使用 Docker Compose
7. 使用JHipster Console 和ELK技术栈来监控服务
8. 生产环境

• 部署到 Docker Swarm
• 部署到 CloudFoundry
• 部署到 Heroku

微服务架构 vs 一体化架构

使用 JHipster 生成应用时，第一个问题就是让你选择你要的生成的应用(目前有4个选项)，但实际上你是在两种架构风格里面作选择：

• 一体化架构，用来建立单独的一个应用，包含前端 AngularJS 代码和后端 spring boot 相关代码，项目中全部代码都在一个应用中。
• 微服务架构，进行了先后端分离，优势是它可让你很容易的控制单个应用的规模，并处理好这些应用中一些简单细小的问题。

相对来讲，一体化架构是比较容易上手，官网默认推荐这个，若是是刚接触 JHipstert，建议从这个入手，熟悉后，若是项目有要求，则再选择微服务架构应用。

下面部分则主要讲解下使用JHipster进行微服务架构。

概览

JHipster 微服务架构的工做方式以下：

• JHipster gateway ，是一个能够经过生成器直接生成的(在第一个问题里面选择 microservice gateway)完整应用，包含来服务端和前端，用来处理web请求。一个微服务架构里面能够同时有几个网关，若是你遵循 Backends for Frontends pattern这种模式，固然这不是强制性的。

• JHipster Registry JHipster的注册中心，能够在github上 获取，全部的微服务应用和网关都是从注册中心获取配置，因此它必需要先运行起来。

• JHipster的微服务应用实例，能够经过生成器直接生成(在第一个问题里面选择microservice application)，它们是提供服务的具体实现。它们是无状态的。能够同时并行运行好几个相同的实例，来处理海量的请求。

• JHipster Console，JHipster的控制台，提供了服务监控和警报的功能，基于ELK 技术栈。

在下图中，绿色的组件表明你的特定应用，蓝色组件表明的底层基础架构：

JHipster 的API 网关

JHipster 能够生成API gateway。 这是一个普通的JHipster 应用,在使用yo jhipster时第一个问题能够选择生成，你能够像开发一个普通应用来开发它。它在微服务架构中扮演一个入口的角色，提供了http 路由，负载均衡，api 文档、保障服务质量和安全的功能。

使用网关进行HTTP路由

JHipster 的网关和服务应用启动以前，须要先启动 JHipster register 项目做为注册中心。应用在配置注册中心地址时候，只须要修改 eureka.client.serviceUrl.defaultZone key 对应的值 （在 src/main/resources/config/application.yml 文件中）。

网关将自动代理全部请求的服务，并沿用应用程序的名称，例如：当微服务应用APP1在注册中心注册后，能够经过/APP1网址来访问。

再举个例子，若是你的网关运行在localhost:8080，你能够经过 http://localhost:8080/app1/rest/foos 得到经过微服务APP1服务提供的的foos资源。

另外，JHipster中REST接口资源都是受保护的，在经过浏览器访问这些接口时，你须要带上正确JWT(在请求头的header上，下面安全章节的时候还会在提到)，或在MicroserviceSecurityConfiguration类中注释掉相关代码。

若是有多个相同的服务实例在同时运行，网关能够从JHipster的注册中心获取这些实例，而且：

• 使用 Netflix Ribbon 进行负载均衡。

• 采用 Netflix Hystrix 提供的熔断机制，这样能够将挂的运行实例快速安全地移除。

每一个网关应用都提供了http 路由和服务实例监控的功能，在后台"管理员>网关"菜单中能够看到。

安全

JWT (JSON Web Token)

JWT（JSON网络令牌）是如今的一个业界标准，简单易用，能够为微服务应用提供安全保障。

JHispter使用 JJWT library 库，由Stormpath提供，用来实现具体的jwt。

全部的toekn都由网关生成，并传送给底层微服务应用。由于它们共享一个公共的密钥，因此微服务应用可以验证该令牌，而且使用该令牌认证用户。

这些令牌是自给自足的：它们具备认证和受权的信息，因此微服务应用不须要查询数据库或外部系统。这是点保证了微服务的可扩展性，因此很重要。

为了保证服务的安全运行，一个token必须在全部应用程序之间共享：

• 对于每一个应用，其默认的token是独一无二的，并经过JHipster产生，被存储在 .yo - rc.json 文件

• 令牌的值能够经过修改在 src /mian/resources/config/application.yml 文件中的 jhipster.security.authentication.jwt.secret 的值来进行配置

• 一个好的实践是在生产环境和开发环境采用不一样的token

OAuth2

此功能目前处于 BETA 阶段，所以它的文档尚未完成。

JHipster提供生成一个基于Srping security 的"UAA(用户帐号和认证信息)"的服务 。这项服务采用Oauth2 token机制，来保证服务网关的安全。

在这基础上，服务网关利用Spring Security对jwt的支持来传递token给其它底层的微服务应用。

自动生成文档

JHipster 的网关整合了swagger API，因此咱们能够很方便的使用 Swagger UI 和 swagger-codegen。在管理后台的"admin> API"的菜单中，能够看到网关的API，以及全部注册了微服务的API。

经过下拉列表，能够查看有Swagger 生成的API文档，这些API均可以在线测试。测试的时候token会自动添加到Swagger UI 的接口中去，因此全部的请求都是在沙盒外进行。

请求速率限制

这是一个高级功能，须要创建一个Cassandra 集群（经过Docker Compose configuration 能够比较容易的搭建起来）。

网关提供限速的功能，因此REST请求的次数能够被限制：

• 经过IP地址（匿名用户）

• 用户登陆（登陆用户）

JHipster将使用Cassandra 集群存储的请求数据，而且对超出限制请求将发送HTTP 429 （太多请求）错误。每一个用户的默认限速为每小时10万API调用。

这是一个重要的功能，能够保护微服务不被一些特殊的的用户请求拖垮服务器。

JHipster register 做为一个管理 REST 接口资源的关卡，它对用户的安全信息拥有绝对控制权，所以它能够很容易扩展，以提供根据用户角色来进行特定速率限制。

为开启速率限制，须要在 application-dev.yml 或 application-prod.yml 中进行配置

jhipster:
    gateway:
        rate-limiting:
            enabled: true

固然 Cassandra 集群也须要搭建并配置好. 若是采用 JHipster’s Docker Compose 的配置(在 src/main/docker 中)，则能够正常运行。想本身手动设置群集，这里有些步骤要注意下：

• 首先要有一个可用的Cassandra集群。

• 须要配置好JHipster特定的限速表，相关的 create_keyspace.cql 和 create_tables.cql 脚本，在 src/main/resources/config/cql 目录下。

• 该群集必须在 application-*.yml文件中进行配置，其对应的键为spring.data.cassandra（已生成了默认配置）

若是你想添加更多的规则，或修改现有规则，你须要修改RateLimitingFilter类。好比说，若是你要进行如下状况的限制：

• 下降HTTP调用的限制

• 添加每分钟或每日限制

• 删除了"管理员"用户的全部限制

访问控制策略

默认状况下全部已注册的微服务均可以经过网关访问。若是你想从经过网关排除特定的API ，你可使用网关的访问控制过滤器来对具体的访问进行控制。在 application-*.yml 文件中对 jhipster.gateway.authorized-microservices-endpoints 进行配置，默认配置为：

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

若是你只想微服务bar的 /api/foo 接口能够被访问，那么你只须要进行以下配置：

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

JHipster 的注册中心

JHipster 注册中心概览

JHipster Registry 是一个可运行的应用，由JHipster 的团队开发。和JHipster generator同样，也是开源的，遵循Apache 2-licensed，也放在github上，点此查看。

能够在github上clone或者下载Registry的源码，若是使用了JHipster generator，则建议使用使用和它相同tag的Registry，它的运行方式和其它的应用同样：

• 开发环境下，直接运行 ./mvnw，它默认采用开发环境下的配置文件，Eureka Registry 将能够经过 http://127.0.0.1:8761/ 进行访问。

• 生产环境下，使用./mvnw -Pprod打包生成可执行WAR文件。

若是想经过docker镜像来运行JHipster Registry，Docker Hub 中也有提供，在JHipster Registry，固然这个镜像是预先配置好。

• 运行 docker-compose -f src/main/docker/jhipster-registry.yml up 来启动JHipster Registry. 而后 Eureka Registry 就会监听你8761 端口 , 由此即可以经过 http://127.0.0.1:8761/ 来访问

更多关于docker和JHipster Registry的问题，能够参见[docker Compose documentation ]({{ site.url }}/docker-compose/)

JHipster 注册中心的安全保障

JHipster Registry 默认是受保护的，须要使用帐户和密码来登录，默认帐号密码为"admin/admin"。

微服务应用固然也是以admin的角色在Registry上进行注册，可是是经过HTTP Basic 认证。因此若是你的微服务应用不能链接到注册中心，你会收到"401 authentication error"的错误信息，由于你配置错了某些东西。

为了保障JHipster Registry 的安全：

• 你必须修改admin的密码。此密码能够在Spring boot 的 application-*.yml 文件中经过修改 security.user.password 对应的值来实现，或者你也能够新建一个 SECURITY_USER_PASSWORD 环境变量。在[Docker Compose sub-generator]({{ site.url }}/docker-compose/)中，用到了这个变量。

• 由于你的应用程序是经过HTTP链接到Registry，因此保障链接通道的安全性很重要，其中一个比较简单的方式是采用HTTPS。

在JHipster 上注册你的应用

JHipster Registry 是采用了 Netflix Eureka server 和 Spring Config Server。 当微服务应用和或者微服务网关启动的时候，它们会首先链接到JHipster Registry去获取配置信息。

这些配置是指spring boot 的配置，也就是 application-*.yml 文件。但它们存储在中央服务器上，易于管理。

当整个服务启动时，微服务应用或者网关会从Registry上获取服务的配置信息而且覆盖它们原来存储在本地的配置文件。

如下两种配置信息是能够用的：

• 开发环境下的本地配置文件（使用 dev profile），使用本地的文件系统。

• git 配置信息，用在生产环境下（使用 JHipster prod profile），存储在git 服务中。使用git能够创建tag、分支，或者回滚配置信息，这是生产环境下很是实用。

为了集中管理微服务的配置，你须要按照 application-*.yml 的格式建立配置文件，并放在Registry 的config 文件下。要求 appname 和 profile 你的微服务应用同名和profile对应。

举个例子，添加了一个 gateway-prod.yml 文件将对全部的名为gateway的应用采用生产环境下的配置文件。此外，定义在 application[-dev|prod].yml 配置将对全部的应用产生效果。

上面提到网关路由是经过Spring boot 来配置，它们其实也能够经过Spring Config Server 来管理。举个例子，你能够在 v1 分支上，将应用 app1-v1 路由到 /appl 的url上，而在 v2 分支，将 app1-v2 路由到 /app1 的url上。这是一种无缝升级微服务的好方式，以达到不须要中止服务就能够升级的效果。

建立微服务应用

微服务应用实例是能够经过 JHipster 生成的，没有前端（生成的微服务网关会有前端，用到了angularJS ），它要配合着 JHipster Registry 才能正常运行。

为微服务应用生成实体对象

在用 [entity sub-generator]({{ site.url }}/creating-an-entity/)为微服务应用中生成entity时，和在一体化架构应用中生成entity的方式有点不同，由于微服务实现了先后端分离，微服务应用后台只须要提供接口，不须要前端代码，所以它也就不须要生成前端代码。

首先，在微服务的应用中生成实体，能够采用在一体化应用中生成实体对象的方法，也可使用 [JHipster UML]({{ site.url }}/jhipster-uml/) 或者 [JDL Studio]({{ site.url }}/jdl-studio/) 来生成更加复杂的实体以及关系。固然这不会生成AngularJS代码。

而后，在微服务网关应用中，再次运行[entity sub-generator]({{ site.url }}/creating-an-entity/)，会在开始时多出一个问题，这是专门针对网关应用的：

• 有两个选项：要么像在一体化架构应用中生成实体方式那样，正常生成一个新的实体（微服务网关应用自己是一个完整的 JHipster 应用，这点上它有点像是个一体化应用），要么是利用已有的 JHipster 配置信息来生成。

• 若是选择后者，你须要输入微服务应用的路径，而后 JHipster 会产生网关上的前端代码（至关因而在网关应用中经过页面来管理微服务应用实体）。

使用HazelCast作分布式缓存

若是你的应用采用了 SQL 的数据库，JHipster 针对微服务 给出了不一样的，支持二级缓存的解决方案：

• JHipster 的默认微服务缓存解决方案是采用 Hazelcast
• 你也能够采用 Ehcache(一体化应用默认支持的方案) ，或者干脆不适用缓存。

默认的 Hazelcast 解决方案是支持微服务的，它能够很好的支持你拓展服务：

• 使用本地缓存，你是单个服务没有一个能够同步的缓存，可能致使数据不一致。

• 不使用任何缓存，随着服务的拓展增长，系统的负担都放到来数据库，这也不是个很好的方案。

采用 Hazelcast作缓存，须要作些特别的配置：

• 在启动时，应用程序会链接到 JHipster 注册服务中，找到和他相同的服务实例。
• 若是使用了 dev profile，JHipster 将在本地主机上 127.0.0.1 上建立这些实例的群集 ，使用每一个实例不一样的端口。默认状况下， Hazelcast端口是 你的应用程序的端口+ 5701 (因此若是你的应用程序的端口是 8081，Hazelcast将使用端口 13782)
• 若是使用了 prod profile，JHipster 用它找到的全部其余节点来构建一个群集，使用Hazelcast默认的端口 (5701)

不带数据库的微服务应用

只有微服务应用能够建立无数据库的程序。这是由于微服务应用能够很小，能够没有用户管理的代码。

一个没有数据库的微服务应用很小，可用于链接到一个遗留的后端系统。

使用 Docker Compose

开发微服务系统，意味着你可能须要在几个不一样的 services 和 databases 上同时工做，而 Docker Compose 则是一个针对此状况，管理开发，测试和生产环境的绝佳工具。

为此咱们有一篇专门的文档来介绍 [Docker Compose documentation]({{ site.url }}/docker-compose#microservices) ，咱们强烈建议在开发微服务架构的系统前阅读这篇文章，熟悉这方面的知识。

使用JHipster Console 和ELK技术栈来监控服务

当你使用 docker-Compose sub-generator 的时候，会询问你是否须要为你的应用添加监控。若是选择是，它将会在你的 docker-compose.yml 文件下添加 JHipster-Console。当你启动系统后，就能够有经过访问 http://localhost:5601 来获取系统应的日志和各类指标。更多关于监控的东西，能够参见 monitoring documentation

对比一体化应用，网关和微服务监视器提供了一些额外的功能，能够帮助你有效地监控微服务集群。例如查看日志，它能够具体到日志对于的应用程序的名称，主机，端口和Eureka ServiceId ，这样可让你追踪到具体的service。此外，JHipster Console带有默认的仪表板，让你在同一时间查看全部的服务。

生产环境

部署到 Docker Swarm

Docker Swarm (Docker 集群管理工具) 底层使用的API 和Docker Machine (Docker管理工具) 是同样的，因此使用Docker Swarm 发布微服务应用和在你本机上发布是同样的。更多关于Docker和Docker Swarm的文档请参考 [Docker Compose documentation ]({{ site.url }}/docker-compose/)。

部署到 CloudFoundry

使用 [CloudFoundry sub-generator]({{ site.url }}/cloudfoundry/) 搭建为微服务的应用原理和以前是同样的，只是你须要部署更多的应用：

• 使 sub-generator 发布你的 JHipster Registry

• 拿到JHipster Registry 的url,你须要在你的其它应用里面配置这个地址：

  • 在 bootstrap-prod.yml 文件中，设置 spring.cloud.config.uri 值为 http://<your_jhipster_registry_url>/config/

  • 在 application-prod.yml 文件中，设置 eureka.client.serviceUrl.defaultZone 值为 http://<your_jhipster_registry_url>/eureka/

• 发布你的网关应用和微服务应用

• 拓展你的应用

一个重要的点是 JHipster Registry 默认是不受保护的，而微服务应用也不该该直接经过外网访被访问到，用户只有经过网关才能访问到你的服务。针对此问题有两种解决方案：

• 经过使用特定的路由来保护你的的 Cloud Foundry。

• 所有应用都使用 Https，并经过使用 Spring Security 的 basic authentication 来保护你的 JHipster Registry。

部署到 Heroku

使用 [Heroku sub-generator]({{ site.url }}/cloudfoundry/) 的原理和以前也是是同样的，只是你须要部署更多的应用：

经过下面的按钮能够在 Heroku 上一键部署 JHipster Registry：

为了保障注册中心的安全，请参考 [Heroku sub-generator documentation]({{ site.url }}/heroku/)

在获取注册中心的地址后，你的所有应用都要在 application-prod.yml 中配置这个地址：

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

配置好后你就能够部署你的网关应用和微服务应用。使用 Heroku sub-generator 会询问你 JHipster Registry 的地址，这个可让你的应用程序直接到 Spring Cloud Config server 上获取它们的配置。

注意 以上的配置是经过http协议，可是在生产环境上，建议使用HTTPS来链接到你的JHipster Registry。由于管理员的密码是经过HTTP来进行传输的，因此极力建议经过HTTPS来加密通讯通道。

欢迎扫码加入咱们,内有大量资料,翻译,视频,文档.欢迎加入咱们GITHUB翻译组