[一] 更新说明
在前后端分离架构中,使用 Token 进行身份认证和授权,几乎是现代 Web 开发的事实标准。常见的 Token 类型有:JWT Token(自包含 Token)和 Opaque Token(不透明 Token),各自的优劣势对比如下:
| 维度 |
JWT Token(自包含 Token) |
Opaque Token(不透明 Token) |
| 结构 |
结构化,可解码读取 claims |
无规则随机字符串,对外完全不透明 |
| 验证依赖 |
资源服务器本地即可完成签名验证 |
必须同步调用授权服务器内省接口 |
| 性能/延迟 |
极低,无远程调用,适合高并发 |
每次请求增加一次网络往返,增加延迟和授权服务压力 |
| 可扩展性 |
天然支持水平扩展,无中心节点瓶颈 |
授权服务可能成为瓶颈,需引入缓存层减轻负载 |
| 用户信息携带 |
可在令牌内直接携带常用属性和权限,减少额外查库 |
不携带信息,资源服务器需另行查询或依赖内省返回的数据 |
| 即时撤销能力 |
极弱。令牌签发后,在过期前无法使其提前失效,除非引入额外的黑名单/撤销列表机制(此时丧失无状态优势) |
强。只要在授权服务器侧将令牌标记为失效,下一次内省即返回无效,即时生效 |
| 信息泄露风险 |
Payload 默认仅 Base64URL 编码,任何人拿到令牌都能解码看到其内容。若误将敏感信息放入 payload,极易泄露 |
完全不暴露内部信息,令牌本身就是个指针,对客户端/中间人无意义 |
| 令牌体积 |
较大,通常几百字节甚至上千字节(尤其携带较多 claims 时),HTTP Header 负担较重 |
体积很小,固定长度随机串,几十字节 |
| 签名/密钥管理 |
需要管理签名密钥,非对称签名下需要分发公钥,对称签名下密钥共享有安全风险 |
资源服务器仅需持有调用内省 API 的凭证(client_id/client_secret),密钥管理相对集中 |
| 标准化与互操作 |
标准成熟(RFC 7519),跨系统、跨语言互操作性强,非常适合分布式微服务间传递信任 |
依赖 OAuth 2.0 内省规范(RFC 7662),但比 JWT 更依赖中心服务的实现细节 |
| 过期控制 |
在签发时设定 exp,到期自然失效;难以实现“用完即失效”的一次性令牌 |
可由授权服务器完全掌控,随时可修改过期策略或强制撤销 |
| 使用成本 |
序列化/反序列化及验签有一定 CPU 开销,但省去了远程调用开销 |
CPU 开销极低,但网络调用开销和授权服务压力是主要成本 |
Dante Cloud 之前的版本中,虽然一直也是支持 JWT Token 和 Opaque Token 两种 Token,但是由于 Spring Security Resources Server 配置的限制,仅能在同一时间使用其中一种 Token,需要通过修改配置才能修改所需使用的 Token 类型。
v4.0.6.3 版本对 Token 颁发配置做了大幅重构,实现在无需修改配置和重启服务的情况下,通过界面动态修改不同 客户端 对应颁发 Token 的类型,用户可以更加灵活的根据不同的场景,使用不同类型的 Token。
注意事项:
- 如果改用 JWT Token,那么
单一类型终端允许最大登录数限制、同一账户的用户踢出 等安全管控功能将失效。
- 相对于 Opaque Token 来说,JWT Token 安全性较低。需要结合自己的应用场景以及安全性需求,合理的选择使用 JWT Token 还是 Opaque Token
[二] 更新日志
- 主要更新
- [新增] 前端新增创建物模型功能页面
- [新增] 可通过前端界面配置更改 OAuth2 Token 格式,无需再通过配置文件方式更改 Token 格式
- [新增] 新增 JWT Token 和 Opaque Token 同时配置方法,通过动态判断请求中 Token 类型,灵活选择对应的应用逻辑
- [新增] (新开源) Influxdb 3 集成
- [新增] (新开源) 基于 Spring Integration 的 Mqtt 集成
- [新增] (新开源) 基于 Spring Integration 的 Emqx 集成
- [新增] (新开源) 多种类型消息统一聚合发送
- [升级] Pnpm 版本升级至 v11,提升安装效率减少本地碎片文件。Nodejs 需要使用 v22 及以上版本。
- 其它更新
- [新增] 新增 Token 格式自定义属性,方便在客户端动态注册时指定 生成的 Token 格式
- [新增] 适配 Spring Security 7.X,新增 OAuth2 客户端自动注册功能,支持物联网自定义 Product Key 属性
- [新增] 新增 Mqtt 签名算法及校验逻辑
- [新增] 新增物模型数据单位全部查询接口
- [重构] 自定义 AccessToken 解析器改用动态判断方式,将 JWT Token 和 Opaque Token 解析融合
- [重构] InfluxDB java 客户端替换为 influxdb3-java,删除 InfluxDB 1 和 2 相关模块,新增 InfluxDB 3 模块
- [重构] 规范 OAuth2 相关自定义 Interface 代码所在包,降低代码包归类混乱
- [重构] 重构响应式基础接口继承关系和基础方法定义,提供更便捷的相应结果封装方法
- [修复] 修复 OSS 模块单体模式下无法启动的问题,将条件注解常量路径从 PROPERTY_PREFIX_OSS 对齐为 PROPERTY_ASSISTANT_OSS。【PR by 凤文Coding】
- [修复] 修复客户端动态注册会将默认的的 AccessToken 格式指定为 JWT Token 问题
- [修复] 修复 ThingsBrain 模块 Import 配置类错误
- [修复] 修复前端验证码错误信息显示方式,避免多种错误提示同时显示
- [修复] 修复代码包名拼写错误
- [优化] 优化 OAuth2 客户端动态注册请求和响应实体参数注释,明确必要和非必要参数
- [优化] 优化 axios 封装,更好地支持请求独立选项与全局设置选项融合
- [优化] 优化客户端动态注册自定义属性添加和返回逻辑
- [优化] 关闭 OIDC 客户端动态注册功能,默认使用新版 Spring Security 开始支持的 OAuth2 客户端动态注册
- [优化] ServiceContext 及配置新增 OAuth2 客户端自动注册端点
- [优化] 核心业务逻辑 JPA 存储枚举类型字段指定数据长度,降低数据库存储使用
- [优化] 将原有使用 saveAndFlush 方法的代码变更为使用 save 方法,提升数据库操作性能
- [优化] 优化 hikari 和 hibernate 配置以进一步提升链接和访问数据库性能0.3-11-cds
- 依赖更新
- [升级] alipay-sdk-java 版本升级至 4.40.791.ALL
- [升级] langchain4j 版本升级至 1.15.0
- [升级] redisson 版本升级至 4.4.0
- [升级] software.amazon.awssdk 版本升级至 2.44.7
- [升级] software.amazon.awssdk.crt 版本升级至 0.45.4
- [升级] swagger-core 版本升级至 2.2.50
- [升级] weixin java 版本升级至 4.8.3.B
- [升级] protobuf-maven-plugin 版本升级至 5.1.4
- [升级] spring-ai 版本升级至 1.1.6
- [升级] vue 版本升级至 3.5.34
- [升级] grpc 版本升级至 1.81.0
- [升级] fastjson2 版本升级至 2.0.62
- [升级] operaton 版本升级至 2.1.0
- [升级] webauthn4j 版本升级至 0.31.5.RELEASE
- [升级] joda-time 版本升级至 2.14.2
[三] 注意事项
- Dante Cloud 4.0.6.0 版本,使用了全新的、包含 AI 支持功能的 Nacos v3.2.1。因为新版 Nacos 表结构发生了较大变化,该版本与之前版本不兼容。需要重新建库重新导入配置。
- Nacos 自 v3.2.0 版本起,已经将关键的 plugin,例如:Postgresql、Oracle 等数据存储插件合并至 Nacos 主工程中,并默认打包至 Docker 的镜像中,通过修改配置即可更换数据库,无需像从前一样,更换数据库还得自己打包插件。因此,原来由 Dante Cloud 自主打包的 Docker 镜像将不再维护,直接使用 Nacos 官方打包镜像。
[四] 项目简介
Dante Cloud 国内首个支持阻塞式和响应式服务并行的、开箱即用的企业级云原生微服务基座。是采用领域驱动模型(DDD)设计思想,以「高质量代码、低安全漏洞」为核心,基于 Spring 生态全域开源技术,高度模块化和组件化设计,支持智能电视、IoT等物联网设备认证,满足国家三级等保要求,支持接口国密数字信封加解密等一系列安全体系的一站式多租户微服务解决方案。独创的可以“一套代码实现微服务和单体两种架构灵活切换”的企业级应用系统。
1. 项目理念
Dante Cloud 一直秉承着“简洁、高效、包容、务实”的理念,使用微服务领域及周边相关的各类新兴技术或主流技术进行建设,不断地深耕细作、去粗取精、用心打造。目标是构建一款代码质量高、维护投入低、安全防护强的微服务基座,可以帮助用户快速跨越架构技术选型、技术研究探索、基础架构搭建阶段,直接聚焦业务开发。极大地降低传统项目中因安全漏洞、技术负债、低质代码等潜在隐患所产生的高维护投入。期望像项目名字寓意一样,构建一套可以在在行业变革的时期承上启下,助力企业信息化建设和数字化转型的产品。
Dante Cloud 核心关注点是:「高质量的系统代码」、「合理的系统架构」、「低耦合的模块划分」、「高安全性系统实现」、「灵活的功能扩展能力」,「优质的微服务方案」。不会像其它一些系统一样,追求 业务功能 的 丰富 性。堆叠大量无法做到真正通用的功能,反倒会成为负担和干扰,不如由用户自己按照需求灵活设计和实现。
2. 架构设计
Dante Cloud 优秀的模块化能力,为系统提供了高度灵活的配置能力、功能的“可插拔”能力 以及不同需求场景的适配能力。正因为优秀的模块化体系,使得 Dante Cloud 不仅是一套完整的微服务架构,还是一套高质量的 「单体模块化」 系统。这里的微服务架构和单体架构并不是分离的两套代码,也不是分离的两个项目。而是完全融合的一整套代码,使用时可以根据需要选择是以微服务模式或者单体模式运行,配合灵活的模块能力,实现系统的多样化定制和功能的管控。
这是 Dante Cloud 微服务最大的特色之一:“一套代码、两种架构”。可以帮助企业在项目早期以单体架构快速建设项目、方便开发人员在本地进行开发以及新技术研究。在项目后期随着用户规模增大以及并发需求提升时,可以快速无缝迁移至微服务架构。
3. 适用用户
微服务技术并不是落伍了,而是进入了成熟期,它的适用场景和边界被更清晰地定义了。微服务不再是一个“必须要有”的选项,而是一个“权衡之后”的选择。同时,Dante Cloud 也并未使用任何复杂难懂或难以上手掌握的技术,项目中所涉及核心关键组件中,其中 「近 80% 均为 Spring 生态原生组件」。技术实现均为各组件标准用法的组合与应用,编码风格和代码设计一直也在极尽努力尽量与 Spring 生态的标准规范用法保持一致,只不过经过大量的版本迭代和重构之后逐渐形成了一定的封装与抽象。
本项目适用的用户如下:
- 「传统项目用户」:可以先体验的单体版,先从“前后端分离”以及“多端适配”开始,尝试不同于传统内嵌页面的开发模式。
- 「数字转型用户」:如果您正在考虑进行数字化转型,可以直接选择使用微服务版本,不用再为“基础组件碎片化,需花大量时间整合、踩坑版本兼容”等问题而苦恼。
- 「复杂项目用户」:如果您的业务复杂度上升到一定阶段,可以直接选择使用微服务版本,直接聚焦于业务开发,节省大量前期搭建基础设施、解决通用技术问题的时间。
- 「初创团队用户」:可以先使用单体版进行开发,只要代码放置规范、模块划分合理,后期可以根据需要无缝迁移至微服务架构
- 「技术尝鲜用户」:本项目并不拘泥局限于常规成熟的技术内容,目标是探索新型技术并用其来为业务的创新服务。喜欢技术尝鲜的用户可以尝鲜使用。
- 「学习提升用户」:本项目代码实现优雅和领域划分清晰,编码风格和模块实现尽最大可能与 Spring 生态规范保持一致,是深入学习 Spring 生态组件和提升技能的优秀案例
支持开源项目的方式不是仅有 Fork 工程和下载源码,还可以点点 Star!
1. Dante Cloud 主工程
2. Dante Engine 核心组件库
3. UI 前端工程(旧版)
4. UI 前端工程(新版)
5. ThingsBrain 基于 Dante Cloud 的物联网平台(加速开发中...)