Merge pull request #589 from didi/master

合并主分支

Author: ZQKC

Releases_Notes.md

@@ -1,4 +1,59 @@
 
+
+## v3.0.0-beta.2
+
+**文档**
+- 新增登录系统对接文档
+- 优化前端工程打包构建部分文档说明
+- FAQ补充KnowStreaming连接特定JMX IP的说明
+
+
+**Bug修复**
+- 修复logi_security_oplog表字段过短，导致删除Topic等操作无法记录的问题
+- 修复ES查询时，抛java.lang.NumberFormatException: For input string: "{"value":0,"relation":"eq"}" 问题
+- 修复LogStartOffset和LogEndOffset指标单位错误问题
+- 修复进行副本变更时，旧副本数为NULL的问题
+- 修复集群Group列表，在第二页搜索时，搜索时返回的分页信息错误问题
+- 修复重置Offset时，返回的错误信息提示不一致的问题
+- 修复集群查看，系统查看，LoadRebalance等页面权限点缺失问题
+- 修复查询不存在的Topic时，错误信息提示不明显的问题
+- 修复Windows用户打包前端工程报错的问题
+- package-lock.json锁定前端依赖版本号，修复因依赖自动升级导致打包失败等问题
+- 系统管理子应用，补充后端返回的Code码拦截，解决后端接口返回报错不展示的问题
+- 修复用户登出后，依旧可以访问系统的问题
+- 修复巡检任务配置时，数值显示错误的问题
+- 修复Broker/Topic Overview 图表和图表详情问题
+- 修复Job扩缩副本任务明细数据错误的问题
+- 修复重置Offset时，分区ID，Offset数值无限制问题
+- 修复扩缩/迁移副本时，无法选中Kafka系统Topic的问题
+- 修复Topic的Config页面，编辑表单时不能正确回显当前值的问题
+- 修复Broker Card返回数据后依旧展示加载态的问题
+
+
+
+**体验优化**
+- 缩短新增集群后，集群信息加载的耗时
+- 集群Broker列表，增加Controller角色信息
+- 优化默认密码为admin/admin
+- 副本变更任务结束后，增加进行优先副本选举的操作
+- Task模块任务分为Metrics、Common、Metadata三类任务，每类任务配备独立线程池，减少对Job模块的线程池，以及不同类任务之间的相互影响
+- 删除代码中存在的多余无用文件
+- 自动新增ES索引模版及近7天索引，减少用户搭建时需要做的事项
+- 优化前端工程打包流程
+- 优化登录页文案，页面左侧栏内容，单集群详情样式，Topic列表趋势图等
+- 首次进入Broker/Topic图表详情时，进行预缓存数据从而优化体验
+- 优化Topic详情Partition Tab的展示
+- 多集群列表页增加编辑功能
+- 优化副本变更时，迁移时间支持分钟级别粒度
+- logi-security版本升级至2.10.13
+- logi-elasticsearch-client版本升级至1.0.24
+
+
+**能力提升**
+- 支持Ldap登录认证
+
+---
+
 ## v3.0.0-beta.1
 
 **文档**
@@ -35,6 +90,7 @@
 - 增加周期任务，用于主动创建缺少的ES模版及索引的能力，减少额外的脚本操作
 - 增加JMX连接的Broker地址可选择的能力
 
+---
 
 ## v3.0.0-beta.0
 

docs/dev_guide/登录系统对接.md

