不建议用 spring security ，我记得是在哪里看过一篇文章，spring security 是前后端不分离时代的思路——全流程控制，从后端一直控制到前端。所以它才实现的如此麻烦，如此的“累赘”，而你现在开发的东西基本上都已经是经历过前后端分离洗礼后的，所以你用这玩意就觉得万分不适配。


@Chinsung 你的感觉是没错的，shiro 勉强还好点，给了一些自由发挥的空间，spring security 完全是把你框死必须按他那套“大而全的全领域控制”逻辑走。

个人真不建立在比较简单的场合用 shiro 和 security 。尤其是 security ，根本就不适合目前这种后端不吐出 html ，只吐数据，需要轻量化 token 的场合

@MoonLin 不是有说法威联通的软件差的很远吗？不然黑群晖到处都是，黑威联通的没几个啊

这个问题，10 年前其实就有文章提到：那篇文章是这么说的，现代系统变的越来越复杂——它举例是最新的民用航空飞机，说再顶尖的工程师也无法窥整个飞机的全貌，只能关注顶层总装，分系统的细节必须由其它人完成。这是必然的事情，这篇文章还很忧虑的说，有没有可能会有一天，整个系统的复杂程度，会复杂到哪怕只关注顶层，人脑也无法理解呢。

所以你的担心是客观事实，但是也没必要焦虑，因为这是这个时代所有工程师都必须面对的问题。
至于你说的，如何评估一个系统能够承担的工作量。这个问题更加复杂一些。因为现实中的业务是千奇百怪的。单一条件下的任务说测试出来的负载量很难适应更复杂的环境。所以你如果想挑战你的系统到底能胜任多少任务这个问题，除了做实验没有其他办法。也就是说这个东西是试出来的。哪怕是官方给出的，他自己的测试都不一定适应你所使用的使用环境。

@Juszoe 其实这是我自己在考虑要不要进行优化，客户那边，还没有进一步反馈。

它这个东西，不单单是算 618 期这么简单，是用户点击任意一期，你都得拿到这一期前 618 期的数据。

预先算题是不行的，因为历史记录已经高达 6935 期。要把这么多期都算出来，那可要不少时间。

可能上面有个人说的落盘是正道，我现在也想干脆把计算和展示分开算了，用户想重新算就点计算按钮然后等时间，平时就是展示历史数据，切换的也快

@phrack 这位甲方自认为能从以前的数据里找到规律，所以他设计的算法有大量从以前的数据里追溯的


@wxf666
1.目前并没有“以前算过”这个概念，因为并没有把历史数据存盘，每次都是针对某一期开始算

2.循环搜 7w 次耗时 50ms ，我也觉得这有点慢，但是我现在实在想不出该优化哪里，对比字符串就是 "xxxx".indexof("xxxx")。并没有特别用什么，
EveryThing 啥的应该是用 C++的吧，它那应该是某种特化场景，我估计我肯定比不了。因为我这里面有大量 for 循环遍历 list ，

@GopherRustaceans
因为 css 就不是编程语言，它是查表，从思路上说就和一般概念的编程语言就不一样。

而且 css 这个鬼玩意，它本质不是为 GUI 系统设计的，它最初的出发点是做排版系统，排版系统和 GUI 系统有交集，但并不是一回事，有点像轿车和皮卡的关系。现代 web 开发更多是做 GUI ，做展示页（排版）的时候比较少。这存在不匹配的阻尼。
然后就是 CSS 最初的设计者，按照她自己的说法，她的设计更符合排版系统的需求——她把 CSS 设计成了一个非正交系统。什么叫非正交呢？所谓正交的系统，你动了 A ，不会影响到 B 。但是非正交系统不是，你动了 A ，B 会跟着跑，但是它还不会直观的告诉你，你得凭经验。CSS 里到处都充斥这种和“隐藏条件”一样的玩意，导致 CSS 的开发，必须背表，大约有几十种组合，如果这个人对这些表背的滚瓜烂熟，用的随心所欲，那它就不会对 CSS 产生任何怀疑。问题是这种思路它就不是传统编程的思路。

即使是前端，也没几个真敢说自己对 css 很熟练的，证据就是这些前端在拿到一个别人开发的，布局有问题的界面时，他们绝大部分时候的选择，就是干脆的自己重新写一遍 css ，而不是像传统编程开发那样，去 debug 一下找到有问题的代码在哪里。CSS 是很难 debug 的，因为非正交的原因，造成当前问题的原因可能是十万八千里之外的一个盒子的输入参数，这种隐藏条件在 CSS 里比比皆是。

一般来说，熟悉 java 的，学习 js 的一点都不难，但是要搞定 CSS 就千难万难。而我见过那种真能熟练 CSS 的的人，他自述它写 CSS 的时候戴着耳机听歌，但是写 JS 的时候就不敢。注意证明这玩意有多大的思维鸿沟，你擅长一边，就很难擅长另外一边。所以这是壁垒

独立开发者 X
顶尖销售 √

楼主这种，就是解释的太多，谁让你和对面谈那么久的？还“很真诚地告诉他我确实不需要。希望以后不要打扰我了”？

我这么说，你这种在这种推销电话的上级评估就是典型的软柿子，有机可乘，属于重点可能性目标。人家当然要屡次来骚扰你。

正确应对这种骚扰电话的办法：
接起来；
“你好，哪里？” （不要自爆家门，直接问对方是谁）
对方开始巴拉巴拉。重点来了，根本不需要等对方巴拉完，只需要听到足够确定对面是骚扰电话，骗子，或者别的什么不需要的东西的内容。立刻执行下述操作，回答：“不需要，再见”，然后不要等对面任何反应。立刻挂机。

