Aresxue

2025 年了还有这种讨论，当真是印证了历史发展总是螺旋式上升的这句话。

微服务在大公司是必需品，至于中小公司用不用微服务的标准是能否玩的明白，然后实际中大部分人和公司确实玩不明白，确实难绷。

@CodeCaster 瞄了一眼貌似你们的框架主要还是面向 AI 的，你们这个方案在传统工程领域可能没那么适用，因为你们解决的只是运行时问题，微服务还有很多其它的问题，比如代码仓库，除了 google 喜欢且有能力玩好 monorepo ，其它的主流公司还是 Multirepo 模式。如果只是为了解决运行时问题，SofaBoot 的模块化开发和 SOFAArk 等方案也都相对成熟了，甚至更极端些直接用 Faas 好了。

感谢 DeepSeek-R1 和 GPT 4o ，以下为当前页面的总结
### **中划线（-）**

**优点**

1. **视觉友好**
- 无驼峰大小写混淆（如**`i`**和**`l`**视觉近似问题）
- 空格替代感强，单词分隔清晰（**`get-list`**vs**`get_list`**）
2. **技术兼容性**
- 与域名规范一致（域名不支持下划线）
- 避免 HTTP 协议中路径大小写敏感问题（全小写统一）
- 符合 Google SEO 推荐（[**官方文档**]( https://developers.google.com/search/docs/crawling-indexing/url-structure)），传统网站和 SEO 实践中，多推荐使用中划线
3. **输入便捷性**
- 无需切换大小写，打字效率更高
- 符合传统网站习惯（如**`about-us`**、**`contact-info`**

**缺点**

1. **前端工具兼容性**
- 使用**`-`**分割路径可能导致 TS 模型生成工具解析困难（需额外配置）
- 某些自动生成的 API 工具不便生成含中划线的路径
2. **复制粘贴体验**
- 在某些编辑器中，双击选中时，中划线可能被切断（依赖编辑器配置修正），导致不易选中整个字符串。

### **下划线（`_`）**

**优点**

1. **开发工具友好**
- 双击复制时，下划线会被整体选中（无需配置编辑器）
- 与部分编程风格（如 Python 的**`snake_case`**）一致
2. **规避大小写问题**
- 全小写下划线无大小写敏感风险

**缺点**

1. **视觉与功能性争议**
- 下划线在长 URL 中与空格区分度低（如**`get_list`**vs**`getlist`**），可能与空格混淆
- 域名不支持下划线，路径中混用可能引发混淆
2. **服务器配置风险**
- Nginx 等服务器默认不支持 URL 中的下划线（需手动启用）

### **驼峰**

**优点**

1. **开发友好性**
- 与后端代码风格（如 Java 的驼峰命名）高度一致
- 节省字符长度（如**`getList`**vs**`get-list`**）

**缺点**

1. **用户体验风险**
- 手动输入易混淆（如**`i`**vs**`L`**）
- 部分客户端可能自动转全小写导致 404
- **输入不便**：需要在输入时切换大小写，使用上稍显麻烦
2. **协议兼容性问题**
- HTTP 路径大小写敏感，需严格匹配（前端/运维易出错）

总的来说，选择哪种格式需考虑具体应用场景的约束和需求，如 SEO 友好性、开发工具兼容性、团队编码规范等。中划线在较多场合被优选，尤其是在 SEO 和 URL 命名中。

java 的 orm 是个月经贴了，但说实话现存的 orm 都不好用，在当前的 JVM 设计下也很难看到曙光，这才是 mybatis 还能苟延残喘的原因， 作为第四代编程语言的 sql 在数据处理这个领域语法的简洁性超过 java 这个三代语言太多了，甚至可以说 sql 语法的易用性、简洁性超出了绝大多数编程语言，在这个背景下用编程语言代替 sql 只会带来更多的工作量，而 orm 的优势（数据库适配性、可维护性）等等很难打动用户。

@4ra1n 这里其实还有个更安全的方式，把 arthas 源码搞下来，然后自己开发一个新的 command ，可以直接复用 arthas 的 sc 指令( sc *)，然后自己做 class->jar 文件的计数处理即可，这样可以使用 attach 模式而不是 premain ，对业务更安全影响也更小。

这个诉求没这么复杂，java agent 把 instrumentation 的引用保存起来就行了，然后放线上去接受真实流量，跑个一天或者手动触发业务操作，再把某台容器从注册中心剔除掉，到这台容器上调用 http 接口，接口里面用 java.lang.instrument.Instrumentation#getAllLoadedClasses 获取所有的 class ，然后对 class 所在 jar 包去重就行了

分本地还是线上，本地环境 3 楼的策略你能搞完绝对够用了，线上环境就要复杂的多了，maven 本身就有一些调优参数。

不用就行了，说实话对开源来说这个算是屁大点事，Linus 以前还天天 fuck NVIDIA 呢。
不过这框架我还真用过，语法思路问题不大（抄的 mybatis-plus ），但是明显作者技术功力不到家，对底层序列化还有很多地方的处理都有 bug ，另外和 spring-data-elasticsearch 的互兼容性做的比较差，导致最后还是弃用了，我想要的其实更多的还是一个基于 spring-data-elasticsearch 的语法糖框架，毕竟 spring-data-elasticsearch 的扩展和细节处理已经有很多年的积累了。

Controller -> Mapper -> Service ，外部定义越早越好，对接的前端和其它三方可以直接查看 Controller 申成的接口文档，Mapper 其实主要指的是底层模型，这块是需要和老板/产品达成一致的，Service 指的是内部服务一般来说调整更自由，不管是改名字还是职责还是拆分都好说一些。