@@ -0,0 +1,199 @@
+
+
+![Logo](https://user-images.githubusercontent.com/71620349/185368586-aed82d30-1534-453d-86ff-ecfa9d0f35bd.png)
+
+## 登录系统对接
+
+[KnowStreaming](https://github.com/didi/KnowStreaming)（以下简称KS） 除了实现基于本地MySQL的用户登录认证方式外，还已经实现了基于Ldap的登录认证。
+
+但是，登录认证系统并非仅此两种。因此，为了具有更好的拓展性，KS具有自定义登陆认证逻辑，快速对接已有系统的特性。
+
+在KS中，我们将登陆认证相关的一些文件放在[km-extends](https://github.com/didi/KnowStreaming/tree/master/km-extends)模块下的[km-account](https://github.com/didi/KnowStreaming/tree/master/km-extends/km-account)模块里。
+
+本文将介绍KS如何快速对接自有的用户登录认证系统。
+
+### 对接步骤
+
+- 创建一个登陆认证类，实现[LogiCommon](https://github.com/didi/LogiCommon)的LoginExtend接口；
+- 将[application.yml](https://github.com/didi/KnowStreaming/blob/master/km-rest/src/main/resources/application.yml)中的spring.logi-security.login-extend-bean-name字段改为登陆认证类的bean名称；
+
+```Java
+//LoginExtend 接口
+public interface LoginExtend {
+  
+    /**
+     * 验证登录信息，同时记住登录状态
+     */
+    UserBriefVO verifyLogin(AccountLoginDTO var1, HttpServletRequest var2, HttpServletResponse var3) throws LogiSecurityException;
+  
+    /**
+     * 登出接口，清楚登录状态
+     */
+    Result<Boolean> logout(HttpServletRequest var1, HttpServletResponse var2);
+  
+    /**
+     * 检查是否已经登录
+     */
+    boolean interceptorCheck(HttpServletRequest var1, HttpServletResponse var2, String var3, List<String> var4) throws IOException;
+  
+}
+
+```
+
+
+
+### 对接例子
+
+我们以Ldap对接为例，说明KS如何对接登录认证系统。
+
++ 编写[LdapLoginServiceImpl](https://github.com/didi/KnowStreaming/blob/master/km-extends/km-account/src/main/java/com/xiaojukeji/know/streaming/km/account/login/ldap/LdapLoginServiceImpl.java)类，实现LoginExtend接口。
++ 设置[application.yml](https://github.com/didi/KnowStreaming/blob/master/km-rest/src/main/resources/application.yml)中的spring.logi-security.login-extend-bean-name=ksLdapLoginService。
+
+完成上述两步即可实现KS对接Ldap认证登陆。
+
+```Java
+@Service("ksLdapLoginService")
+public class LdapLoginServiceImpl implements LoginExtend  {
+  
+
+    @Override
+    public UserBriefVO verifyLogin(AccountLoginDTO loginDTO,
+                                   HttpServletRequest request,
+                                   HttpServletResponse response) throws LogiSecurityException {
+        String decodePasswd = AESUtils.decrypt(loginDTO.getPw());
+
+        // 去LDAP验证账密
+        LdapPrincipal ldapAttrsInfo = ldapAuthentication.authenticate(loginDTO.getUserName(), decodePasswd);
+        if (ldapAttrsInfo == null) {
+            // 用户不存在，正常来说上如果有问题，上一步会直接抛出异常
+            throw new LogiSecurityException(ResultCode.USER_NOT_EXISTS);
+        }
+
+        // 进行业务相关操作
+        
+        // 记录登录状态，Ldap因为无法记录登录状态，因此有KnowStreaming进行记录
+        initLoginContext(request, response, loginDTO.getUserName(), user.getId());
+        return CopyBeanUtil.copy(user, UserBriefVO.class);
+    }
+
+    @Override
+    public Result<Boolean> logout(HttpServletRequest request, HttpServletResponse response) {
+        
+        //清理cookie和session
+      
+        return Result.buildSucc(Boolean.TRUE);
+    }
+
+    @Override
+    public boolean interceptorCheck(HttpServletRequest request, HttpServletResponse response, String requestMappingValue, List<String> whiteMappingValues) throws IOException {
+       
+        // 检查是否已经登录
+        String userName = HttpRequestUtil.getOperator(request);
+        if (StringUtils.isEmpty(userName)) {
+            // 未登录，则进行登出
+            logout(request, response);
+            return Boolean.FALSE;
+        }
+
+        return Boolean.TRUE;
+    }
+}
+
+```
+
+
+
+### 实现原理
+
+因为登陆和登出整体实现逻辑是一致的，所以我们以登陆逻辑为例进行介绍。
+
++ 登陆原理
+
+登陆走的是[LogiCommon](https://github.com/didi/LogiCommon)自带的LoginController。
+
+```java
+@RestController
+public class LoginController {
+  
+
+    //登陆接口
+    @PostMapping({"/login"})
+    public Result<UserBriefVO> login(HttpServletRequest request, HttpServletResponse response, @RequestBody AccountLoginDTO loginDTO) {
+        try {
+             //登陆认证
+            UserBriefVO userBriefVO = this.loginService.verifyLogin(loginDTO, request, response);
+            return Result.success(userBriefVO);
+          
+        } catch (LogiSecurityException var5) {
+            return Result.fail(var5);
+        }
+    }
+
+}
+```
+
+而登陆操作是调用LoginServiceImpl类来实现，但是具体由哪个登陆认证类来执行登陆操作却由loginExtendBeanTool来指定。
+
+```java
+//LoginServiceImpl类
+@Service
+public class LoginServiceImpl implements LoginService {
+
+    //实现登陆操作，但是具体哪个登陆类由loginExtendBeanTool来管理
+    public UserBriefVO verifyLogin(AccountLoginDTO loginDTO, HttpServletRequest request, HttpServletResponse response) throws LogiSecurityException {
+      
+        return this.loginExtendBeanTool.getLoginExtendImpl().verifyLogin(loginDTO, request, response);
+    }
+
+
+}
+```
+
+而loginExtendBeanTool类会优先去查找用户指定的登陆认证类，如果失败则调用默认的登陆认证函数。
+
+```java
+//LoginExtendBeanTool类 
+@Component("logiSecurityLoginExtendBeanTool")
+public class LoginExtendBeanTool {
+
+    public LoginExtend getLoginExtendImpl() {
+        LoginExtend loginExtend;
+      	//先调用用户指定登陆类，如果失败则调用系统默认登陆认证
+        try {
+          //调用的类由spring.logi-security.login-extend-bean-name指定
+            loginExtend = this.getCustomLoginExtendImplBean();
+        } catch (UnsupportedOperationException var3) {
+            loginExtend = this.getDefaultLoginExtendImplBean();
+        }
+
+        return loginExtend;
+    }
+}
+```
+
++ 认证原理
+
+认证的实现则比较简单，向Spring中注册我们的拦截器PermissionInterceptor。
+
+拦截器会调用LoginServiceImpl类的拦截方法，LoginServiceImpl后续处理逻辑就和前面登陆是一致的。
+
+```java
+public class PermissionInterceptor implements HandlerInterceptor {
+
+
+    /**
+     * 拦截预处理
+     * @return boolean false:拦截, 不向下执行, true:放行
+     */
+    @Override
+    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
+       
+      	//免登录相关校验，如果验证通过，提前返回
+				
+      	//走拦截函数，进行普通用户验证
+        return loginService.interceptorCheck(request, response, classRequestMappingValue, whiteMappingValues);
+    }
+
+}
+```
+

docs/dev_guide/解决连接JMX失败.md

@@ -1,19 +1,14 @@
 
-![Logo](https://user-images.githubusercontent.com/71620349/185368586-aed82d30-1534-453d-86ff-ecfa9d0f35bd.png)
 
+![Logo](https://user-images.githubusercontent.com/71620349/185368586-aed82d30-1534-453d-86ff-ecfa9d0f35bd.png)
 
 ## JMX-连接失败问题解决
 
-- [JMX-连接失败问题解决](#jmx-连接失败问题解决)
-  - [1、问题&说明](#1问题说明)
-  - [2、解决方法](#2解决方法)
-  - [3、解决方法 —— 认证的JMX](#3解决方法--认证的jmx)
-
-集群正常接入Logi-KafkaManager之后，即可以看到集群的Broker列表，此时如果查看不了Topic的实时流量，或者是Broker的实时流量信息时，那么大概率就是JMX连接的问题了。
+集群正常接入`KnowStreaming`之后，即可以看到集群的Broker列表，此时如果查看不了Topic的实时流量，或者是Broker的实时流量信息时，那么大概率就是`JMX`连接的问题了。
 
 下面我们按照步骤来一步一步的检查。
 
-### 1、问题&说明
+### 1、问题说明
 
 **类型一：JMX配置未开启**
 
@@ -43,6 +38,26 @@ java.rmi.ConnectException: Connection refused to host: 192.168.0.1; nested excep
 java.rmi.ConnectException: Connection refused to host: 127.0.0.1;; nested exception is: 
 ```
 
+**类型三：连接特定IP**
+
+Broker 配置了内外网，而JMX在配置时，可能配置了内网IP或者外网IP，此时 `KnowStreaming` 需要连接到特定网络的IP才可以进行访问。
+
+比如：
+
+Broker在ZK的存储结构如下所示，我们期望连接到 `endpoints` 中标记为 `INTERNAL` 的地址，但是 `KnowStreaming` 却连接了 `EXTERNAL` 的地址，此时可以看 `4、解决方法 —— JMX连接特定网络` 进行解决。
+
+```json
+ {
+  	"listener_security_protocol_map": {"EXTERNAL":"SASL_PLAINTEXT","INTERNAL":"SASL_PLAINTEXT"},
+  	"endpoints": ["EXTERNAL://192.168.0.1:7092","INTERNAL://192.168.0.2:7093"],
+  	"jmx_port": 8099,
+  	"host": "192.168.0.1",
+  	"timestamp": "1627289710439",
+  	"port": -1,
+    "version": 4
+  }
+```
+
 ### 2、解决方法
 
 这里仅介绍一下比较通用的解决方式，如若有更好的方式，欢迎大家指导告知一下。
@@ -76,26 +91,36 @@ fi
 
 如果您是直接看的这个部分，建议先看一下上一节：`2、解决方法`以确保`JMX`的配置没有问题了。
 
-在JMX的配置等都没有问题的情况下，如果是因为认证的原因导致连接不了的，此时可以使用下面介绍的方法进行解决。
+在`JMX`的配置等都没有问题的情况下，如果是因为认证的原因导致连接不了的，可以在集群接入界面配置你的`JMX`认证信息。
+
+<img src='http://img-ys011.didistatic.com/static/dc2img/do1_EUU352qMEX1Jdp7pxizp' width=350>
+
 
-**当前这块后端刚刚开发完成，可能还不够完善，有问题随时沟通。**
 
-`Logi-KafkaManager 2.2.0+`之后的版本后端已经支持`JMX`认证方式的连接，但是还没有界面，此时我们可以往`cluster`表的`jmx_properties`字段写入`JMX`的认证信息。
+### 4、解决方法 —— JMX连接特定网络
 
-这个数据是`json`格式的字符串，例子如下所示：
+可以手动往`ks_km_physical_cluster`表的`jmx_properties`字段增加一个`useWhichEndpoint`字段，从而控制 `KnowStreaming` 连接到特定的JMX IP及PORT。
 
+`jmx_properties`格式：
 ```json
 {
-    "maxConn": 10,           # KM对单台Broker的最大JMX连接数
-    "username": "xxxxx",     # 用户名
-    "password": "xxxx",      # 密码
+    "maxConn": 100,           # KM对单台Broker的最大JMX连接数
+    "username": "xxxxx",     # 用户名，可以不填写
+    "password": "xxxx",      # 密码，可以不填写
     "openSSL": true,         # 开启SSL, true表示开启ssl, false表示关闭
+    "useWhichEndpoint": "EXTERNAL"  #指定要连接的网络名称，填写EXTERNAL就是连接endpoints里面的EXTERNAL地址
 }
 ```
 
 &nbsp;
 
-SQL的例子：
+SQL例子：
 ```sql
-UPDATE cluster SET jmx_properties='{ "maxConn": 10,	"username": "xxxxx", "password": "xxxx", "openSSL": false }' where id={xxx};
-```
+UPDATE ks_km_physical_cluster SET jmx_properties='{ "maxConn": 10, "username": "xxxxx", "password": "xxxx", "openSSL": false , "useWhichEndpoint": "xxx"}' where id={xxx};
+```
+
+注意：
+
++ 目前此功能只支持采用 `ZK` 做分布式协调的kafka集群。
+
+