整个过程熟练后连 5 秒都不需要，对方再来，你照样如此操作，就像机器一样操作。相信我，这是对抗骚扰，骗子，以及其它推销电话的最好办法，因为你在整个过程中：1.没有暴露任何个人信息； 2.拒绝速度极快，且不给对面任何反应时间，极其干脆，这种对对面的骚扰式交流是极大的打击。因为这类骚扰式交流的一个培训套路，就是尽量让对方不要挂电话，尽量延长通话时间，通话时间越长越能找到对方心理弱点进攻巴拉巴拉。所以你迅速的结束通话，就给了对方一种心理震慑——即这个人不好惹根本不按套路走。
最好，开头的你好打招呼，和结尾回答，不需要再见，是为了让对面分析你的通话记录时确定你是个人。如果你完全不回话直接挂机，会让对面觉得你上了技术手段。会不死心的寻找其它方法进来。


建立起这个号码背后的人是绝对不好惹的对象，这一点非常重要，比你搞什么投诉，什么运营商防护强的多，因为这年头运营商或者和外面有勾结，或者自身技术不行，对骚扰电话的防御，远算不上好。我们的个人信息早不知道被卖了多少遍，所以要让对方不来骚扰你的，最简单的办法就是在对抗中让对方觉得你无懈可击。给你打电话是白费力气，毕竟骚扰电话也要花钱。自然就不来惹你了

@diagnostics 我前面说了那么多，看来你没听进去。
maven 一点也不老，作为一个包管理框架，它工作的非常好。
构建不过是它使用插件实现的附加功能。在这方面，肯定不如天生是为构建工具而生的 grade 。
你的复杂度已经到达了 maven 使用插件无法满足你的地步，那就就应该换更强的工具，而不是在原地抱怨一个并不是专门为构建而生的工具

@chuck1in 这两家有 orm 框架？没有吧，不如你举一个，我印象里这两家出的都是 sql tools 。不是说自己是 ORM 就是 ORM 的，ORM 的核心是 O ，奔着用 Object 取代 SQL 去的，所以无论 hibernate 还是 EF ，这两家都在 Object 上下了很大的功夫，所以 object 有很多状态，并用复杂的嵌套结构来映射 join 查询。而且他们有一个特征就是，当你没办法非得用 sql 的时候，非常麻烦，因为当年他们摆明了希望取代 sql 。
后来的 sql framework 基本都没有这么干，虽然他们保留了 object 和允许嵌套，但没有把 object 设计的非常复杂。同时都提供了很方便的直接写原生 sql 的能力。也就是说，后来的库基本都倒向了 R 。倒向 R 和 ORM 的想法就背离了，ORM 的核心是 O 。但是这个思路现在看是不成功的

maven 是包依赖管理工具，靠插件实现构建能力。
gradle 是构建工具，可以靠脚本实现各种匪夷所思的构建需求。

从以上你就能看出这两者的核心区别是什么，maven 就不是构建工具。

如果是简单的项目，比如现在大部分的后端 api ，也就几十个接口的那种，gradle 完全没必要，maven 的构建插件轻松搞定。

但是如果你的项目很复杂，比如 spring 这种已经是巨型的 framework ，再比如巨石型 APP ，你不用 gradle ，根本搞不定。


所以关键是你的开发究竟是哪个领域。就楼主来说，楼主是开发 framework 的，这一点和 spring 有点类似，而且楼主已经感觉到 maven 构建插件的上限了。这个时候，应该果断的换更强力的构建工具。


技术的应用，第一够用就好，第二如果不够用了要马上行动找解决方案。不要去评判好不好，技术的诞生都是有其自己的背景的，在这个背景下很好，换个背景就不适用了

@chuck1in ORM 是不限语言的一种思路，核心思想是想用面向对象来取代关系运算（虽然它名字叫“对象关系映射”）。所以你用面向对象的思路去思考它，暂时把关系运算的思路放一边比较好。

另外 ORM 的思路从现在看是失败的，因为对象关系并不能真的替换掉关系运算，所以 ORM 这个东西和 SQL 之间存在阻尼，这就是用起来各种不舒服的核心所在。现存的 ORM 也就剩下 java 的 hibernate 和.net EF 了，其它的认真来说都不能算 ORM ，是基于 active record 思路（创始者是 ruby on rail ）的 sql 强化工具。对关系数据库的访问方式最终还是回归到 sql 本身了。

当然，最近国内又有一些作者开始折腾了，但是他们的思路也不是 ORM 的思路，它们的思路是希望通过链式 api 调用，使其能映射几乎绝大部分 SQL 的想法，老实说我不是很看好，因为我觉得复杂 sql 最合适的思路还是直接写 sql 。

总之，ORM 的核心是 O ，而不是 R ，但是这个思路没走通，之后的绝大部分关系数据访问库，都倾向于 R ，分歧不过是怎么把用 R 的这个过程搞的漂亮点

@johnkyle 不好意思记错了

@wa007 HN 是啥？
还有为啥是 X 账号而不是推特账号？

Mac 这玩意不就是个 Unix 吗？看不起 windows ，又真有决心的话，你自己装个 Linux ，啥不能干？
非要买 Mac ，就是消费主义洗脑，装 b 而已

楼主你的思路其实不太对劲，你实际上是考虑把复杂功能集成化到一个组件上来解决问题，这会引入新的不确定性。你为啥一定要让 frp 来做这件事呢？你的服务器防火墙把端口关了不就完事了，职责单一，不容易出问题。
而且服务器防火墙一般有 api 接口的，写个脚本想开就开，想关就关

@xtreme1 直通？直通只能让一个虚拟机独占 GPU 。现在有没有在家用硬件上实现 GPU 被多个虚拟机调用的办法，就像调用 CPU 那样