@onion83 不，你没明白我说的意思，和他们的应用方向无关，而是常驻内存这个关键。近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战，javaee 重新开始回暖某种程度上可以视为业界的一种态度，swoole 从设计上是常驻内存的，而 php7 虽然有了围绕 opcache 设计的 jit，但是这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述。

@random2333 在大部分已知 PHP MVC 框架里，他最差，这还不算差是啥，其实差点倒也无所谓，关键是我觉得这家伙路走歪了

laravel 的那套东西，如果玩过 java 的 SSH 系列的都知道是咋回事，我个人不看好，更像是“为了证明我能这样”而搞出来的产物，而且 java 系的 web 最近一直在瘦身，往轻量化方向转，那种层层包装的做法被认为落后于时代，laravel 却觉得那样很好，还要学过来。。。我实在不觉得这有什么好学的，真正 javaee 的优点在于常驻内存，这个角度上，swoole 这样的东西才是未来，laravel 还是没脱离一次请求——载入资源——处理完毕——资源卸载这种 CGI 过程，包装的再华丽有啥用

你上学的时候能看到的老师是什么水平？培训班也就是那样
*.好老师始终是少数
*.就算有牛逼老师，你能不能学到也还要两说

@gouchaoer 你在大部分企业里实践微服务的第一个绕不过去的坎就是把他们原本基于传统关系数据库的系统改造成基于微服务的架构，这其中必然有一致性要求高的业务，要完全不要事务，纯粹 kv 存储是不可能，分布式事务的关系数据库，目前感觉都在发展中，鲜有成熟的例子

各位，微服务最大的问题在于每个服务背后都有一个独立的数据源啊，你们是怎么做这种分布式事务的，我觉得这才是核心问题，不论这个的话，微服务不过是把以前在一个项目组织内把功能分组进化到每个组进化为一个项目而已，如果解决不了分布式事务的问题，微服务压根也不能有效解决水平扩展问题。但是网上基本没有讲这块的具体实现的，都一股脑的说如何拆分业务

@SourceMan 前端技术发展异常迅猛，然而除了移动互联网之外，你还是要和该死的 IE 打交道。所以核心问题不是技术发展有多快，而是你能否摆脱某些用户

楼主，阻碍你普及新技术的首要障碍，是你的老板要面对的客户，而不是其他什么原因，如果你的老板面对的客户要求兼容 IE8，那你的推广必然阻力重重

@colincat 我遇到个新问题，你们当时在 tomcat 下做 websocket，是如何解决服务端超时检测这个问题的，即一段时间没有收到来自客户端的数据就断开。这个在别的 socket 实现下很简单的功能在 tomcat 下好难啊，放狗了两天，没找到肯定的答案

@notreami 因为已有的代码都是基于 session 的，搞个新的，你得把之前的代码全改了

@RainFinder 以前的交换模型是纯粹的“请求——响应”，而且用用户验证机制，基于 session （ shiro ）的，要推送的话，也是必须先沿着用户身份的，所以开始才考虑 websocket，希望能无痛升级，结果发现无法复用，java 实现的 websocket 有一个要求，用于处理 websocket 请求的那个 servlet 必须是独立的，并不能复用处理普通 http 请求的那个，于是就无法复用现有的用户验证体系。就僵在这里了

@des 核心问题时想复用现在的这一套用户验证机制，结果发现目前基于 session （ cookie ）的验证机制没法用在新的推送上

@lightening 如何付费，在哪里使用？

@USCONAN 首先谢谢，其次问问这玩意在哪里找到的，我直接访问 https://translate.google.com/都没看见这个 toolkit

本科的时候老老实实研究数学，到了研究生专业再去考虑这些，话说如果你能进理学院（研究数学的）并能学出点名堂来，你离这些专业就很近了

去面高级职位，然后你就知道你缺啥了

gayhub ？？？？这是什么鬼

当然是圈钱，info 上在推一个所谓的“高可用后端经验交流大会”，门票 6000 “起”，还得团购

@kslr Oauth2 难道就不过期了，无限刷吗？
而且有些明显不是 Oauth2 的也这样