KOCA-监控运维平台-注册中心管理，KOCA在2.4版本支持了erueka注册中心认证功能，但是现在添加了认证功能的注册中心无法获取到对应的服务实例。
建议 KOCA 3.x 重要调整和一些规约
-
KOCA 项目主要分为以下几类：
- koca-base：功能聚焦在自有协议、开源组件扩展与封装、标准的实现等；包含一些基础框架、核心包（接口、规范）、核心功能、开发框架等；需要各种标准。一个仓库
- koca-security：认证、授权、鉴权、权限控制、安全增强，基于 Spring Security，兼容。一个仓库
- koca-boot：负责 koca-framework、koca-security 的装配、配置参数绑定、扩展指标监控，需要兼容 Spring Boot XX。一个仓库
- koca-cloud：包含服务注册与发现、网关、调用链路，需要兼容 Spring Cloud，尤其是 Spring Cloud Commons。多个仓库
拆分目前的
koca-base，将koca-cloud相关功能（调用链路、监控、服务注册与发现、统一配置）、版本管理等拆分到koca-cloud组，将其它独立功能拆分为独立工程
项目的模块层次不要太多，尤其是
koca-framework，建议模块深度 2
建议在 Gitlab 上单独开设
koca-projects/koca-cloud项目组，koca-projects包含koca-base/koca-security/koca-boot等常规项目，koca-cloud包含koca-traing/koca-config等微服务、监控类项目
建议创建 GitLab
koca-projects-experimental项目组，用于存放孵化中的项目，项目发布 1.0.0 版本之前，在孵化器中迭代。
-
Boot App ？
-
Maven 坐标：
- koca-base：
com.[**.]koca.base:koca-xxxx，例如com.koca.base:koca-core - koca-boot：
com.[**.]koca.boot:koca-boot-xxxx，例如com.koca.boot:koca-boot，com.koca.boot:koca-boot-autoconfig - koca-cloud：
com.[**.]koca.cloud:koca-cloud-xxxx，例如com.koca.cloud:koca-cloud-gateway
- koca-base：
package 前缀与
groupid相同。
package 建议去掉
yf，如果 KOCA 已注册商标、知识产权，建议 package 去掉szkingdom
为什么要把
koca-base和koca-boot拆开？解决很多开发人员只会使用@Autowired，只会@SpringBootTest的问题。
- 主要由
koca-boot-dependencies、koca-cloud-dependencies管理依赖，koca-base应该尽量少依赖三方jar，提供koca-base-bom管理其依赖。 - 三方组件升级作为版本迭代日常需求和任务。
- 请勿重复造轮子，除非开源的轮子不满足需求，如果非得造，必须经过评审，参与评审的人对评审结果负责，新轮子一定要与已有的轮子适配或可转换。
- 使用开源组件是对其进行集成、封装、优化、扩展，不能使其原本支持的功能不支持。
-
koca-boot-autoconfig中所有自动配置的配置参数，前缀均为koca。所有可以配置yaml|properties的参数均需要使用实体绑定。严禁直接使用@Value直接使用（部分特殊参数除外）。koca-cloud-**的配置前缀为koca.cloud - 对于非空实例（成员）属性，应声明为
final，使用构建方法注入，严禁使用@Autowired。 - 每个仓库一个工程，仓库根目录即是构建文件
pom.xml、build.gradle的所在位置 - Java 工程根目录需要有
Maven / Gradle Wrapper，方便构建。 - 工程根目录需要有
README.md，该文件内容包含当前工程简介、如何构建、如何开发、代码格式模板以及其它信息。 - 工程中如果有自定义格式文件，使用
.gitattributes标识文件类型，参考：https://github.com/alexkaratarakis/gitattributes 。需要有.gitignore - Boot App 要通过开关兼容微服务架构和单体应用，调用链路、监控等与功能无关特性也要提供运行时开关、编译打包时可选
- 分支命名：
master，develop，feture-***，1.0.x，1.1.x，严禁使用具体的版本号做为分支号，例如：1.4.1。 - 发版本打 Git tag 对应的提交日志必须为“Release X.Y.Z”，包括
.RELEASE/-SNAPSHOT/-M1/-RC这些版本，同一仓库多个位置的修改合并为一个提交，尽量使用插件将版本号统一为一个变量，目前大部分使用“Update pom.xml”，无任何参考价值，且有多次提交。目前还存在改版本号的提交与打tag的提交不一致的情况。
提交日志建议中文，发布提交日志可以用“Release X.Y.Z”，规范且显眼。
建议发布提交日志仅仅提交本地，然后在此提交上建 tag，然后推送 tag，不建议直接在分支上改了提交推送，如果修改后的集成、打包无法通过，需要再次修改，之前的版本号修改提交无法移动和变更。
下个版本开始的提交日志为“Next development version (vX.Y.Z-SNAPSHOT)”
- 当写提交信息时，请遵循 这些约定 ， 如果你正在修复一个现有的问题，请在提交的最后添加
Fixes gh-XXXX消息（其中XXXX是问题号）。 - 对代码格式、编码规范执行严格审查。发版前要完成对代码的优化，优化参考编码规范、Sonar 问题报告。
- 注册运营 KOCA 公众号。
KOCA框架调整
目标
-
保证业务代码使用的兼容性（优先考虑）
可以修改配置或者依赖，但不能影响业务原代码
-
独立koca-base、koca-boot、koca-cloud项目; koca-security待定
各项目中parent pom.xml各自定义参考spring-projects中的定义
-
koca-boot兼容springboot 2.5.7；统一koca模块 配置标准：均以koca. 开头 ，借鉴springboot配置迁移功能
-
遵循规约优于配置
实施过程
原koca-admin、koca-studio、koca-amo 升级到3.0，但依赖koca-base 2.7.0-RELEASE进行开发，流水线调整暂不编译koca-base 源码
koca-base模块拆分
约定
- 各模块不得依赖spring-boot
- 禁止使用@Autowired, 尽量少用@Value
- 建议各模块层次不超过2
模块规划
- koca-core:核心包，koca协议及系统接口
- koca-common-tools: 工具库 libaray, 提供各种Utils工具类, 线程上下文工具 （代码package要兼容之前版本）
- koca-multi-datasouce: 多数据源方案
- koca-mybaits: mybatis 扩展
- koca-jdbc: 数据批量处理、sql显示调用，基于JdbcTemplate扩展
- koca-web: 针对spring-web的扩展，包括Controller统一异常处理等，filter拦截等处理
- koca-websocket: 消息推送扩展
- koca-validation:参数校验
- koca-bex: 业务执行引擎
- koca-wechat: 对接微信和企业微信的工具包
- koca-id-generator: 主键生成器
- koca-kcbp: 调用xp bp的工具包
- koca-distributed-lock:分布式锁
- koca-mq: 通用消息队列
- koca-file: 文件处理，包括上传下载，md5校验等
- …
- integration-test :集成测试模块,不对外发布包
兼容性测试
koca-base 各模块使用第三方开源库时，尽量评估出可用范围，如koca-cache适用于spring-framework 4.x-5.x
koca-boot 模块拆分
- koca-boot-autocofingure: base各模块自动装配
- koca-boot-denpendecies: boot相关版本依赖管理
- koca-boot-xxx-starter: 各种starter, 方便快速使用
- koca-boot-actuator
- boot-integration-test: 集成测试
koca-cloud 按库拆分
koca-cloud-gate
- koca-cloud-gateway
koca-cloud-config
- koca-cloud-config-client:
- koca-cloud-config-server
koca-cloud-registry
- koca-cloud-registry-client: 注册中心客户端
- koca-cloud-registry-manager:
- koca-cloud-registry-eureka-server
koca-cloud-parent
koca-cloud-dependencies
koca-cloud-tracing
具体操作点参考
koca-base(koca-framework)
koca-core
com.szkingdom.koca.core.protocol 返回协议
com.szkingdom.koca.core.exception 返回异常协议
koca-common-tools
com.szkingdom.koca.core.util 工具包
com.szkingdom.koca.core.crypto 加解密工具
线程上下文
koca-crypto
koca-crypto 配置加解密
koca-spring-support
com.szkingdom.koca.core.context 上下文获取
koca-multi-datasource
com.szkingdom.koca.support.datasource 多数据源
koca-jdbc 批量操作数据库
koca-mybatis
com.szkingdom.koca.support.mybatis mybatis相关各种
koca-web
com.szkingdom.koca.support.exception 异常拦截处理
com.szkingdom.koca.support.validation 参数校验
koca-support
com.szkingdom.koca.core.i18n 国际化 i18nUtils
com.szkingdom.koca.support.interceptor 国际化语言拦截器
com.szkingdom.koca.support.json json序列化跟反序列化
com.szkingdom.koca.support.logback log脱敏处理
挪到koca-registry
com.szkingdom.koca.support.registry 注册中心配置转换
koca-boot
koca-boot-starter
com.szkingdom.koca.core.config 配置扫描
参考
- totodi.md
- KOCA3.x 重要调整和一些规约.md
配置迁移
koca 原2.x 之前配置迁移到到 3.0配置兼容方案
如 auth.enabled 变更为 koca.security.enabled
引入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-properties-migrator</artifactId>
</dependency>
在工程resouces/META-INF目录下添加additional-spring-configuration-metadata.json
修改如下内容：
{
"properties": [
{
"name": "auth.enabled",
"type": "java.lang.Boolean",
"description": "安全认证控制开关",
"deprecation": {
"replacement": "koca.security.enabled",
"level": "error"
}
}
]
}
KOCA 3.x Maven坐标规约
背景
KOCA 3.x 将进行一系列调整，包括一些规约调整；其中重点是进行koca框架按 base、boot、cloud 进行拆分，涉及到maven坐标调整；
KOCA后续涉及对外交付，需要更符合公认的规约。
现状
Maven GroupID and ArtifactId
-
KOCA
szkingdom.yf.koca.base koca-xxx
szkingdom.yf.koca.admin koca-admin-xxx
szkingdom.yf.koca.studio koca-studio-xxx
szkingdom.yf.koca.amo koca-amo-xxx
szkingdom.yf.component.workflow workflow-xxx 工作流
szkingdom.yf.component.report report-xxx 报表
-
KACE
szkingdom.jr.kace.boot kace-xxx
szkingdom.jr.kace.cloud kace-xxx
-
FS
com.szkingdom.fs koca-fs-xxx
规划
KOCA3.x Maven坐标 GroupId 均以 com.szkingdom.koca （com.公司.项目 参照com.alipay.sofa等）开头.
建议对KOCA进行适配和扩展的项目 如KACE、FS 等 ，使用如下maven坐标命名方式：
| 项目 | 模块 | GroupId | ArtifactId | 说明 |
|---|---|---|---|---|
| KOCA | koca-base | com.szkingdom.koca.base | koca-xxx | |
| KOCA | koca-boot | com.szkingdom.koca.boot | koca-boot-xxx | |
| KOCA | koca-cloud | com.szkingdom.koca.cloud | koca-cloud-xxx | |
| KOCA | … | com.szkingdom.koca.xx | koca-xx-xxx | 其它扩展 |
| KACE | kace-boot | com.szkingdom.kace | ||
| FS | … | com.szkingdom.fs | koca-fs-xx | |
补充说明
- 关于KOCA GroupId 调整，建议不要进行手动调整，KOCA小组会提供groupId装换工具。
- 关于工作流和报表组件坐标，暂不调整
- 关于 koca-boot-starter 的ArtifactId 参考如下实现 koca-boot-starter-xxx（参照spring-boot-starter-xx），而不是单纯的作为第三方spring-boot-starter的扩展
提供统一转换工具，将路径下所有对应文件坐标进行修改，可以通过命令行参数指定，java -jar pom-property-replace.jar -root 指定扫描路径 -old 需要替换的内容 -new 替换成的内容。 默认路径为jar包所在路径，默认old为"szkingdom.yf.koca"，默认new为"com.szkingdom.koca"。 注意输入值是否需要转义。pom-property-replace.zip (225.6 KB)
json转excel工具，能将指定路径下的additional-spring-configuration-metadata.json文件转为excel，一个json文件对应一个excel，java -Dfile.encoding=utf-8 -jar json2excel.jar -root 指定转换文件的根路径 -output 指定excel输出的路径(会在该路径生成excels文件夹)。root和output默认值都是jar包所在路径。 注意 -Dfile.encoding=utf-8指定编码格式，不然可能会乱码。
json2excel.zip (15.5 MB)
bex引擎遇见一个可优化的地方，版本是2.7.1.1-RELEASE。
测试api接口，不传任何数据，即body为空，依然可以通过bex层进入进入接口，导致接口容易出现NPE。
这点是否可以优化一下，还是在其他的高版本已做处理。
koca-support-2.4.0版本中的GlobalExceptionHandler对于入参校验抛出的ConstraintViolationException虽然可以捕获，但是返回结果中的detail不是具体的信息，而是全限定类名。
我debug源码的时候发现有可能的代码在com.szkingdom.koca.support.exception.GlobalExceptionHandler类中的result.setDetail(cause.getClass().getName());这行代码中。
在3.0及之后的版本中以修复改问题； 针对koca-support2.4.0版本。建议业务扩展自定义异常实现，覆盖该逻辑
收到反馈
koca cli 4.5-2，或者4.2 创建的项目，选择的4.4模板，如果在config存在APP_LOGO（不设置使用默认），会导致logo丢失。 建议是不给默认logo，注释一下大概怎么弄自定义的就行。
- 低码平台设计器、渲染器支持maven的方式与后端项目整合至一起，便于快速开发与调试
- 低码平台前端脚手架支持生成时设置访问地址，由脚手架修改相关配置文件及nginx配置文件，以便快速部署，减少调试所需时间
- 低码平台相关组件各属性相关描述文档不够完善
目前koca框架不支持redis集群节点异常后自动切换，导致集群TA断开部分redis后无法登录访问，需要优化
您好，目前建投线上在使用导出组件koca-admin-export:5.2.4进行前端页面查询数据全量导出时出现了超时报错的情况。原因为全量数据过大，导致网关接口调用超时报错。
是否能将整个导出改为异步导出，在异步线程中分阶段更新进度信息。通过循环调用查询进度信息来避免单接口超时。并增加个警告提示，在勾选全选或者多页数据增加警告二次确认。如果操作员执意要做的话，中途也可以通过页面按钮直接取消？