基于koca框架的建议
这个帖子置顶一下
可以。很强！以后我们就在这里提建议。
1 个赞
欢迎多多提建议
没问题，欢迎
由于项目需求。希望可以支持后端自定义会话过期时间
auth.security.session-storage.session-expire=1800 #过期时间，单位s，默认1800s
该过期时间是全部会话的过期时间。是想自定义不同登录接口的会话过期时间吗？
已经确认需求为设置token过期时间，通过配置auth.security.jwt.expireTime 默认1800000 单位ms设置
KOCA升级版本时，能否给出一个版本升级说明例如
1、从2.1升级到2.2有哪些变动，升级步骤是什么；
2、maven使用的pom文件需要添加或者去除什么样的依赖；
3、有哪些方法和类是废弃的，替代方案是什么
你好，KOCA每次升级，在我们的官网在线文档以及交付件的离线文档中都是有每个版本的升级说明的哦~~ 具体在线文档地址：http://10.202.63.8:9000/#/md/Release_Note/2_3_Release_Node
使用koca-client完成服务间远程调用，开启hystrix（隔离策略使用“线程”），远程服务通过AuthContextHolder.getPrincipal()拿不到用户信息。
koca-cloud-msa-starter本身是包含netflix-hytrix依赖的，启用hystrix是合理的操作。建议koca-client在设置header:trustedprincipal的时候，考虑非同一线程上下文的场景。
多谢反馈，后续会进行处理
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)