分布式 id 为什么不用推特的 snow 算法生成，uuid 的缺点太明显了

不难

看下结果集数据量，navicat fetch 的可能不是全部数据。

我司电信项目的并发标准是日常 500qps, 峰值 3 倍也就是 1500qps，实际压测中可以达到 10000qps，当然和互联网公司没得比，真正的互联网公司的高并发至少要 10w 级

从设计模式的单一职责原则来说不建议 service 的互相调用，相似的业务也应该由多个 Dao 重新组合完成实际业务，但是这样会带来大量冗余，好处是各个 service 完全独立没有相互耦合。相对的 service 互相调用则可以使得代码更为简洁业务上的相关性也体现在了代码上，在需要修改时只需要修改被依赖的 service，在重构时有很大的作用。业界对于耦合十分厌恶，比较互联网项目基本都拆除了外键，所以 service 只调用 dao 是一种更严谨的方式，service 之前的相互依赖一旦随着项目推进逐渐增多就会变成项目的负债让项目的推进越来越难。如果项目中没有严格规定的话，要考虑好两个 service 所对应的顶层业务是否需要这种关联性，需要则 service 调用 service，不然还是调用 dao 重新组合业务好了(这种方式调优时也有明显优势)。

instrument、aop、asm、javasist

做 CI 不 pull 怎么行，封版就是让大家过个好年

用 docker 好一点，但也有 windows 的版本

me too

老接口有很多。。。而且一般也没啥动力重构

那么多链路，浏览器、反向代理、安全校验、业务校验，一般根本到不了数据库，数据库本身也有对数据块大小的限制

为了个剪切板，我升级了 windows 的开发版。。。不过真的还挺好用

新版不是出了个 Services

干掉所有索引包括但不限于主键、外键，然后导出后再加上，数据迁移的基本常识

感觉还不如研究下怎么调整线程数、数据库连接这些东西。。。

泛型擦除，编译器不保留泛型信息，只能自己强转

@ARhen 对的，比较适合分布式架构，集中管理配置文件，还可以实现一些开关值的动态刷新(数据库连接这种不会重新建立)

因为你们的业务大概率不适合 Restful，标准的 Restful 自然要通过请求方式标识资源操作类型，但实际项目中的复合业务可能包含增删改查的多个属性，从语义上就不好界定，不如把这部分简化掉，而且 http 码本身的粒度不够，大概率还是要自定义响应码和响应描述，和 Restful 也不是很搭

@ARhen jar 的话可以直接用 vim 修改的，而且本身 spring 也提供了配置文件外置的方式(个人觉得不好用), 配置这块最好还是使用专业的配置中心，也有利于配置的复用和管理，比如阿里的 nacos