IntelliJ IDEA 2022.2 EAP 5 发布了，此版本带来了许多特定于框架的更新，包括对 Spring 6 和 Spring Boot 3 功能的支持、对 Websocket 和 GraphQL 请求的支持、对 HTTP 客户端的改进等等，还包括 Docker 和 Kubernetes 的一些新功能。

框架和技术

Spring 6 和 Spring Boot 3

IntelliJ IDEA 2022.2 完全支持 Spring 6 和 Spring Boot 3 功能，包括新的@AutoConfiguration 类和@ConfigurationProperties 类。

Spring 6 支持新的声明式 HTTP 客户端

Spring Framework 6 允许将 HTTP 客户端定义为带有注释方法的 Java 接口。IntelliJ IDEA 2022.2 为此类接口提供 URL 完成、导航以及与 HTTP 客户端的集成。

Spring Cloud Gateway 路由的 URL 完成和导航

IntelliJ IDEA Ultimate 现在提供 URL 补全、Search Everywhere 功能以及查找 Spring Cloud Gateway URL 的使用提示。可以使用 Endpoints 工具窗口轻松生成 HTTP 请求，或查找所有网关路由。

用于 Java 的实验性 GraalVM 本机调试器

IntelliJ IDEA 2022.2 可以调试 GraalVM 原生映像二进制文件，可以将调试器附加到任何基于 GraalVM 的可执行文件，或使用附加的调试器启动应用程序。它将为 Maven/Gradle 项目自动创建相应的运行配置。

请注意，此集成是实验性的，需要安装 GraalVM 的开发版本和此插件。

JVM 微服务测试和模拟框架的代码洞察改进

IntelliJ IDEA 2022.2 使用 Spring WebTestClient、RestAssured、WireMock 和 MockServer 等流行的 Java API 自动突出显示测试中的 JSON/XML 主体，这些数据片段具有更好的可读性，且更易于编辑。

Spring Shell 代码洞察改进

IntelliJ IDEA 2022.2 可以识别使用 Spring Shell 库声明的 CLI 命令，并检查其正确性。

改进了对 JAX-RS 端点的支持

IntelliJ IDEA 2022.2 正确支持声明为@ApplicationPath 的 JAX-RS 通用 Web 服务 URL 模式，以及 URL 完成、导航和查找使用中的子资源。

在 HTTP 客户端中支持 WebSockets 端点

IntelliJ IDEA 2022.2 Ultimate 支持 WebSocket 连接，允许创建请求以及发送和接收消息。

在 HTTP 客户端中支持 GraphQL 端点

此版本在 HTTP 客户端中引入了对 GraphQL 请求的支持。IntelliJ IDEA Ultimate 可以通过开箱即用的 HTTP 和 WebSockets 协议发送 GraphQL 查询。对于http://  和  https://  使用简单的 HTTP 请求，而 ws:// 和 wss:// 则被委托给 WebSocket 执行程序。

HTTP 客户端的 UI/UX 改进

为 HTTP 客户端引入了一些 UI/UX 改进。首先是可以使用装订线图标选择运行环境：

其次是通过添加进度条改进了响应视图，方便跟踪下载过程。

改进了 Protobuf 和 Java 源之间的导航

可以轻松地从 .proto 文件导航到生成的代码并返回。

Kubernetes 和 Docker

通过 Telepresence 集成拦截 Kubernetes 服务请求

IntelliJ IDEA 2022.2 的 Kubernetes 插件提供与 Telepresence 工具的集成，以便拦截来自 K8s 集群中服务的 HTTP 请求，并将它们路由到本地运行的服务。

IDE 重启时 Docker 自动连接

IntelliJ IDEA 现在会在重新启动 IDE 后自动连接到 Docker。

完整的更改列表请查看发行说明。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

开源轻量级应用交付平台

渠成云原生应用交付平台 是 北京渠成软件有限公司自主设计、研发的开源轻量级应用交付平台。它底层基于容器和Kubernetes技术，通过Helm进行应用的封装，提供了渠成云原生应用市场、服务管理、服务监控与告警、日志管理与审计、集群管理等平台功能，是一款使用简单，功能完备的云原生应用交付平台。

