JHipster是一个开发平台，用于创建、开发、部署Spring Boot + Angular/React/Vue架构的Web应用或Spring微服务应用。它的目标是自动化生成一个完整和现代化的Web应用或微服务应用，整合了：
- 基于Spring Boot框架的服务端，具备高性能和高可用的Java技术栈
- 基于Angular，React和Bootstrap的时尚、现代、移动端优先的前端
- 基于JHipster Registry，Netflix OSS，ELK和Docker的微服务架构
- 使用Yeoman，Webpack和Maven/Gradle构建应用程序的工作流程
Overview
JHipster微服务架构如下图所示(绿色组件为自定义应用，蓝色组件为平台提供的基础架构)：
Gateway：网关，基于JHipster生成的一个应用，用于处理Web请求并且提供了一个前端Angular应用。如果采用“后端服务前端的模式”，那么可以考虑使用多个网关
Traefik：反向代理和负载均衡，可与网关一起使用
JHipster Registry：注册中心，一个运行时应用程序，所有应用都可以在其上注册并获取其配置。另外，还提供了运行时监控面板
Consul：用于服务发现 或 Key/Value存储；也可以替代JHipster Registry作为注册中心
JHipster UAA：基于JHipster的用户认证和授权，使用OAuth2协议
JHipster Console：基于ELK技术栈的监控和报警控制台
Microservices：基于JHipster生成的应用，用于处理REST请求。这些微服务是无状态的，并且某些微服务可以启动多个实例以应对高负载
API Gateway
网关会通过应用名称代理所有指向后端微服务的请求。例如，微服务app1成功注册后，可在网关中通过*/app1访问；假设网关跑在localhost:8080，那么可以通过http://localhost:8080/app1/rest/foos*去获取微服务*app1*提供的*foos*资源。它实际上利用Netflix Zuul实现路由功能
网关实际上利用Netflix Ribbon实现负载均衡
网关实际上利用Netflix Hystrix实现服务熔断
可以使用JWT或OpenID Connect实现安全相关的需求，但是后者需要额外配置一些内容以避免性能下降和应用间认证不同步的问题
基于Spring Security的UAA服务器提供Oauth2令牌以保护网关，网关使用”Spring Security的JWT实现“将JWT令牌发送到微服务
网关公开了它自身以及所代理服务的Swagger API定义，可以利用Swagger UI或swagger-codegen等工具提高开发效率；
网关提供限制速率的功能，可以通过以下两种方式限制REST请求数：
- 通过IP地址(匿名用户)
- 通过用户登录(已登录用户)
JHipster使用Bucket4j 和 Hazelcast 计算请求数量，达到限制时会发送HTTP 429错误；默认限制为：每个用户每小时10W次API调用
默认所有已注册的微服务都可通过网关访问。可通过修改以下配置项实现访问应用“bar”时仅能访问“/api/foo”
1
2
3
4jhipster:
gateway:
authorized-microservices-endpoints:
bar: /api/foo
Traefik
- 用于HTTP反向代理和负载均衡
- 可以像Zuul一样路由HTTP请求，因此在路由上与网关的功能重叠，但比网关的层次要低：仅提供路由HTTP请求，不提供速率限制、安全性、Swagger文档聚合
- 在JHipster中，Traefik默认与Consul一起使用——这提供了一种不同的服务发现解决方案
- 可在两种不同的架构中使用
- 取代Zuul，直接路由HTTP请求至相应的服务；在这种架构中，“网关”仅提供前端Angular应用；这是默认配置
- Traefik和Zuul一起使用，HTTP请求会先经过Traefik，再经过Zuul，最后到达终端服务；
- 由于这种形式下会多一次网络请求过程，因此效率会比第一种低；但这种形式可以使用网关提供的速率限制或Swagger文档聚合功能；
- 可作为边缘服务用于扩展网关，这种情况下客服端应用需要使用绝对URL
JHipster Registry
- 三个主要作用
- 作为Eureka Server，提供服务发现功能，这也是JHipster能处理路由、负载均衡、为应用提供可扩展性的原因
- 作为Spring Cloud Config Server，为所有应用提供运行时配置的功能
- 作为管理服务器，提供监控和管理应用的面板
- 监控面板
- 指标面板：包含the JVM、HTTP requests、cache usage、database connection pool
- 健康检查面板：应用运行状态(up/down)
- 配置面板：查看应用配置的详细信息，使用Spring Boot Actuator实现
- 日志面板：允许在运行时更改应用程序的Logback配置
Consul
- 替代JHipster Registry作为注册中心，它与Eureka相比具有以下优势：
- 在多节点集群中操作更容易
- 一致性优先于可用性，因此可以集群中状态的变化可以更快地传播
- 服务发现可以通过DNS Interface或HTTP API与已存在的应用进行简单交互
JHipster UAA
UAA，User Account and Authentication
- Authentication(认证)和Authorization(授权)的区别
Authentication = login + password(who you are)
- Authorization = permissions(what you are allowed to do)
微服务架构的安全性要求
- 统一认证——微服务间的鉴权过程对用户应该是无感的
- 无状态化——微服务的核心价值是可扩展，任何解决方案都不应该影响这一点。服务器端保存用户的session状态不太友好
- 用户/机器的访问控制——对不同的用户/机器进行相应的访问范围控制
- 细粒度的访问权限控制——微服务无需进行用户识别，仅仅对传入的请求进行授权操作
- 免受攻击性——尽可能地抵御漏洞
- 可伸缩性——无状态协议无法保证安全性；避免单点故障
该设计可以应用到独立于语言或框架的任何微服务架构
- 每一个访问任何端点的请求都是通过“client”完成的
- “client”是一个抽象的集合，例如，“Angular $http client”、“REST-Client”、“curl”以及其它任何能完成请求的形式
- “client”可以与用户认证共同使用，例如，前端客户端应用中的Angular $http
- 每一个微服务都作为资源服务器提供被访问资源
- 蓝色箭头表示在OAuth认证服务器上进行客户端认证
- 绿色箭头表示通过客户端完成在资源服务器上的请求
- UAA服务器同时充当认证服务器和资源服务器
- UAA服务器是微服务应用内部所有数据的拥有者（自动授权访问资源服务器）
- Clients通过使用存储在网关配置文件中的client ID和secret作为”password grant”实现认证，从而去访问资源
- Clients使用“client credential grant”实现认证，从而达到不使用用户名去访问资源的目的
- 每一个client都在UAA内部定义(web-app，internal，……)
以下规则可被用于访问权限控制：