IntelliJ IDEA 2022.2 首个 EAP 版本现已发布，带来了许多有用的改进；同时将 IDE 迁移至 JBR 17，以提高 IDE 性能。开发者可以从网站、Toolbox 应用程序，或通过使用 Ubuntu 的 snaps 下载最新版本。

具体更新内容如下：

用户界面

在 MacOS 上合并所有项目的 Windows action

针对 macOS 用户引入了将所有打开的项目窗口合并为一个的功能，将它们变成 tab。此操作可从“Window”菜单中获得。

Mnemonic Bookmarks 的新描述字段

在”Add Mnemonic Bookmark”对话框中集成了一个描述字段，这样你就可以立即为你的书签添加一个可选的描述。

缩放时的字体大小指示器

当你在编辑器中放大或缩小代码时，现在可以看到一个显示当前字体大小的指示器以及将其恢复为默认值的选项。

VCS

Welcome screen 上的 Cloning repository 进度条

更新了 Cloning repository 进度在 IDE 的 Welcome screen 上的显示方式。现在，进度条直接显示在 Projects 列表中，使其更加清晰和易于使用。

Editor

New setting to disable automatic block comment closure

现在可以在按下 Enter 键时禁用 automatic block comment closure。可通过，Settings / Preferences | Editor | Smart Keys，取消勾选”Enter”部分的”Close block comment”复选框。

Code Completion Popup 中提供的 Code Completion Settings

现在可以直接从 Code Completion Popup 中的三个垂直点菜单按钮访问 Code Completion Settings 并配置你的 preferences。

JetBrains Runtime

随着 IntelliJ IDEA 2022.2 EAP 的推出，开发团队正在从 JetBrains Runtime 11 (JBR11) 迁移到 JetBrains Runtime 17 (JBR17)。从此构建开始，所有 IntelliJ IDEA 2022.2 更新都将随附 JBR17。带来的影响包括：

• 显着的性能改进，使 IDE 运行更快、更顺畅。
• 更好的安全性，因为 JBR17 基于最新的 OpenJDK LTS。
• JetBrains Runtime 17 利用 Metal API 在 macOS 上提供更好的渲染性能。
• 提高 macOS 上的可访问性，因为 JBR17 具有与 VoiceOver screen reader 的集成。
• Vector API 的使用旨在表达在运行时编译为支持的 CPU 架构上的向量指令的向量计算，从而实现优于等效标量计算的性能。

详情可查看官方公告。 

更新内容:

• 添加了 test 模块, 方便单测试, 比起之前使用 http::Request::builder 构建 Request 请求简洁很多.
• 添加解析 Request 请求数据到强类型的功能, 并且支持多数据源组合. 详细介绍

Salvo 是极其简单且功能强大的框架

Handler

 use salvo::prelude::*; #[fn_handler] async fn hello_world(_req: &mut Request, _depot: &mut Depot, res: &mut Response) { res.render(Text::Plain("Hello World")); }

中间件

 use salvo::http::header::{self, HeaderValue}; use salvo::prelude::*; #[fn_handler] async fn add_header(res: &mut Response) { res.headers_mut() .insert(header::SERVER, HeaderValue::from_static("Salvo")); }

路由

 Router::new() .push( Router::with_path("articles") .get(list_articles) .push(Router::with_path("").get(show_article)), ) .push( Router::with_path("articles") .hoop(auth_check) .post(list_articles) .push(Router::with_path("").patch(edit_article).delete(delete_article)), );

Github: https://github.com/salvo-rs/salvo

关注公众号

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

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

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

更新内容：

• 字典翻译缓存支持放到redis中
• 添加使用map的实现类包装vo 进行翻译(比如ruoyi的AjaxResult)

插件介绍：

       表里我们经常存放字典码，外键 给前端展示的时候要展示字典描述 (比如 sex 0 代表男)，外键要显示 title/name (如 userid 1 要翻译为张三)。字典比较简单，很多项目都直接交给前端翻译，但是外键翻译是必须要后台来做的，最常见的做法就是 表 join ，这样又要自己写 sql 比较麻烦。使用 Easy Trans，只需要一个注解就可以搞定数据翻译。