视频介绍请看：https://www.qucheng.com/dynamic/qucheng-v1.0-11.html

我们秉承Unix哲学，坚持用简单的方法来解决问题，因此平台在设计之初就坚持简单的原则，将底层复杂的技术进行了抽象和屏蔽，让使用者更专注于平台应用本身的体验，同时提供了应用的一键安装、升级、备份与回滚功能。渠成平台，您可信赖的应用交付平台。

为什么用渠成这个名字？

渠成平台全称：渠成云原生应用交付平台

渠成： 取自 “水到渠成” ，寓意“条件”具备后，后续的事情就会变得自然而然。“条件” 指的就是 “渠成平台”，希望渠成平台能够为您的应用管理提供全方位的支持。

渠成平台的设计理念

目前开源和商业的平台软件很多，基本上都是基于容器和Kubernetes的生态实现，涵盖CMDB、自动化运维、CI、CD、GitOPS、DevOps等众多领域。但我们需要回归本心，认真思考我们要的是什么？平台的本质是什么？平台的真正用户是谁？

因此，经过我们的认真思考，来回答上面的几个问题：

• 平台的本质是什么？：平台只需要支撑业务服务就好，不需要过多的功能，因此我们只做应用安装与管理。

• 平台的用户是谁？：我们平台的用户是应用使用者，他们关注的是应用的稳定性，因此应用安装、升级、回滚备份是必要功能。

渠成平台不会做复杂的功能，我们的关注点在应用管理，我们要做应用管理的专家。

主要功能列表

应用市场

提供官方的开源、商业软件，支持一键安装，数秒内就可以安装完成。

• 极速安装

• 自定义安装

• 应用发布

服务管理

软件从应用市场安装后，运行在平台上，我们称之为服务。

• 服务关闭、启动、重启、删除

• 服务访问控制

• 服务备份

• 服务升级

• 服务导出

• 自定义域名

高可用

平台组件、平台上运行的服务原生具备高可用特性。

• 内置K3s

• 对接现有Kubernetes

• 应用高可用

• 平台组件高可用

仪表盘

展示平台资源使用情况与服务运行情况，一个页面了解全局。

• 平台全局资源概况

• 平台动态信息

• 平台安装的应用详情

监控与告警

平台支持硬件资源、应用状态以及平台自身组件的状态监控与告警。

• 资源监控

• 组件监控

• 行为审计监控

• 应用指标监控

• 告警配置

安全审计

平台内置行为与安全审计模块，同时为运行在平台中的应用提供WAF安全防护功能。

• 平台行为审计

• Web应用防火墙

• 应用安全扫描

团队管理

提供团队创建、成员维护以及权限的配置。

• 成员管理

• 权限管理

集群管理

支持集群节点的维护、平台模块的监控与伸缩。

Torna 1.15.1 发布，本次更新内容如下：

• 【新增】文档可导出为word pr
• 【升级】fastmybatis升级到2.3.2
• 【优化】优化用户查询SQL
• 【优化】增大axios超时时间，方便调试
• 【优化】添加部分权限校验
• 【优化】富文本编辑器使用wangeditor

现在文档可导出为word，效果如下

富文本编辑器改成了wangeditor，效果如下：

预览效果：

关于 Torna

企业接口文档解决方案，目标是让文档管理变得更加方便、快捷。Torna 采用团队协作的方式管理和维护项目 API 文档，将不同形式的文档纳入进来，形成一个统一的维护方式。

Torna 弥补了传统文档生成工具（如 swagger）的不如之处，在保持原有功能的前提下丰富并增强了一些实用的功能。

推荐组合

smart-doc + Torna 实现文档全流程自动化

如果您使用 Java 语言，推荐使用 

smart-doc + Torna 组成行业领先的文档生成和管理解决方案，使用 smart-doc 无侵入完成 Java 源代码和注释提取生成 API 文档，自动将文档推送到 Torna 企业级接口文档管理平台。

