JHipster微服务架构是怎样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
网站的建设创新互联公司专注网站定制,经验丰富,不做模板,主营网站定制开发.小程序定制开发,H5页面制作!给你焕然一新的设计体验!已为电动窗帘等企业提供专业服务。
微服务架构 vs 一体化架构
使用 JHipster 生成应用时，第一个问题就是让你选择你要的生成的应用(目前有4个选项)，但实际上你是在两种架构风格里面做选择：
相对来说，一体化架构是比较容易上手，官网默认推荐这个，如果是刚接触 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的注册中心获取这些实例，并且：
每个网关应用都提供了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
OAuth3
此功能目前处于 BETA阶段，因此它的文档还没有完成。
JHipster提供生成一个基于Srping security 的"UAA(用户账号和认证信息)"的服务 。这项服务采用Oauth3 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请求的次数可以被限制：
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 中)，则可以正常运行。想自己手动设置群集，这里有些步骤要注意下：
如果你想添加更多的规则，或修改现有规则，你需要修改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，它的运行方式和其它的应用一样：
如果想通过docker镜像来运行JHipster Registry，Docker Hub 中也有提供，在JHipster Registry，当然这个镜像是预先配置好。
更多关于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上获取服务的配置信息并且覆盖它们原来存储在本地的配置文件。
以下两种配置信息是可以用的：
为了集中管理微服务的配置，你需要按照 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/)，会在开始时多出一个问题，这是专门针对网关应用的：
使用HazelCast做分布式缓存
如果你的应用采用了 SQL 的数据库，JHipster 针对微服务 给出了不同的，支持二级缓存的解决方案：
默认的 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/) 搭建为微服务的应用原理和之前是一样的，只是你需要部署更多的应用：
一个重要的点是 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: .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来加密通信通道。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。
文章名称：JHipster微服务架构是怎样的
本文来源：
http://cdkjz.cn/article/ggsjcd.html