支持的场景：

•   字典翻译     把 sex 0 翻译为男
•   普通外键翻译 / 唯一键翻译  框架使用 mp/jpa 能力自动帮你去执行 sql 根据外键查询 name/title 并且 set 到你的 vo 字段上
•   跨微服务翻译   比如 order 集合 user 是 2 个微服务，但是 order 要展示创建人姓名，表里只有 id  可以使用跨微服务翻译
•   枚举翻译   把枚举中的汉字给到前端

Trans 注解：

 程序员只需要掌握这一个注解就算熟练使用 EasyTrans 了，绝对不干让程序员掉更多头发的事情。

项目地址：https://gitee.com/fhs-opensource/easy_trans

文档地址：https://gitee.com/fhs-opensource/easy_trans/wikis

关注公众号

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

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

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

关注公众号

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

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

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

更新记录

• ✨ 支持 Spring boot 2.7.0 新特性 @AutoConfiguration。

• ⬆️ 升级 Spring boot 到 2.7.0

注意：mica-auto 并不强制依赖 Spring boot，仅仅是组合了 依赖，方便使用。mica-auto 2.3.0 理论上支持 Spring boot 所有版本。

关于 Spring boot 2.7.0 @AutoConfiguration

1 @AutoConfiguration 注解

Spring boot 2.7.0 新增 @AutoConfiguration 注解，它用来替换 @Configuration 注解， 我们可以看到它组合了 @Configuration（默认 proxyBeanMethods = false 配置类不进行代理，可节省资源另外对 GraalVM 更加友好）、@AutoConfigureAfter 和 @AutoConfigureBefore 方便使用。

另外 Spring boot 2.7.0 开始推荐使用 替换 中的 配置。

2 老的 spring.factories EnableAutoConfiguration 配置

3 新的 AutoConfiguration.imports 配置

使用 mica-auto 2.3.0 在 Spring boot 2.7.x 的配置类中如果使用 注解就会自动生成到新的 AutoConfiguration.imports 配置中，如果任然使用的是老的 则任然会生成到 中。

使用场景

• Spring boot starter 开发利器，自动生成 spring.factories、AutoConfiguration.imports、spring-devtools.properties 配置。

• 多模块项目中的子项目，包名不同时的自动配置（主项目不建议添加）。

• java spi 扩展自动生成配置。