通过这套组合您可以实现：只需要写完 Java 注释就能把接口信息推送到 Torna 平台，从而实现接口预览、接口调试。

推送的内容有：

如果您是非 Java 语言，可以使用表单页面编辑以上内容，完成后同样可以进行接口预览、调试。

x-easypdf基于pdfbox二次封装，极大降低使用门槛，以组件化的形式进行pdf的构建。简单易用，仅需一行代码，便可完成pdf的相关操。

本次更新内容如下：
新特性：
– 新增对otf字体的支持
– 新增页面尺寸类
– 新增页面获取当前页面尺寸X轴左坐标的方法
– 新增页面获取当前页面尺寸X轴右坐标的方法
– 新增页面获取当前页面尺寸Y轴上坐标的方法
– 新增页面获取当前页面尺寸Y轴下坐标的方法
– 新增页面获取原有页面宽度的方法
– 新增页面获取原有页面高度的方法
– 新增页面获取原有页面尺寸的方法
– 新增页面获取原有页面尺寸X轴左坐标的方法
– 新增页面获取原有页面尺寸X轴右坐标的方法
– 新增页面获取原有页面尺寸Y轴上坐标的方法
– 新增页面获取原有页面尺寸Y轴下坐标的方法
– 新增开启表单修复的方法
– 优化条形码组件绘制逻辑
– 优化图片组件绘制逻辑
– 优化表格组件绘制逻辑
– 优化页眉组件绘制逻辑
– 优化页脚组件绘制逻辑
– 优化文本组件绘制逻辑
– 优化读取文档页面的加载逻辑
– 优化字体映射逻辑(多文档同时处理时，平均耗时降低35%，内存占用减少50%)

原有变更：
– 原PDRectangle参数相关方法变更为XEasyPdfPageRectangle参数

