- 主题:Re: 崩溃的实现方式
嗯。有些人就是这样子。不过关键还是 java 社区提供的工具都太重型了。内置在 jdk 内部的 web server 居然到了 jdk6 才提供。。回想一下 python 的 HTTPServer，简直是领先了十几年。这只是一个例子。Java 社区总是在设计“强大”的API，但是忽略了优先最常见的任务。
【 在 dhcn (coder) 的大作中提到: 】
: 耗时任务消息分发用Web容器手动转发，爬虫也在Web容器里面做，写十年Java SSH，是不是离了Tomcat就不会写Java程序了？
--
修改:hgoldfish FROM 211.162.33.*
FROM 211.162.33.*
docker 这种东西估计是那些运维最喜欢的了。开发者才不关心这种东西呢。
【 在 KCH (K饭) 的大作中提到: 】
: 那你怎么理解 Container-based virtualization ?
: 我觉得这是底层派对javaer的抄袭.
--
FROM 120.42.94.*
你说的老JAVAER也有可能是那种业务能手啊。外包做多了就是这样子，本身没啥提高的动力。
【 在 dhcn (coder) 的大作中提到: 】
: 这和部署有个毛关系，说的是实现方式。所有的执行程序都是Servlet形式，连多步爬虫、任务消息缓冲队列都是，做出来的东西，执行时间长的多步爬虫自身根本没有计算调度，Servlet服务自然是见消息就转发，直到后台的服务出错为止，根本就起不到耗时任务缓冲的作用。
: 由于后台都是纯Web服务实现方式,部分需求对后台服务的同步调用贯穿两层，根本无法实现前后台服务解耦，导致一线服务长时间空等状态，内存消耗惊人。高端配置，却根本跑不出效能。
: 当然这个项目之前是企业内部应用,技术实现的要求低，是业务信息传递成功就行，也不管执行时间，更不要说性能。
: ...................
--
FROM 120.42.94.*
我觉得如果是我的话，不太想参与这种团队。干的一点都不舒服。
【 在 dhcn (coder) 的大作中提到: 】
: 最关键的问题是这种人不好用,作技术攻坚吧,他本身排斥新东西，根本出不来什么设计，去Repeat业务代码吧，和那些小孩在一起，好像屈了他的资历了。说个实在话，他可能还不如那种新锐小孩，他对他自己写出来的代码的执行机制理解都有问题。我之前碰到一个小孩，喜欢学习，
--
FROM 120.42.94.*
serlvet 的结构本身限制了整个系统的设计就是一个个的调用。想要做长时间的操作你得去调 tomcat 的参数，不然就不返回了。
调用以后还得扔到 spring 的 service 里面去操作。spring 本身也是限制设计的一个地方，动不动就是接口什么的。对于一些需要仔细调节性能的程序，一层包一层的设计就是个大坑。
【 在 KCH (K饭) 的大作中提到: 】
: 你说得这些问题都不是放到servlet的结构本身带来的,只是业务模型不成熟,
: 这种问题用什么部署架构都一样. 一般这是长时间技术债积累的后果,
: 新人轻飘飘的说很容易,但难保老javaer十年前没吐槽重来过, 或者你重构的版本
: ...................
--
FROM 120.42.94.*