建议关注如梦技术码云：https://gitee.com/ ，更多微服务核心组件值得拥有。

 @RequestMapping("essay") @RestController public class EssayController {  @Autowired  private EssayService essayService;  //查询  @GetMapping("select")  public RS select() {  //查询列表  List<Essay> list = essayService.selectAll();  list = essayService.selectByCondition(Wrapper.where(gt(Essay$.id, 10)).and(lt(Essay$.id, 20)));  //查询一条  Essay essay = essayService.selectById(1L);  essay = essayService.selectOneByCondition(Wrapper.where(eq(Essay$.id, 333)));  //复杂查询  Select select = new Select();  select.column(Essay$.id).column(Essay$.content);  select.where().gt(Essay$.id, 1).and().eq(Essay$.content, "222");  select.orderByDesc(Essay$.creation_time);  list = essayService.select(select);  //用于查询Map  Map<String, Object> map = essayService.selectMap(select);  List<Map<String, Object>> mapList = essayService.selectMapList(select);  return super.successHint("获取成功", list);  }  //分页  @GetMapping("getList")  public Map getList(HttpServletRequest request) {  // 查询对象  Select select = new Select();  ReqPageHelper<Essay> pageHelper = new ReqPageHelper<>(request);  pageHelper.paging(select, essayService);  return pageHelper.toResult("获取列表成功");  }  //更新  @PostMapping("update")  public RS update(Essay essay) {  //根据bean内部id更新  long i = essayService.updateByBeanId(essay);  //根据条件更新  //i = essayService.updateByCondition(Wrapper.where(gt(Essay$.id, 1)).and(eq(Essay$.content, "222")));  if (i > 0) {  return super.successHint("更新成功");  }  return super.othersHint("更新失败");  }  //删除  @PostMapping("deleteById")  public RS deleteById(Integer[] id) {  //根据id删除  long i = essayService.deleteById(id);  //根据条件删除  //i = essayService.deleteByCondition(Wrapper.where(gt(Essay$.id, 1)).and(eq(Essay$.content, "222")));  if (i > 0) {  return super.successHint("删除成功");  }  return super.othersHint("删除失败");  }  //插入  @PostMapping("add")  public RS add() {  List<Essay> essayList = new ArrayList<>();  for (int i = 0; i < 100; i++) {  Essay essay = new Essay(i, "name" + i);  essayList.add(essay);  }  essayService.insert(essayList);  return successHint("成功");  } }

更新内容

• 增加移动端图形验证码
• 增加移动端海报
• 增加移动端秒杀
• 增加移动端团购
• 增加移动端积分商城
• 增加移动端分销市场
• 增加移动端优惠券
• 增加移动账户安全
• 增加移动端收货地址
• 增加游客下载课件限制
• 增加授权到期提醒
• 修复首页简洁模式下样式问题
• 修复删除群组前台依旧显示问题
• 修复兑换课程用户课程数未增加问题
• 调整分享链接服务目录结构
• 若干查询完善 deleted=0，published=1 条件
• 增加 meta renderer 标识方便 360 识别 webkit 模式
• vidtor 本地话，弃用 cdn.jsdelivr.net
• 优化会员套餐价格排序

系统介绍

酷瓜云课堂，依托腾讯云基础服务架构，采用 C 扩展框架 Phalcon 开发，致力在线教育系统。

系统功能

实现了点播、直播、专栏、面授、问答、会员、群组、微聊、积分、秒杀、拼团、分销等。

友情提示

请使用干净的系统执行安装，如有安装过 ， 之类的占用 80 和 443 端口的 web 服务会造成端口冲突

配置要求

• 操作系统：Ubuntu | Debain | Centos
• 系统内存：2G+

申请试用授权

授权申请地址：申请

安装指南

下载安装脚本

根据实际情况修改配置

可选配置项目如下：

执行安装，快慢取决于网络，当有错误或者超时 请重试，请重试，请重试

访问网站

• 管理帐号：10000@163.com /
• 前台地址：http://{your-domain}.com
• 后台地址：http://{your-domain}.com/admin

后续设置： 系统设置

测试数据

管理帐号：@163.com /

结束安装

安装完成，请删除安装脚本

微软于今天发布了 Visual Studio 2022 for Mac v17.0 的 GA 版本，Mac 用户现在就可以下载安装。微软在更新说明中将该版本誉为「迄今为止速度最快的 Visual Studio for Mac 版本」，新版本具有全新的原生 macOS 用户界面、完全运行于 .NET 6，并针对 Apple Silicon（ARM64）处理器进行了优化。

下载链接：

• Visual Studio 2022 for Mac v17.0

微软还发布了 Visual Studio for Mac 的下一个更新的预览版，这个预览版带来了对 .NET 7 和 .NET MAUI 工具的初步支持。

享受快速和流畅的体验

这个版本将 IDE 的前端 UI 换成了完全原生的 macOS UI，取代了之前结合众多 UI 技术的架构。还替换了 IDE 的后端，使其在 .NET 6 上运行。这两个重大变化的结合，使 Visual Studio for Mac 成为迄今为止速度最快、反应最迅速的版本。

通过将 IDE 转移到 .NET 6 上运行，还解锁了 IDE 的另一个最主要成就 —— Visual Studio for Mac 现在可以在 Apple Silicon（ARM64）处理器上原生运行。打开大型项目等操作现在比 Visual Studio 2019 for Mac 快了 50%。

使用 .NET 6 构建现代应用程序

通过这个版本，开发者可以使用 .NET 6 和 C# 10 构建应用程序。Azure Functions v4 也得到了支持，因此你可以在 .NET 6 的基础上开发 Serverless 应用程序。

虽然 Visual Studio for Mac v17.0 没有提供对 .NET MAUI 的支持，但与之同时发布的新预览版支持使用 .NET 6 和 .NET MAUI 对 iOS、Android 和 macOS 应用程序进行跨平台开发。

提高与 Windows 版本的一致性

最后，这个版本的重点是通过启用 Visual Studio（Windows 版本）的一些熟悉的功能来改善你的日常开发体验，如 Git Changes 窗口、工具窗口拖放和 Subword 导航。

• Visual Studio for Mac 中的 Git Changes 窗口，用于审查和提交你的工作。

  

• 工具窗口拖放

  

• 在 C# 编辑器中 Subwords 导航

  

更多详情可查看：https://devblogs.microsoft.com/visualstudio/visual-studio-2022-for-mac-is-now-available/

微软宣布 .NET MAUI 已正式 GA。

.NET MAUI (.NET Multi-platform App UI) 是一个跨平台 UI 框架（前身是 Xamarin.Forms），用于通过 C# 和 XAML 创建原生移动和桌面应用。基于 .NET MAUI，开发者可在单个共享代码库中创建同时支持 Android、iOS、macOS 和 Windows 的原生应用。

微软在公告中表示，此版本是他们实现统一 .NET 平台目标的新里程碑，为打造更广泛的 .NET 生态奠定了基础，并将 .NET Framework 和旧项目系统中的插件、库和服务引入到了 .NET 6 和 SDK 样式项目中。其中包括：

按照发布计划，.NET MAUI 的主要版本将在后续版本（下一个大版本）发布后至少 6 个月内获得支持。例如，.NET MAUI 6.0 将在 .NET MAUI 7.0 发布后的 6 个月内得到支持。同样，.NET MAUI 7.0 将在 .NET MAUI 8.0 发布后的 6 个月内获得支持。

未来，.NET MAUI 将与 .NET 保持一致的发布节奏，即 .NET MAUI 7.0 将与 .NET 7.0 一起发布，.NET MAUI 8.0 将随 .NET 8.0 一起发布。

.NET MAUI 亮点

开箱即用的原生 UI

针对不同平台（Android、iOS、macOS 和 Windows），.NET MAUI 分别提供了专门设计且开箱即用的最佳应用体验。例如，Windows 上的 .NET MAUI 获得了 WinUI 3 的支持，WinUI 3 是与 Windows App SDK 一起提供的首选原生 UI 组件。

丰富的 API

.NET MAUI 提供了简单的 API 来访问每个平台的服务和功能，例如加速度计、应用程序操作、文件系统、通知等。在下面的示例中，通过配置 “app actions” ，即可为每个平台上的应用程序图标添加菜单选项：

提升生产力

.NET MAUI 使用 .NET 6 引入的 C# 10 新特性，包括全局 using 语句和文件范围命名空间——非常有助于减少文件中的混乱。.NET MAUI 以“单一项目”为重点，将多平台目标提升到了一个新的水平。

在新的 .NET MAUI 项目中，平台被放置在一个子文件夹中，开发者可将重点放在花费大部分精力的应用程序上。在项目的 Resources 文件夹中，开发者可以在一个地方管理应用程序的字体、图像、应用程序图标、启动画面、原始资源和样式。.NET MAUI 将针对每个平台的独特要求进行优化。

将 Blazor 带入桌面和移动设备

 .NET MAUI 集成了 Blazor，因此开发者可以直接在原生的移动和桌面应用程序中重用现有的 Blazor Web UI 组件。借助 .NET MAUI 和 Blazor，开发者可以重用 Web 开发技能来构建跨平台的原生客户端应用程序，并构建跨移动、桌面和 Web 的单独 UI。

性能优化

.NET MAUI 专为提高性能而设计。.NET MAUI 中的 UI 控件在原生平台控件上实现了一种精简的、解耦的处理程序映射器模式——这减少了 UI 渲染中的层数，并简化了控件定制。

默认情况下会启用这些设置，以提供优化了性能的 release 版本。

点此查看更多细节。

主要更新：

• 新增Web开源扫描的联动，可以直接联动云上的域名资产进行送检。
• 工具端新增漏洞扫描的联动功能，跟镜像捆绑。
• 平台侧新增Web漏洞扫描配置的配置控制，在「豚控制台」入口处进入了解，可以在线修改扫描插件。（默认非专业安全人员无需了解，部署完成后天然就具备Web漏扫能力，抓取资产后，天然闭环）
• Web漏洞扫描完成后，跟漏洞管理打通，目前已实现。
• Web漏洞扫描增加跟腾讯云翻译的打通，漏洞详情译文，目前只对高级用户开放。
• 增加M1/X86_64的docker-compose区分支持。
• 修复部分BUG(13个)

待办：

• 全流程贯穿测试。
• 完善文档，最佳实践部分的文件。

下一步：（优先级）

• 插一个「紧急任务」，马上要护网了，完成SOC端启明星辰-cSplus系列的日志SysLog纳管，争取在护网时让老铁们能用上，联动分析。
• 云上全资产采集，如K8S的数据资产采集、入库。
• 站点管理增加资产关联匹配的能力，能够将采集到的资产通过自动化的方式匹配，也可以手动方式匹配。
• SOC增加API画像，分析请求的API，绘制站点API资产地图，用于后续代码组成分析用，SCA相关。
• 系统漏洞扫描，漏洞直接丢漏洞管理中。
• 把之前豚自动化构建K8S集群的能力融合到W3A SOC中。

CentOS – x86-64:
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-workapi:v1.0.11 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-dashboard:v1.0.11 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-openapi:v1.0.11 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-agent:v1.0.11 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-frontend:v1.0.11 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-arachni:v1.0.11 √

Mac Osx – m1
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-agent:v1.0.11-m1 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-frontend:v1.0.11-m1 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-workapi:v1.0.11-m1 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-dashboard:v1.0.11-m1 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-openapi:v1.0.11-m1 √
registry.cn-beijing.aliyuncs.com/aidolphins_com/w3a-arachni:v1.0.11-m1 x — Web漏洞扫描不支持在M1下运转

随着拼多多平台的火爆，拼团也成了电商系统必不可少促销活动方式。ShopWind v3.3.3 移动端增加了拼团功能模块，完美融合了拼团玩法，可以两人成团，三人成团，设置拼团优惠价格，超时自动成团等功能。    ShopWind 拼团插件的拼团商品、成团人数由商家发布，发布后的商品在拼团频道中展示。消费者可在拼团频道找到物美价廉的商品，通过发起拼团或参与拼团的形式去进行购物，不仅让商家能够走量赚钱，也能够让买家们花更少的钱买到自己想要的东西。

• 官网网址：https://www.shopwind.net
• 开发文档：https://developer.shopwind.net
• API 接口文档：http://docs.shopwind.net/dev-api
• 开发者社区：https://forum.shopwind.net

PC 体验

• 前台体验： http://test.shopwind.net 买家测试账号：buyer 密码： 支付密码：
• 后台体验： http://test.shopwind.net/admin 平台管理员账号：admin 密码：
• 商家体验： http://test.shopwind.net/seller/login.html 商家测试账号：seller 密码：

移动端体验（商业版）

• H5 端体验： https://h5.shopwind.net 买家测试账号： 密码： 支付密码：

小程序 / APP 体验（商业版）

• 微信小程序（手机浏览器链接）： https://wxaurl.cn/ayue5ScXlzh
• Android（安卓版）体验： https://appgallery.huawei.com/#/app/C
• iOS（苹果版）体验： https://apps.apple.com/cn/app/id
• 商家端体验（小程序）： https://wxaurl.cn/HoSSG6CkeZs
• 通用体验账号：买家（账号： 密码： 支付密码：）、商家（账号： 密码：）

拼团功能介绍

1、消费者在移动端首页，拼团频道，进入拼团频道选择喜欢的商品

2、去开团，进入团购详情页面，发起拼单，进入购买流程完成支付。支付完成后订单状态变为待成团

3、其他消费者进入该拼团商品中，页面展示出正在拼团的人。消费者可以去拼单，进入支付流程，完成支付后且满足拼团人数后，订单状态变为待发货。

其他页面展示

首页 / 用户中心 / 分类页

产品详情 / 购物车 / 下单页

平台后台管理

丰富的功能插件

可视化模板编辑 / DIY 页面布局

 更新内容

• 【新增】商家入驻模块增加入驻主体类型：个人或企业入驻
• 【新增】商家入驻流程，增加身份证等资质证件校验
• 【新增】APP/小程序端 搭配购模块
• 【新增】拼团模块 
• 【新增】数据采集淘宝天猫京东商品模块
• 【新增】商品长图和主图视频功能
• 【新增】详情页显示最近买家评价信息
• 【新增】即时提现到支付宝余额功能
• 【优化】商品规格字段
• 【优化】移动端支付方式传值
• 【优化】前台部分 CSS 及页面
• 【修复】移动端商品详情页商品属性弹窗显示异常
• 【修复】商品评价统计数据有误的问题
• 【修复】优惠券在多个订单可重复使用的问题

小米工程师在向 AOSP (Android Open Source Project) 提交的一个 commit 中指出，应禁止通过 shell 获取已安装的 APK，理由是某些 APK 可能包含私有资源或内容，因此不应该被允许直接从系统中拉取。

从 commit 的投票情况来看，只有作者自己投了一票赞成票，其余两名参与投票的工程师均是投反对票。所以目前该 commit 已被标记为「Abandoned」状态，意味着不能被合并到 AOSP。

投反对票的工程师认为，小米通过修改权限并非保护 APK 提供的 IP（知识产权）或服务的首选方案。即使禁用了 shell 这个 CL 工具，也还有多种方法可以获得 APK。而且 APK 本身也不是私密文件，如果 APK 包含需要保密的内容，应该通过其他方式——如 DRM（数字版权管理）进行保护。

这名工程师还表示，小米这个 commit 属于其内部产品的需求，而不是一个所有人都会（应该）同意的全平台政策。如果小米需要这样做，应该在特定设备中进行。

另一名投反对票的工程师则直言：“与其提交损害上游的东西，不如直接在自己的 fork 分支内折腾。”

对于多名其他开发者的评论，小米工程师也进行了回复，他认为如果一个 apk 可以通过 ‘adb shell’ 命令被拉取出来，那么就可以被反编译，这对 apk 会有一些安全风险。所以，他认为应该尽可能地确保数据分区的数据安全。

点此查看详情。

作者：vivo 互联网服务器团队-Luo Mingbo

一、Kafka 集群部署架构

为了让读者能与小编在后续的问题分析中有更好的共鸣，小编先与各位读者朋友对齐一下我们 Kafka 集群的部署架构及服务接入 Kafka 集群的流程。

为了避免超大集群我们按照业务维度将整个每天负责十万亿级消息的 Kafka 集群拆分成了多个 Kafka 集群。拆分粒度太粗会导致单一集群过大，容易由于流量突变、资源隔离、限速等原因导致集群稳定性和可用性受到影响，拆分粒度太细又会因为集群太多不易维护，集群内资源较少应对突发情况的抗风险能力较弱。

由于 Kafka 数据存储和服务在同一节点上导致集群扩缩容周期较长，遇到突发流量时不能快速实现集群扩容扛住业务压力，因此我们按照业务维度和数据的重要程度及是否影响商业化等维度进行 Kafka 集群的拆分，同时在 Kafka 集群内添加一层逻辑概念“资源组”，资源组内的 Node 节点共享，资源组与资源组之间的节点资源相互隔离，确保故障发生时不会带来雪崩效应。

二、业务接入 Kafka 集群流程

1. 在 Kafka 平台注册业务项目。

2. 若项目的业务数据较为重要或直接影响商业化，用户需申请创建项目独立的资源组，若项目数据量较小且对数据的完整性要求不那么高可以直接使用集群提供的公共资源组无需申请资源组。

3. 项目与逻辑概念资源组绑定。

4. 创建 topic，创建 topic 时使用 Kafka 平台提供的接口进行创建，严格遵守 topic 的分区分布只能在项目绑定的资源组管理的 broker 节点上。

5. 授权对 topic 的读写操作。

通过上述的架构部署介绍及接入流程接入介绍相信大家有很多相关知识点都与小编对齐了。

从部署架构图我们可以清晰的了解到我们这套集群部署在服务端最小的资源隔离单为“资源组”即在同一个资源组下的多个broker节点之间会有影响，不同的资源组下的broker节点做了逻辑隔离。

上述的相关知识点对齐后我们将开启我们的故障排查之旅。

三、故障情况介绍

故障发生时，故障节点所在资源组的多个 topic 流量几乎全部掉零，生产环境我们对 Kafka 集群的磁盘指标READ、WRITE、IO.UTIL、AVG.WAIT、READ.REQ、WRITE.REQ做了告警监控，由于故障发生在凌晨，整个故障的处理过程持续实践较长，导致了业务方长时间的topic流量整体掉零对业务造成不小的影响。

四、监控指标介绍

4.1 流量监控情况

1、故障节点在故障发生时网络空闲率出现短暂的掉零情况，且与生产流量监控指标一致。一旦生产流量上升故障节点的网络空闲率就同步掉零。

2、Grafana 监控指标中topic生产流量几乎全部掉零。

3、Kafka 平台项目监控中也体现了当前项目的多个topic生产流量指标掉零。

4.2 磁盘指标监控

SDF 盘的IO.UTIL指标达到100%， 80%左右我们认为是服务可稳定运行的指标阈值。

SDF 盘的AVG.WAIT指标达到分钟级等待，一般400ms左右的延迟我们认为是服务可稳定运行的阈值。

4.3 Kafka 服务端日志及系统日志情况

Kafka集群controller节点的日志中出现Input/Output error的错误日志。

Linux 系统日志中出现Buffer I/O error 的错误日志

五、故障猜想及分析

从上述的指标监控中很明显的可以得出结论，故障原因是由于 Kafka broker节点的sdf盘磁盘故障导致的，只需在对应的 Kafka broker 节点上将sdf盘踢掉重启即可恢复。那这样就结束了吗 ？of course not。

对 Kafka 有一定认识的小伙伴应该都知道，创建topic时topic的分区是均匀分布到集群内的不同broker节点上的，即使内部某一台broker节点故障，其他分区应该能正常进行生产消费，如果其他分区能进行正常的生产和消费就不应该出现整个topic的流量几乎全掉零的情况。

如上图所示，topicA 的三个分区分别分布在 brokerA、brokerB、brokerC三个物理主机节点上。

生产者producer向TopicA发送消息时会分别与brokerA、brokerB、brokerC三个物理主机节点建立长链接进行消息的发送，此时若 brokerB 节点发生故障无法向外部提供服务时按照我们的猜想应该不会影响到brokerA和brokerC两个节点继续向producer提供接收消息的服务。

但从监控指标的数据展示来分析当brokerB节点出现故障后topic整体流量掉零与我们的猜想大相径庭。

既然是出现类似了服务雪崩的效应导致了部分topic的整体流量几乎掉零那么我们在猜想问题发生的原因时就可以往资源隔离的方向去思考，看看在整个过程中还有哪些地方涉及到资源隔离的环节进行猜想。

Kafka 服务端我们按照资源组的方式做了 Kafka broker的逻辑隔离且从Grafana监控上可以看出有一些topic的流量并没有严重掉零的情况，那么我们暂时将分析问题的目光转移到 Kafka  client端，去分析 Kafka  producer的发送消息的过程是否存在有资源隔离地方没有做隔离导致了整体的雪崩效应。

六、Kafka 默认分区器的分区规则

对 Kafka 生产流程流程有一定了解的同学肯定知道，Kafka 作为了大数据生态中海量数据的消息中间件，为了解决海量数据的并发问题 Kafka  在设计之初就采用了客户端缓冲消息，当消息达到一定批量时再进行批量消息的发送。

通过一次网络IO将批量的数据发送到 Kafka 服务端。关于Kafka producer客户端缓冲区的设计小编后续会单独一个篇幅进行深入的探索，鉴于篇幅问题不再此处进行详细分析。

基于此处的分析我们对一批消息发送到一个故障节点时的容错方案可以有以下猜想：

1. 快速失败，记录故障节点信息。下次进行消息路由时只路由到健康的节点上。快速释放消息缓冲内存。

2. 快速失败，记录故障节点信息，下次进行消息路由时当消息路由到故障节点上时直接报错，快速释放缓冲区内存。

3. 等待超时，当次消息等待超时后，下次进行消息路由时依然会出现路由到故障节点上的情况，且每次等待超时时间后才释放占用的资源。

上述猜想中，如果是第一种情况，那么每次消息路由只路由到健康的节点上不会出现雪崩效应耗尽客户端缓冲区资源的情况；

第二种情况，当消息路由到故障节点上时，直接拒绝分配缓冲区资源也不会造成雪崩效应；

第三种情况，每次需要在一个或多个超时时间后才能将故障节点所占用的客户端缓冲区资源释放，在海量消息发送的场景下一个超时时间周期内故障节点上的消息足以将客户端缓冲区资源耗尽，导致其他可用分区无法分配客户端缓冲区资源导致出现雪崩效应。

带着上述的猜想打开kafka client producer的源代码分析下defaultPartitioner的分区规则得到如下的分配逻辑：

1. 发送消息时是否指定了分区，若指定了分区那消息就直接发往该分区无需重新路由分区。

2. 消息是否指定了key，若消息指定了key，使用key的hash值与topic的分区数进行模运算，得出消息路由的分区号（对应第三种猜想）。

3. 消息未指定分区也未指定key，使用自增变量与topic的可用分区进行模运算，得出消息路由的分区号（对应第一种猜想）。

七、总结

1. 从源码中分析出若发送消息的时候指定了key，并使用的是 Kafka producer默认的分区分配器请款下会出现 Kafka producer 客户端缓冲区资源被耗尽而出现topic所有分区雪崩效应。

2. 跟业务系统同学了解了他们的发送逻辑确实在消息发送指定了key并使用的是 Kafka producer的默认分区分配器。

3. 问题得到论证。

八、建议

1. 若非必要发送消息时不要指定key，否则可能会出现topic所有分区雪崩效应。

2. 若确实需要发送消息指定key，建议不要使用Kafka producer默认的分区分配器，因为指定key的情况下使用 Kafka producer的默认分区分配器会出现雪崩效应。

九、扩展问题思考

1. 为什么 Kafka producer提供的默认分区分配器要单独将指定key的情况采用topic所有分区进行模运算而在未指定key的采用是自增变量和可用分区进行模运算？

2. 文章中分析的问题均为客户端缓冲区的粒度是producer实例级别的即一个producer共用一块内存缓冲区是否可以将缓冲区的粒度调整到分区级？

   Idea激活2022.2

关于这系列的问题思考与分析，我们将在后续的文章 Idea激活2022.2中讲述，敬请关注。