问题修复：
– 修复页眉/页脚组件添加自定义组件错误问题(issue#I5BYE4，issue#I5BZUN)
– 修复页眉组件分割线错误问题
– 修复表格组件自动拆分行数据错误问题

注：本次更新不兼容历史版本，请按需升级。

1 背景

技术方案设计和评审是版本迭代的一个重要环节，一般情况下版本迭代交付，技术方案设计在2-3天，颗粒度大的需求或者独立项目，这一个环节的时间会适度拉长，但是整体时间还是比较紧凑。技术同学在短时间产出高质量的技术方案是相对困难的，这样评审人对技术方案设计比较难以理解到位、并给出合理建议。本文给出一种面向需求迭代交付的技术方案设计逻辑以解决这一问题，它的核心思想是采用用例驱动设计，基于“演绎法+自上而下”的逻辑来设计技术方案。

2 概要性的设计逻辑

本文的技术方案设计逻辑，基于用例驱动设计。先从需求识别关键用例，接着为用例构造涉及顶层服务交互时序图，之后再自上而下的展开每一个服务接口实现的设计。

1. 关键用例识别：用例是用户或者外部系统与当前系统交互的一个完整的过程，它站在用户视角思考解决用户问题的完整交互流程。这是驱动软件设计的第一步，有了关键用例识别，就可以为每一个用例展开设计。这样整个技术方案设计就具备完整性和推导逻辑。
2. 用例涉及顶层服务交互时序设计：顶层服务是指最外层的服务，你可以理解为RPC服务或者HTTP服务。用户一个完整的交互流程会涉及多个顶层服务的协作完成，交互时序图定义清楚了满足用例的服务交互顺序、服务接口定义、服务大致的实现逻辑。这一步骤是一个概要设计，它不会深入到服务内部的设计，而是偏向服务间的交互契约定义（服务功能、服务接口、服务交互）。接下来就可以从这个交互时序自上而下推导服务接口实现方案设计。
3. 服务接口实现设计：在第2步的概要设计里面，明确定义了服务的功能、服务的接口定义，这一步骤就从服务要解决的功能性问题和非功能性问题展开设计，特别是非功能性问题的定义和满足往往会影响实现方案的设计，比如可靠性问题、可扩展性问题、可维护性问题。举个例子，针对可扩展性问题，可以拆分为规模可扩展性、业务可扩展性。规模可扩展性依靠服务自身性能和服务横向伸缩能力，因此如何提升服务的性能和服务具备横向伸缩就会对服务接口实现的设计产生很大的影响。这里，我们就可能会在功能性问题设计方案基础上，增加缓存组件，以提升性能。

以上3点就是简单的用例驱动的设计逻辑。接下来介绍一下比较完整的设计逻辑。

注：用例驱动设计，非常重要，不仅仅可以用在设计，也在编码、CR、稳定性保障起到很重要的作用，举个例子，目前我们的CR是逐个用例进行评审，每一个用例先介绍顶层服务交互时序图，再Review代码，评审效率和结果提升很多。

3 完整的设计逻辑

架构设计的出发点是用户问题，从用户问题出发形成解决方案，最终落地变成我们的产品需求。产品需求的合理性，就会由用户问题是否准确定义、用户问题解决路径是否匹配、用户问题解决路径涉及的业务流程和规则是否合理决定。技术同学着重关注应用架构、技术架构、数据架构，这三个架构是可以遵循合理的推导逻辑来设计的。一种比较简单清晰的推导路径分成四个阶段、九个步骤， 如下图所示。

• 需求分析：对需求进行结构化分析，明确需求要解决的问题、实现路径、实现路径涉及的业务流程和业务规则，最终抽取出参与者与系统关键用例。注意：系统关键用例非常重要，它是整个技术方案设计的第一步，即用例驱动设计。
• 应用架构设计：从系统关键用例出发，勾勒出需求的所有用例场景，用例涉及的应用、服务及其之间的依赖关系，然后详细设计用例涉及的服务的交互时序图，并明确服务的接口定义和非功能性要求。应用架构是一个高层的设计，拉通了整个团队对需求涉及的用例及用例实现中涉及服务的具体交互流程的认知，定义了应用、服务间的实现契约。注意：这里用例服务交互时序图只涉及服务及核心流程，不用太细化到服务的具体实现，也就是说每一个服务只有一个Lifeline，在里面的每一个步骤简单描述。
• 技术架构设计：从应用架构中定义的服务接口展开，针对服务接口的实现进行设计，需要分析服务接口实现的功能性、非功能性需求，准确识别服务接口实现需要解决的问题，然后设计相应的解决方案，特别是非功能性需求的满足需要通过合理的技术架构的设计来保障。比如，解决直播库存秒杀问题、解决库存超卖问题、解决出价分布式一致性问题、解决商品详情模块化扩展问题、解决收藏大数据实时查询问题等，用例中对这些问题的定义可以推导出合理的解决方案，将解决方案用图形化方式表示出来，就整体形成技术架构设计。非功能性需求，可以分类为可靠性需求、可维护性需求、可扩展性需求、效率与成本需求等。
  • 可靠性需求可以通过SLA进行目标定义，SLA可以拆分为SLO、SLI，比如服务接口在规定响应时间的响应成功率、分布式事务一致性比率等，然后设计相应方案来保障。
  • 可维护性需求核心在于控制复杂度，尽量使用简单的设计来满足可维护性。可以采用成熟的架构风格、设计模式应用在服务实现中，比如分层、插件化（模块化）、管道过滤器、组合模式等。
  • 可扩展性需求则重点考虑规模的扩展和业务规则的扩展，规模的扩展要求能够进行横向扩缩容，需要至少满足无状态设计，而业务规则的扩展则可以应用扩展类的架构风格与设计模式。
  • 效率与成本需求是对技术架构设计形成约束，即服务的实现是要考虑成本的，尽可能具备高的性价比。
• 数据架构设计：从服务接口实现方案出发，设计合理的存储架构满足服务的功能性和非功能性需求。数据架构需要描述清楚所依赖的关系数据存储、列式数据存储、高速缓存、索引、离线计算、实时计算等，以及具体的数据模型（可用使用ER图表示），此外，还需要兼具考虑事务处理性能、数据分析性能等需求。

架构设计基于用例驱动设计，通过“演绎法 + 自上而下”进行推导设计的。首先，从业务需求到IT架构（应用架构、技术架构、数据架构）是层层推导设计的。其次，应用架构来自全局的用例场景及用例涉及服务交互，它是概要性的设计；技术架构和数据架构则是应用架构服务接口定义的具体实现的方案设计，需要针对服务接口实现的功能与非功能性需求进行设计；从应用架构到技术架构与数据架构是自上而下（或者由总到分）的推导。

详细的各部分设计逻辑可以参考：规范-技术方案设计，本文详细介绍了如何做需求分析、如何做应用架构设计、如何做技术架构设计、如何做数据架构设计等内容。

4 关键的两类图：用例图和时序图

4.1 用例图

三部分组成：参与者、用例、参与者与用例之间的关系。

参与者：不是特指人，是指系统以外的，在使用系统或 与系统交互中所扮演的⻆色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

用例：是对包括变量在内的一组动作序列的描述，系统 执行这些动作，并产生传递特定参与者的价值的可观察结果。

关系：参与者与用例之间的关系主要包括关联、归纳 (泛化)、包含、拓展和依赖。

用例图中的关系描述如下：

A）关联：表示参与者与用例之间的关系;

B）泛化：表示参与者与参与者之间、用例与用例之间 的关系，一个用例可以被特别列举为一个或多个子用 例，这被称为用例泛化;

C）包含：表示用例与用例之间的关系，其中一个用例 (基础用例)的行为包含了另一个用例(包含用例)的 行为。用来把一个较复杂用例所表示的功能分解成较小的步骤;

D）扩展：表示用例与用例之间的关系，用于拓展用例对基础用例的增强;拓展用例是在特定条件出现时，才会被执行的用例。

4.2 时序图

时序图是基于交互的对象行为建模，是 UML 用于描述 对象之间信息的交互过程的方法，是描述对象间协作关系的模型。

时序图用于捕获系统运行中对象之间有时间顺序的交互，是由生命线和消息组成。

时序图将交互关系表示为一个二维图。纵向是时间轴， 时间沿竖线向下延伸。横向轴代表了在协作中各独立对 象的类⻆色。类⻆色用生命线表示。当对象存在 时，⻆色用一条虚线表示，当对象的过程处于激活状态 时，生命线是一个双道线。消息用从一个对象的生命线 到另一个对象生命线的箭头表示。箭头以时间顺序在图 中从上到下排列。

时序图要素说明如下：

A）⻆色：用户、外部系统等。

B）对象和生命线：对象的命名可以是类名、对象名、 类 + 对象名，生命线为虚线表示对象存活的时间。

C）活动条：在生命线的虚线上可以用活动条来表示某 种行为的开始和结束，一般用矩形表示。

D）消息：对象的行为称为消息，对象调用另一个对象 的行为即完成一次消息传递。分为：简单消息、同步消 息、异步消息。此外，还有自我调用消息、消息的返回值。

E）交互框：选项 opt、抉择 alt、循环 loop、并行 par 等。

5 参考模板和范例

以下是出价定义的技术方案参考模板，不同的模板对设计逻辑进行裁剪和调整。对于版本迭代，大部分需求设计可以采纳V3版本的方式来设计。这里附上了相应的参考范例，供大家参考。

6. 结论

本文探索了基于用例驱动的架构设计逻辑，核心思想是采用用例驱动设计，基于“演绎法+自上而下”的逻辑来设计技术方案，帮助开发人员理清技术方案设计思路并提升技术方案的质量和评审效率。完整的架构设计背后简单清晰的推导路径分成四个阶段、九个步骤，简单实用，如下所示。

各个阶段的产出成果如下。

• 需求分析阶段产出成果
  • 业务流程图（活动图或流程图，泳道或非泳道）
  • 用例图
• 应用架构设计阶段产出成果
  • 应用、服务规划
  • 用例涉及顶层服务交互时序图
  • 服务接口定义
• å技术架构设计阶段产出成果
  • 服务接口实现的设计方案

  Idea激活2022.2

• 数据架构阶段产出成果
  • 服务接口实现的存储方案
  • ER图

*文/LorryIdea激活2022.2

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～